Quelle pratique de programmation que vous aimiez autrefois avez-vous changé d'avis?

Question

Comme nous le programme, nous avons tous de développer des pratiques et des modèles que nous utilisons et dont ils dépendent. Cependant, au fil du temps, à mesure que notre compréhension, de la maturité, et même l'utilisation de la technologie de changements, nous nous rendons compte que certaines pratiques que l'on pensait étaient de grands ne sont pas (ou ne s'appliquent plus).

Un exemple de pratique une fois, j'ai utilisé assez souvent, mais au cours des dernières années a changé, c'est l'utilisation de l' objet Singleton pattern.

Au travers de ma propre expérience et de longues discussions avec des collègues, je me suis rendu compte que les singletons sont pas toujours souhaitable - qu'ils peuvent rendre le test plus difficile (par inhibition de techniques comme se moquer) et peut créer des indésirables de couplage entre les parties d'un système. Au lieu de cela, j'utilise désormais l'objet d'usines (généralement avec un conteneur IoC) qui cachent la nature et de l'existence de singletons de certaines parties du système qui ne se soucient pas ou besoin de savoir. Au lieu de cela, ils s'appuient sur une usine (ou service locator) d'acquérir l'accès à ces objets.

Mes questions à la communauté, dans l'esprit de l'auto-amélioration, sont:

• Quels modèles de programmation ou de pratiques avez-vous réexaminé récemment, et maintenant, essayez de les éviter?
• Qu'avez-vous décider de les remplacer?

Answer 1

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Answer 2

Seul les points de retour.

Une fois, j'ai préféré un seul point de retour pour chaque méthode, car avec qui je peut assurer que tout le nettoyage nécessaire par la routine n'a pas été négligé.

Depuis, j'ai déménagé à beaucoup plus petites routines - de sorte que le risque de négliger le nettoyage est réduit et, en fait, la nécessité pour le nettoyage est réduit, et de trouver que les premiers retours de réduire la complexité apparente (le niveau d'imbrication) du code. Les artefacts de l'unique point de retour de maintien de "résultat" variables autour de, garder le drapeau des variables, des clauses conditionnelles pour pas-déjà-fait des situations - rendre le code apparaît beaucoup plus complexe qu'elle ne l'est en réalité, de rendre plus difficile à lire et à maintenir. Les sorties, et les petites méthodes, sont le chemin à parcourir.

Answer 3

• Essayer de coder les choses parfaitement dès le premier essai.
• Essayer de créer un modèle OO parfait avant le codage.
• Tout concevoir pour la flexibilité et les améliorations futures.

En un mot, suringénierie .

Answer 4

La notation hongroise (à la fois les Formes et les Systèmes). J'ai utilisé le préfixe tout. strSomeString ou txtFoo. Maintenant, j'utilise someString et textBoxFoo. C'est beaucoup plus lisible et plus facile pour quelqu'un de nouveau à venir et ramasser. Comme un bonus supplémentaire, il est trivial de le garder constant -- camelCase le contrôle et l'ajout utile/nom descriptif. Les formes hongrois a l'inconvénient de ne pas toujours être cohérent et Systèmes hongrois n'a pas vraiment le gain de beaucoup. Chunking toutes vos variables ensemble n'est pas vraiment utile, surtout avec les IDE modernes.

Answer 5

Le "parfait" de l'architecture

Je suis venu avec L' architecture il y a quelques années. Me suis poussé techniquement aussi loin que je pouvais, donc il y avait 100% faiblement couplé couches, l'utilisation extensive des délégués, et des objets légers. Il était technique le ciel.

Et c'était de la merde. La technique de la pureté de l'architecture à seulement ralenti mon dev équipe en vue de la perfection sur les résultats et j'ai presque atteint un échec complet.

Nous avons maintenant beaucoup plus simple, moins techniquement parfait de l'architecture et de notre taux d'exécution a atteint des sommets.