FonctionnalitéKarma

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Cette page a démarré sur FeatureKarma

: "Quand vous initiez de nouvelles activités, trouvez des choses que vous faites actuellement et que vous ne pouvez pas interrompre -- que ce soit des compte-rendus, des activités, etc. Cela fonctionne, mais vous devez vous efforcer à le faire. Gardez toujours à l'esprit votre TeethToTailRatio." -- Donald Rumsfeld, Rumsfeld's Rules.

Si vous souffrez des JargonFile:CreepingFeaturitis ou même pire, des gonflements de fonctionnalités, vous avec une mauvaise fonctionnalité karma.

De ce fait, quand vous doigts vous pressent d'ajouter encore une nouvelle fonctionnalité, vous devez effacer ou en simplifier une autre existante pour équilibrer la fonctionnalité karma.

Si vous croyez que l'ordinateur parfait est éteint et dans un remplissage de champs, alors vous pouvez facilement comprendre la philosophie. Aussi, si vous travaillez à construire une communauté, moins vous avez d'acrobaties à faire faire à vos éléments, mieux c'est.

Dit souvent d'une autre manière, le code le plus simple produit les meilleures communautés, parce que les personnes peuvent piger plus rapidement le comportement. Ceci parce qu'aù fil du temps, les personnes pratiquent doucement dans leurs têtes un reverse engineering des programmes.

Si vous avez autorisé peu de règles, vous devrez en faire des bonnes et puissantes. Alors, parce qu'il n'y a seulement qu peu de règles, les gens les apprendront et trouveront des façons intéressantes de les mixer. Voilà comment Wiki:JimCoplien a découvert <TAB><SPACE>:<TAB> == la citation et CliffordAdams a résolu le pluriel des ModèleDeLien's. [Localement la règle de citation est simplement un caractère : (au début de toute ligne), et la règle des ModèleDeLien's au pluriel a changé).]

Ceci est dans la même veine que le sage écrivant un conseil : vous n'êtes pas fait pour éditer à moins qu'on ne vous laisse avec une page blanche.

"Ecrire est facile. Vous rayez simplement tous les mots inappropriés." -Mark Twain

Maintenez-là simple. Maintenez-là puissante. OrdonnerLeChaos.

[Selon] JoeArmstrong?, NiklausWirth? a dit une fois que si quelque chose est ajouté à une langue, d'autres choses devraient être jetées.

La simplicité est magnifique et la beauté est une force puissante dans les décisions de design. Les personnes ont des besoins différents et des fonctionnalités supplémentaires peuvent néanmoins aider les individus à parvenir à la simplicité dans leur travail. Une fonctionnalité que la plupart des gens n'utilisent jamais peut être une fonctionnalité cruciale pour un petit groupe d'utilisateurs.

Les fonctionnalités ne doivent pas être prises trop loin, tout spécialement quand des fonctionnalités moins importantes affectent les fonctionnalités communes. Les designers devraient choisir de bon comportements par défaut, et ne pas encombrer l'utilisateur avec trop de choix non demandés. D'un autre côté, un bon outil ne devrait pas limiter l'utilisateur à des comportements de novice.

Une autre façon de comparer les approches est de regarder différentes formes de littérature. Quelques personnes s'expriments elles-mêmes très bien en poésie alors que d'autres écrivent de gros romans. Très peu de personnes sont capables d'écrire des romans avec l'intensité d'un poème court. (Peu de personnes sont même capables de lire des travaux intenses à longueur de livre). Parfois il est inapproprié d'écrire un grand livre pour exprimer les détails d'une simple idée.

Une autre approche est simplement d'empiler les fonctionnalités et de reconcevoir quand un problème apparaît. Par exemple, le SGML est un standard soigneusement conçu qui n'a pas rencontré les besoins de la première communauté internet. HTML a été créé et est rapidement devenu un bazar. Des standards ont émergé du bazar, et quelques-uns d'entre eux (comme les tables) ont été acceptés et utilisés par la communauté, alors que d'autres (comme <blink>), ne l'ont pas été. Pour finir, le XHTML a été créé pour nettoyer beaucoup du bazar tout en conservant les aspects utiles du HTML.

