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

J'ai obtenu mon diplôme il y a 10 ans, alors peut-être que le fait qu'intellisense permette une plus grande verbosité et que la délcaritivité du HTML et du XAML transmette l'intention du développeur a joué un rôle, mais mon opinion sur les commentaires de code en ligne a considérablement changé. À l'école, on m'a enseigné et convaincu que presque chaque ligne de code avait besoin d'un commentaire. Mes mentors de la vieille école pensaient la même chose. Maintenant, je crois que je devrais m'efforcer de faire du code qui exprime clairement mon intention. Je ne commente que lorsque je ne peux pas écrire un code dont l'intention est claire.

Answer 2

J'ai appris que la pratique que l'on évite dans mon école, à savoir copier-coller le code des autres, est en fait la façon dont on procède dans le monde réel. Ainsi, au lieu d'obtenir des notes médiocres pour avoir plagié le code d'autrui à l'école, c'est la chose la plus intelligente à faire dans le monde réel, en s'appuyant sur le code bien testé d'autrui, en utilisant des cadres et des interfaces au lieu d'essayer de réinventer la roue moi-même à chaque fois.

Bien sûr, je vérifie toujours la licence du code avant de l'utiliser dans mon application :)

Answer 3

Les choses qu'on ne vous apprend jamais à l'université :

• Les calendriers sont importants : on ne vous impose pas une date limite pour laquelle vous devez faire l'essai de la vieille école.
• Tout changement introduit un risque : Les grands systèmes comportent généralement suffisamment de pièces mobiles pour que vous ne puissiez pas comprendre immédiatement toute l'ampleur d'un changement.
• Tout est relatif : "il faut faire ça" n'a vraiment aucun sens. Tout, tout doit être fait. Prenez un numéro et faites la queue.

Answer 4

Depuis que j'ai quitté l'université/le collège, je me suis lentement rendu compte que l'utilisation de l'héritage et la conception orientée objet classique ne sont pas la réponse à tous les problèmes de conception.

Bien que j'essaie toujours d'écrire des classes faiblement couplées et hautement cohésives qui ont des responsabilités claires, je trouve que je n'ai presque jamais besoin de hiérarchies d'héritage profondes et en fait, je m'en sors souvent sans héritage du tout.

De plus, j'avais l'habitude de penser que le code devait être écrit de manière à ce qu'il soit le mieux compris par le compilateur/ordinateur. Maintenant, j'écris du code pour que d'autres personnes le comprennent. Peut-être que cela aurait dû être enseigné dans mon diplôme d'informatique, mais ça ne l'a pas été.

Answer 5

J'ai appris beaucoup de choses mentionnées ailleurs dans ce fil, mais la chose que je ne vois pas encore mentionnée est la maintenabilité. Lorsque vous écrivez du code à l'université, vous savez que vous ne l'utiliserez plus jamais. Il doit juste faire son travail. Lorsque vous écrivez du code dans le "monde réel", il vivra pour toujours. Les outils que j'ai écrits lorsque je suis arrivé à ce poste il y a plus de 10 ans sont toujours utilisés. Il est très important de garder le code simple, direct et bien commenté.