Voici quelques-uns des principes lapidaires auxquels je crois et que j'ai trouvés utiles.
- Lorsque vous attaquez un nouveau problème, apprenez comment il a été résolu auparavant. Presque chaque nouveau problème est un ancien problème déguisé. Comprendre cela et examiner l'art antérieur peut accélérer et améliorer votre solution. Vous ne croiriez pas le nombre de fois où j'ai vu un problème complexe résolu sans comprendre l'art antérieur, en faisant toutes les erreurs que les pires antériorités ont faites dans LEUR première tentative. Perte de temps et d'énergie, résultant en un logiciel de mauvaise qualité.
- Si vous écrivez vos propres protocoles de sécurité / cryptographie, vous le faites mal. Utilisez des protocoles cryptographiques et de sécurité existants et bien étudiés. Personne n'y arrive du premier coup, et il y a de très bonnes chances que quelque chose que vous faites par vous-même présente des vulnérabilités qui n'apparaîtront que lorsqu'il sera trop tard pour les corriger.
- Ne faites pas le malin. Pour le développement de logiciels commerciaux, le plus important est que le code soit facilement compris, débogué et maintenu. Cela rend moins probable qu'il soit erroné, et moins probable qu'il soit jeté par la prochaine personne qui doit travailler dessus.
- Ne pas trop optimiser ou modulariser dès le départ. Optimiser tôt complique le code, et peut améliorer le temps d'exécution d'une manière inconséquente. Obtenez un algorithme clair et propre et optimisez-le plus tard. De même, il faut faire preuve de modération en s'efforçant de rendre le système modulaire et extensible. Dans quatre de mes projets pluriannuels, plus d'un an (chacun) a été consacré à la création d'un modèle de plug-in facilement extensible. Le seul plug-in réellement écrit dans chaque cas était l'exemple unique avec lequel mon équipe a commencé, mais nous avons considérablement compliqué le développement et les tests en adoptant cette approche. Attendez d'avoir un besoin, ou vous risquez de créer les mauvaises interfaces et de perdre du temps et de l'énergie. Enfin, j'ai vu plusieurs exemples de personnes allant trop loin avec la POE et l'encapsulation, compliquant inutilement le code.
- Vous ne pourrez jamais " réparer plus tard ", alors faites-le bien. Une autre erreur que j'ai faite à plusieurs reprises est de jeter quelque chose ensemble avec l'intention de le corriger avant d'expédier. Ensuite, un feu après l'autre surgit, et le code est expédié dans une forme hideuse. Écrivez-le de la bonne façon dès la première fois.
- Ajouter une journalisation sensible. Assurez-vous que vous avez un moyen de journaliser / tracer l'exécution de votre code. Assurez-vous que ce mécanisme est léger, et a des niveaux de journalisation sélectionnables (par exemple, informationnel, avertissement, erreur) pour vous permettre de contrôler combien est journalisé.
Il y en a beaucoup plus, mais ce sont les plus utiles pour moi.
.