Il est incertain de dire que ce HTML moderne pourrait avoir été conçu sans les erreurs produites dans les précédentes versions. Beaucoup de fonctionnalités communément utilisées (comme l'utilisation de "listes de définitions" pour décaler le texte) sont maintenant découragées en faveur de tel ou tel standard plus récent (feuilles de style). Parfois le meilleur moyen de faire est d'essayer, échouer, apprendre et à nouveau réessayer avec une nouvelle connaissance. Parfois, on peut démarrer le second ou troisième essai avant que la conception parfaite ne soit terminée.

Exactement. Pour équilibrer votre karma, vous devez effacer le "cruft" (code redondant et mal écrit) que vous avez accumulé. Il n'y a rien de mal à ajouter des fonctionnalités, tant que vous désirez effacez les stupides.

Et HTML n'est pas exactement un bon exemple. Il n'existe pas de HTML standard. C'est comme essayer de porter du code C avant ANSI/X3J11.

Html est l'exemple parfait. Il y a beaucoup de standards HTML -- sentez-vous libre d'en choisir un. La plupart des auteurs de navigateurs tendent à converger vers le standard W3C HTML 4.

Les standards acceptés tendent à mettre fin à l'innovation. C'est probablement plus facile d'écrire un tout nouveau langage que d'ajouter une fonctionnalité significative au langage C. (Bien sûr, standardiser le langage ne fait rien pour courber l'usage inventif du langage. Une dispute pourrait même être produite pour l'encourager).

Un truc pour obtenir un standard vraiment bon est de trouver ce que les utilisateurs veulent vraiment avant de geler le standard. Un bon moyen de savoir ce que les utilisateurs veulent est d'implémenter presque toutes les fonctionnalités demandées, puis de voir par la suite quelles fonctionnalités sont vraiment utilisées. Quelques fonctionnalités qui semblaient utiles ne seront pas utilisées, alors que quelques fonctionnalités obscures seront très populaires.

En quelque sorte, le fait d'ajouter des fonctionnalités demandées par les utilisateurs est plus important sur un wiki que dans la plupart des logiciels. Si un traitement de texte à une fonctionnalité manquante, on peut choisir un autre programme qui offre la fonctionnalité. Si un wiki n'offre pas une fonctionnalité, alors on n'a pas cette option-là (d'utiliser simplement un autre programme). Le contenu est lié à l'implémentation spécifique.

ModèleDeLiens et "syntaxe de facto"

Les ModèlesDeLiens? au pluriel (ModèleDeLien) sont sûrement un anti-modèle. La leçon ici est que si vous n'ajoutez pas une fonctionnalité demandée, les gens essaieront de la falsifier par d'autres moyens. Vous parvenez avec une syntaxe de facto qui n'est pas évidente, verbeuse, aliénante et généralement élève la BarrièreALEntrée?.

L'utilisation de plusieurs apostrophes simples pour délimiter un ModèleDeLien n'est certainement pas évidente. L'interaction avec les règles de mise en page des textes était accidentelle et découverte lentement. Dans le proche futur, UseModWiki (et MeatballWiki) pourront ajouter une solution bien plus simple. La nouvelle méthode résoudra aussi les problèmes de ponctuation après les URLs utilisant la même syntaxe.

: Après plusieurs tentatives, UseModWiki a choisi d'utiliser "" (deux doubles-apostrophes) comme un délimiteur invisible, comme ModèleDeLienÿ?0ÿs (affiché comme ModèleDeLiens). Cela a remplacé la vieille pratique d'utiliser quatre ou six apostrophes simples comme : LinkPatternÿ?1ÿs. La nouvelle règle n'interagit pas avec toute autre règles de mise en forme, et elle est cohéremment utilisée pour tous les types de liens.

Il n'y a rien de mal à ajouter de nouvelles fonctionnalités, tant que vous désirez effacer les stupides.

