1. Réfléchissez clairement avant d'écrire du code

Les nouveaux venus dans le secteur, afin de montrer leurs capacités, sont impatients de commencer à écrire du code dès qu'ils reçoivent les exigences. C'est un grand tabou ! À mon avis, le temps réellement passé à écrire du code n'est que de 20 %. Si vous ne réfléchissez pas clairement, les 80 % restants du temps seront consacrés à corriger des bugs.

2. Si vous ne communiquez pas, vous vous retrouverez la tête cassée et le visage en sang

Ne pas être bavard et communicatif peut facilement conduire à des malentendus sur les exigences. Au final, vous terminez le développement pour découvrir que ce n'est pas ce que le produit demandait. De nombreuses fonctionnalités sont reportées et retravaillées à cause d'un manque de communication.

3. Personne ne lit la documentation, mais vous devez quand même l'écrire

Le rôle de la documentation n'est généralement pas de communiquer, mais de conserver une trace. La plupart des exigences sont encore communiquées oralement, mais si vous ne rédigez pas de documentation comme trace, des litiges surviendront facilement plus tard.

4. Veillez à écrire des commentaires

Ne pas écrire de commentaires, c'est creuser un trou pour soi-même et pour les autres, car au bout d'un certain temps, vous ne comprendrez même plus votre propre code.

5. Ne vous attendez pas à ce que les exigences soient stables

Les exigences produit sont constamment ajustées en fonction des besoins métier. Modifier les exigences est parfaitement normal. Ne vous plaignez pas ; la seule constante dans ce monde, c'est le changement.

6. Le business prime sur la technologie

Si la technologie ne sert pas l'activité de l'entreprise, elle ne vaut rien. Gagner de l'argent est le principe absolu d'une entreprise. Par conséquent, je ne recommande pas à tout le monde de courir après les nouvelles technologies ; accordez plutôt plus d'attention à l'application des technologies matures dans les entreprises commerciales.

7. Ne comptez pas sur la chance

L'endroit où vous sentez vaguement qu'un bug va se produire est exactement celui où un bug se produira certainement.

8. Testez-le d'abord vous-même quelques fois

Ne vous contentez pas de refiler le code aux testeurs dès que vous avez fini de l'écrire. Tout ce qui passe entre vos mains doit être de qualité assurée.

9. Résolvez les problèmes par vous-même autant que possible

Lorsque vous rencontrez un problème que vous ne comprenez pas, essayez d'abord de le résoudre par vous-même (90 % des problèmes peuvent être résolus avec Google, Stack Overflow, etc.). Ne vous contentez pas de prendre une capture d'écran et de la jeter à quelqu'un pour qu'il vous aide à chaque fois. Votre patron et vos collègues ne sont pas là pour réparer vos erreurs. Mais si vous avez vraiment tout gâché, demandez de l'aide dès que possible.

10. Utilisez les nouvelles technologies avec prudence

Ne courez pas après les nouvelles technologies. Les nouvelles technologies sont toutes des versions bêta. Si vous prenez sur vous de les utiliser avant même que les gourous n'aient écrit une documentation d'introduction claire en chinois, vous vous attirez surtout des ennuis.

URL d'origine : http://www.techug.com/post/funny-programmer-pictures-2.html