J'avoue : la plupart du temps, j'ai un problème avec "Keep It Simple and Short" car essayer de le faire en fonction des livres que j'ai lus, des modèles de conception que j'ai entendus, etc. me donne un tel enthousiasme - un enthousiasme venant de le sentiment que je suis sur la bonne voie vers une perfection probable.
D'un autre côté, oui, cela me met un stress supplémentaire en termes de respect des délais parfois ...
Mais chaque fois que je me dis: "La prochaine fois, reste simple, stupide!" Je trouve ça très difficile de rendre "simple" la prochaine fois, car ça commence à paraître bizarre ... et inconfortable après un point.
Ensuite, je commence à juger ma compréhension de «simple» ...
SIMPLE signifie-t-il trop court qu'il fonctionne mais difficile à maintenir et à étendre?
SIMPLE signifie-t-il briser de nombreux principes de la POO?
SIMPLE signifie-t-il tricher?
SIMPLE signifie-t-il simplement respecter les délais sans faire de bruit? etc.
En fait, c'est quoi?
La question est : pouvez-vous écrire la définition EXACTE de SIMPLE en termes de principe KISS? -s'il y a.
Merci!
la source
Réponses:
Apprenons un baiser français:
Ce qui se traduit par:
la source
Scénario
Vous devez couper et pincer.
Solution A: pas KISS
Solution B: BAISER
Quant à une définition exacte : il est difficile de définir une échelle absolue pour mesurer la simplicité. Principalement parce que la vraie simplicité empêche la vraie compréhension du problème en question, et c'est rarement réalisable. Mais disons que les solutions A et B illustrent la différence entre les solutions qui tendent respectivement à la sur-complexité et à la simplicité.
la source
"Rendre les choses aussi simples que possible, mais pas plus simples" -Einstein
Garder le code aussi simple que possible, mais pas plus simple dépend du problème résolu. Tant que le problème résolu a tendance à changer, KISS aussi.
Il y a un équilibre entre la suringénierie (oh mec, cela ressemble à un endroit idéal pour montrer mes compétences en conception de modèles!) Et la sous-ingénierie (si seulement j'utilisais une usine, je n'aurais pas ce couplage qui m'a fait faire 20 changements de code ...). L'objectif est la maintenabilité.
la source
Simple ne signifie pas enfreindre les bons principes de programmation. En fait, cela signifie davantage le contraire.
Non. Être difficile à maintenir et à étendre est un gros symptôme de complexité. En fait, je trouve que rendre le code extensible conduit à un code plus simple, puisque vous ne traitez pas tous les cas pour commencer, vous pouvez garder le code de base plus simple.
Non. La plupart des principes de POO sont conçus pour garder le code plus propre et plus organisé, ce qui en fin de compte est plus simple.
Non. Il est difficile d'écrire pour maintenir le code et les hacks sous prétexte de respecter les délais.
Non. Les délais et la simplicité de votre code sont deux problèmes distincts. L'écriture de code simple ne prend pas plus de temps à écrire (bien qu'il s'agisse d'une idée fausse courante).
la source
C'est très difficile à expliquer car simple ne signifie pas la même chose pour tout le monde.
Exemple. Certains développeurs pensent que
?:c'est simple mais d'autres pensent qu'uneifdéclaration est meilleure. Quand c'est à ce niveau, vous ne pouvez pas plaire à tout le monde.En général, simple signifie sans complexité . Pour comprendre la simplicité, nous devons comprendre la complexité.
Il existe deux types de complexité:
Vous pouvez vérifier la complexité essentielle avec les questions suivantes:
Cette solution est-elle simple? Puis-je l'expliquer à mes pairs en quelques minutes et ils l'obtiennent? Existe-t-il une solution plus simple au problème? Si oui, y a-t-il des compromis entre la solution compliquée et la simple? Pouvons-nous vivre avec ces compromis? Par exemple, de nombreux programmeurs font une erreur de micro-optimisation de tout et leur solution (ainsi que le code) devient trop compliquée.
Vérifier votre complexité accidentelle:
Le code est-il simple? Si j'y reviens dans trois mois, combien de temps me faudra-t-il pour créer le contexte dans mon cerveau afin que je puisse faire le changement que je dois faire? Est-ce que tout dans mon code source a un objectif clair et il le transmet efficacement à moi et aux autres développeurs ? Est-ce difficile de tester mon code? Habituellement, plus votre code est compliqué, plus il est difficile de faire des tests unitaires, donc j'utilise généralement cela comme une mesure de la complexité. Vous voulez généralement de petites classes et méthodes bien nommées et ciblées. Les modèles de conception vous aident généralement à les atteindre également.
Si vous souhaitez utiliser un modèle de conception simplement parce que vous venez de le lire, cela va probablement introduire une complexité accidentelle. Si vous voulez mettre quelque chose parce que vous pensez que c'est intelligent, cela introduira probablement une complexité accidentelle.
J'espère que cela aide et n'oubliez pas: simple ne signifie pas FACILE .
la source
J'ai toujours pensé que les principes derrière X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) valaient la peine d'être respectés. Je n'arrive pas toujours à atteindre cet objectif.
Plus précisément, je dois toujours me rappeler ... "N'ajoutez pas de nouvelles fonctionnalités à moins que vous ne connaissiez une application réelle qui en aura besoin.", Et "Si vous pouvez obtenir 90% de l'effet souhaité pour 10% du travail, utiliser la solution la plus simple. "
la source
Non.
la source
Simple - dans ce contexte particulier, c'est exactement l'opposé du complexe. Simple ne signifie pas nécessairement: toute personne stupide doit le comprendre - mais vous devez vous assurer que vous pouvez le comprendre, même si vous ne l'avez pas écrit vous-même.
La complexité pourrait être obtenue par une compréhension difficile des références - débarrassez-vous-en! De nombreux fichiers / classes liés les uns aux autres - pas question! Et du code compliqué (ce qui signifie: boucles chaînées, plusieurs couches ITE, etc.) - personne ne veut lire cela.
À mon avis: Il est très facile d'ajouter une autre fonction, dans les classes, vous pouvez également ajouter des fonctions privées, donc vous ne jouez pas avec l'interface. Alors pourquoi ne pas utiliser cet avantage et limiter vos fonctions / procédures à 50 lignes. Peut-être encore moins. Obtenez des noms significatifs. De cette façon, vous rendez la plupart des commentaires obsolètes. De cette façon, vos fonctions sont faciles à lire, faciles à modifier / étendre.
Bien sûr ... les dernières phrases auraient fonctionné comme: Dans les classes, il y a la possibilité de définir des fonctions privées, utilisez simplement cette possibilité pour diviser les fonctions en 50 lignes afin qu'elles soient beaucoup plus lisibles (n'oubliez pas les bons noms, vous n'avez donc pas besoin de commenter beaucoup).
MAIS: Il est beaucoup plus simple (!) De tout lire s'il y a un arrêt complet qui montre: j'ai terminé une pensée, passons à la suivante.
C'est ce que je définirais comme simple.
la source