Si les fonctionnalités étaient "stupides", elles n'auraient pas été ajoutées, ou remarquées quand elles ont été jetées au dehors. Les décisions comme ça sont tout à fait faciles à faire. Traiter le développement de fonctionnalité comme un jeu à somme nulle peut être dommageable pour un utilisateur de communauté, en donnant aux gens des raisons de se battre contre les demandes de fonctionnalités d'autres personnes. (Il y aura encore une compétition pour un temps de développement limité, mais parfois il est facile d'accepter une demande de faible priorité.)

D'un autre côté, parfois les compromis sont valables. Par exemple, parfois une fonctionnalité désirée a un coût trop élevé en temps de développement, ou requiert une restructuration qui affecte d'autres fonctionnalités.

Par exemple, une fonctionnalité de "diff avancée" pour UseModWiki a été développée mais retirée plus tard. Elle fournissait une production presque optimale de "diff" en conservant les versions d'historiques de pages dans chaque page. Le nouveau code pouvait, à un temps donné, montrer toutes les différences depuis ce temps, ou montrer la différence disponible la meilleure et alerter l'utilisateur que plus de différences existaient. (Par exemple, sur une vision de 3 jours de ModificationsRécentes, le lien "(diff)" afficherait une diff unique avec toutes les modifications produites durant les trois derniers jours).

La fonctionnalité "diff avancée" avait néanmoins plusieurs inconvénients. Elle était difficile à tester. Elle a rendu la base de données beaucoup plus grosse. Elle a considérablement compliqué quelques fontions admin planifiées, et a souvent été un facteur dans d'autres plans. La fonctionnalité était difficile à expliquer et pouvait devenir confuse à utiliser. Ce n'était pas drôle du tout d'écrire et de maintenir ce code-là, et elle a presque interrompu tout autre développement. Pour finir, parès avoir imaginé que peu de personnes n'utiliseraient même les meilleurs parties de la fonctionnalité, la "diff avancée" a été laissée tomber. (Peut-être que cela fût stupide, mais c'était vraiment chouette quand elle fonctionnait.)

Je pense que j'ai été beaucoup trop dramatique quand j'ai utilisé le mot "stupide". Le point que j'essaye de produire est qu'il est souvent mieux de chercher des façons de condenser les fonctionnalités en des plus simples et plus puissantes plutôt que d'ajouter de nouveaux frobs au produit. Il est néanmoins stupide de patcher fonctonnalité sur fonctionnalité sans penser à ce que vous voulez pour finir du logiciel et d'imaginer ce qui est le meilleur. Au moins, c'est vrai dans notre contexte de constructeurs de communautés. -- SunirShah

Je suis d'accord généralement. Malheureusement, je suis essentiellement sur des idées de condenser encore plus à fond mon code wiki. [Attention : métaphre questonnable suit ;-] On pourrait penser que le processus d'ajouter "fonctionnalité sur fonctionnalité" puis de simplifier comme un empilement d'ordure. On construit un paquet de fonctionnalités, puis on enlève celles qui ne sont plus utiles.

J'ai eu de bons résultats avec une stratégie de plein de fontionnalités dans le temps. Dans le développement, le programme a démarré comme un énoncé simple dans l'une des fonctions de trn. Après que beaucoup plus de fonctionnalités aient été ajoutées, le code a migré sur un fichier et a été nettoyé. Plus tard, des fonctionnalités similaires ont été ajoutées à une partie différentee en copiant et modifiant le code. A la fin, j'étais fatiqué de modifier de mulitples sections du code qui faisait essentiellement la même chose, aussi je l'ai récrit d'une façon à moitié orientée objet. (C'était avant que le C++ ne soit utilisable dans mon environnement.)

Plusieurs fois, j'ai trouvé que mes premières suppositions étaient erronnées et ont drastiquement changé mes directions de développement. (J'ai probablement écrit plus de 20 000 lignes de code jeté, comparé à environ 10 000 lignes de code livré). A ce moment, je voyais toujours le code comme un modèle de prototype pour la version finale. Le plan était toujours d'agrandir le modèle actuel à ses limites, puis de reconcevoir le projet en se basant sur ce qui avait appris du modèle. Plus d'une fois, j'ai fait un backup du source, puis retiré les fichiers de mon répertoire de travail et l'ai récrit (pour coller à un nouveau design). Le code strn n'est certainement pas le code C le plus propre, mais il a produit des objectifs vraiment ambitieux.

Si je voulais justifier ma méthode, je pourrais l'appeler "organique" comme comparé à la croissance "cristalline". Puis à nouveau, peut-être que j'ai un sale esprit (comme mon bureau :-) J'aime vraiment le désordre comme la langue anglaise de Perl . -- CliffordAdams (qui tant de FonctionnalitéKarma, qu'il ressucitera probablement comme l'assistant presse papier de Microsoft.)

Les décisons comme celles-ci sont plutôt facile à faire. - Parfois c'est difficile. Par exemple, à cette heure la RedirectionPage me semble être une fonctionnalité "stupide". Ses avantages semblent mineurs ; elles nous épargne essentiellement d'avoir à suivre un lien supplémentaire. Ses coûts semblent majeurs ; chaque fois je la regarde, je semble trouver des nouvelles complications et problèmes. Ainsi, je serais tenté de la laisser tomber. D'un autre côté, je serais aussi tenté de persévérer ; peut-être que les problèmes peuvent être résolus avec suffisamment de travail et d'ingéniosité, et l'avantage peut être plus grand que ce à quoi je m'attends.

