Comment vos valeurs de codage ont-elles changé depuis que vous avez obtenu votre diplôme ?

Question

Nous sommes tous sortis de l'école avec des étoiles dans les yeux et peu d'expérience dans la programmation du "monde réel". Comment votre opinion sur la programmation en tant que métier a-t-elle changé depuis que vous avez acquis plus d'expérience en dehors du milieu universitaire ?

Je suis devenu de plus en plus intéressé par le design à la McConnell Alors que beaucoup de mes collègues ont suivi un chemin différent, avec moins de couches intermédiaires, du code qui est à l'air libre et plus facile à trouver, même s'il est plus difficile à lire, et des conceptions centrées sur les performances.

Qu'avez-vous appris sur l'art de la conception de logiciels qui a changé votre façon d'aborder le codage depuis que vous avez quitté le monde universitaire ?

Answer 1

Je suis diplômé en génie logiciel. J'ai appris que presque personne ne veut de logiciels conçus par des ingénieurs. C'est cher, et lent à développer. Beaucoup de gens veulent le contraire. Quelque chose qui est jeté ensemble aussi rapidement et négligemment que possible, tant que ça fonctionne. Personne ne se soucie de l'aspect du code sous-jacent, tant qu'il est fonctionnel. Personnellement, j'essaie d'encourager des pratiques de développement logiciel plus professionnelles, mais je me rends compte que, parfois, la méthode rapide et sale est vraiment meilleure.

Answer 2

Avant l'université le truc, c'est d'être assez intelligent pour trouver la bonne façon de créer son programme. antes de vous commencez à coder. Je n'ai jamais été assez intelligent, et je me suis rendu compte de mes erreurs après 15 minutes de codage. :-(

Après l'université L'estimation du temps nécessaire à la création d'un logiciel est impossible à faire avec précision, il ne devrait donc pas y avoir de calendrier.

Après quelques années dans l'industrie : Après avoir constamment échoué à faire les choses correctement du premier coup, j'ai décidé que c'était impossible. Comme je travaillais sur le débogueur Visual C++, j'ai décidé que la clé pour être un bon programmeur était d'être très bon en débogage. Vous écrivez tout ce que vous pouvez, puis vous utilisez le débogueur pour trouver les problèmes et les corriger.

Après quelques années supplémentaires : Je suis passé du débogueur Visual C++ à l'éditeur Visual C#. J'ai décidé que le débogueur n'avait pas d'importance, la clé pour être un bon développeur est d'être bon en édition . J'ai aussi lu le livre de Fowler Refactoring . Au lieu d'essayer de bien faire les choses du premier coup, ou de mal faire les choses du premier coup et de vivre avec, j'ai décidé de mal faire les choses du premier coup, puis d'améliorer la conception en la remaniant.

Autres enseignements : La simplicité et la clarté du code sont essentielles. Si vous les maîtrisez, toutes les autres choses que vous pourriez souhaiter (correction, performances, capacité à ajouter de nouvelles fonctionnalités) deviennent accessibles. De même, chaque fois que vous rencontrez un bogue, ne vous contentez pas de le corriger, ne vous contentez pas de corriger des bogues similaires à d'autres endroits, mais changez votre façon de faire les choses pour garantir que ce genre d'erreur ne se reproduira plus jamais.

En tant que manager, j'ai dirigé une équipe selon les valeurs de simplicité, de refactoring, de clarté, de testabilité, de retour d'information rapide, de recherche d'une bonne conception, de pratiques de codage qui éliminent des classes entières d'erreurs, etc. Nous avons connu un succès fantastique. En tant que développeur individuel, j'ai continué à suivre ce que j'avais appris en tant que manager et j'ai eu la plus grande productivité de ma carrière (bien que mon ancienne équipe ait été bien meilleure que moi).

Answer 3

/********************************************************
* Star encrusted header's have gone the way of the dodo *
********************************************************/

Les commentaires sont désormais appliqués si et seulement si nécessaire. Le code est généralement un commentaire suffisant.

Answer 4

J'ai fini par me ranger fermement dans le camp de McConnell après avoir lentement écarté un tas de bêtises apprises à l'école.

Son livre en dit plus sur la bonne ingénierie logicielle que ce que j'ai appris à l'université.

Answer 5

Le principe DRY (Don't Repeat Yourself) est devenu beaucoup plus important pour moi. Mes critères de réussite d'un logiciel ont également changé : je suis plus heureux avec un logiciel que d'autres personnes peuvent facilement étendre.