J'ai commencé à réfléchir moi-même à la fonction de redirection. Elle n'est vraiment pas trop mauvaise dans le code, parce que la plupart de ses fonctions sont partgées avec la redirection après édition. Je pense que ce devrait être non nécessaire la plupart du temps, parce que les personnes ne modifieraient simplement que les liens originaux vers la vraie cible, puis effaceraient la page de redirection. J'aimerais la laisser de côté durant un moment et voir si quiconque revient pour en faire bon usage. Si la fonctionnalité de redirection est sur le chemin de quelque chose d'autre de génial, elle s'estompera probablement.

: La fonctionnalité redirection a pris plus de travail que ce qui était attendu, mais c'est maintenant une fonctionnalité "permanente". Des améliorations ont été apportées pour utiliser le HTTP "Location:" titre (aussi utile pour une édition ordinaire) et un lien arrière à partir de la cible vers la page redirigée.

Si vous abandonnez les idées au premier signe du problème, vous n'arriverez jamais à quelque chose de génial. -- DaveHarris

Mais parfois, vous devez savoir quand les plier... la fonctionnalité "diff avancée" avait presque tué le développpement UseModWiki. J'ai continué à penser "juste un petit peu plus et cela fonctionnera" durant des mois jusqu'à ce que n'ai réalisé que c'était une fonctionnalité que seul son créateur pourrait aimer. --CliffordAdams (ai je mentionné que c'était vraiment chouette ?)

Oui, vous devez savoir. Je ne suis simplement pas d'accord sur le fait que savoir est facile.

Personnellemnet je pense que "diff" est une fonctionnalité presque cruciale, en termes de visions personnalisées et de dimensionnement. Si je visite un site seulement une fois par semaine pour savoir ce qui a changé depuis, alors je ne peux pas me permettre de relire le site en entier à chaque fois. (Vos pages de modifications récentes y parviennent admirablement ici, ceci dit en passant). Je pense aussi que c'est important pour la responsabilité, comme partie d'une PisteAudit que je vois comme une section importante d'un modèle de SécuritéDouce. Je ne comprends pas vraiment ce que faisait votre "diff avancée" ou quels étaient les problèmes, aussi je ne vous dirai pas que vous avez fait une erreur d'y travailler, mais je pense que le champ général mérite beaucoup d'effort.

: La fonctionnalité "diff avancée" sauvegardait quelques anciennes versions de chaque page, et pouvait souvent générer des différences à partir du dernier moment où un utiliateur avait lu la page. Le plus gros problème était de créer une interface pour le grand nombre d'options que fournissait la "diff avancée". Quelque temps après, j'ai abandonné la version de l'"avancée", UseModWiki ne fournissait seulement que la fonctionnalité "diff" la plus basique -- la différence entre la version actuelle et la version précédente. Les différences majeur/mineur/auteur sont un compromis entre les plans originaux pour une "diff" pleine de fonctionnalités et la diff inadéquate "version précédente".

: Une autre fonctionnalité que je voulais écrire était une "diff jour", qui montrerait toutes les modifications produites durant la journée en cours. Parce que désirais implémenter cette fonctionnalité, j'ai résisté à la capacité d'ajustements de fuseaux horaires (qui pouvaient changer les heures du "jour en cours" pour différents utilisateurs). Après, j'ai abandonné sur la "diff jour", les ajustements de fuseaux horaires furent étonamment faciles. --CliffordAdams

Ces décisions ne sont pas faciles ; avoir les bonnes est ce qui distingue les programmeurs de génie. En termes de Wiki:PatternLanguage : des pages comme FonctionnalitéKarma aident parce qu'elles identifient les forces, mais les forces doivent encore être amenées en équilibre et cette page est trop générale pour offrir une solution concrète. Le modèle proposé, "Effacer une vieille fonctionnalité à chaque fois que vous en ajoutez une nouvelle", est sur-simplifié. -- DaveHarris

J'aime désormais la façon dont cette page est pleine de contradictions. Ces jours-ci j'imagine le hack d'indentation de Cope et le hack de Cliff Wiki:SixSingleQuotes et le délimiteur à double apostrophe être très laid, et je pense que la transition SGML -> HTML -> XHTML ne démontre pas quoi que ce soit. A ce stade, encore je m'accroche à l'idée de la FonctionnalitéKarma, si seulement comm un EquilibreDeForces? vers la fonctionnalité-tis. Hé, le karma est assi difficile qu'il n'est facile. -- SunirShah

LangueFrançaise PageTranslation FeatureKarma

FonctionnalitéKarma

Discussion