Imaginez une seule chose qui rendra votre code plus compréhensible, et cela vous aidera également à comprendre le code de quelqu'un d'autre beaucoup plus facilement et vous «gâcherez» le code de quelqu'un d'autre qui a été écrit avant de rejoindre l'entreprise. Et la meilleure chose est que vous comprendrez toujours s'il vaut la peine de le changer ou mieux de ne pas le toucher. Présenté?!
Le début est trop prometteur et vous avez déjà ressenti une sorte de divorce.
Maintenant, sérieusement.
J'écris du code pour moi sur mon propre projet et dans une entreprise où j'en programme plus d'un. Et j'ai commencé à remarquer que même lorsque je travaille seul et que je reviens à l'ancienne section du code, il y a des pensées: "Pourquoi ai-je écrit comme ça ici, est-ce mal?" Et soudain, si je veux changer, une situation peut se produire maintenant, quelque chose ne fonctionne pas et la décision que j'ai prise quand j'ai écrit cet ancien code était optimale.
Il est donc important d'écrire dans les commentaires "Pourquoi", "Pourquoi ai-je pris cette décision quand j'ai programmé?", "Pourquoi parmi toutes les options j'ai choisi exactement l'implémentation sur laquelle je me suis arrêté?". Surtout si vous travaillez en équipe. J'ai eu une situation où un morceau de code qu'une autre personne a écrit n'a pas pleinement mis en œuvre ce dont j'avais besoin et maintenant j'ai une question logique: "Pourquoi a-t-il fait ça?", Mais nous ne pouvons pas nous souvenir de tout et avons logiquement reçu la réponse: " Je ne me souviens pas pourquoi. Quelque chose n’a pas grandi ensemble. " Et vous vous retrouvez dans une situation de blocage, l'option qui est maintenant disponible et d'autre part a peur de commencer à vous réécrire, parce que vous ne savez pas d'où viendra le problème, peut-être rencontrerez-vous le même problème insoluble que votre collègue a rencontré, ou peut-être que vous ne le ferez pas . Qui sait ça maintenant?! Et cela conduit au fait que certaines parties du code deviennent «intouchables», vous avez peur de les toucher.
Je pense donc qu'écrire la raison du choix d'une option donne certains bonus.
- Même lorsque vous travaillez seul, vous pouvez immédiatement comprendre si vous connaissez la raison. Vous êtes juste devenu stupide lorsque vous avez écrit ce code ou c'est un code adéquat, compte tenu du contexte.
- Vous grandissez en tant que programmeur, et vous pouvez changer la décision que vous avez prise par inexpérience, car vous savez pourquoi elle est là.
- Au fil du temps, la raison même pour laquelle un tel code est écrit peut "sombrer dans l'oubli" et maintenant quand vous voyez cela, vous comprenez que vous pouvez vous en séparer avec un esprit calme, si vous ne l'écrivez pas, alors il restera ici, peur de blesser quelque chose.
- Vous pouvez regarder l'ancien code écrit devant vous d'une nouvelle manière. Si tout à l'heure, avec un regard arrogant, vous venez de le frapper, maintenant vous comprenez que dans la situation que les programmeurs étaient devant vous, c'était une décision très correcte.
- Sauve de la situation lorsque vous nettoyez, la décision de la béquille qui était devant vous, et il s'avère que vous avez ouvert la boîte de la pandore, car seule cette béquille s'est tenue à la mort universelle.
- Lorsque vous écrivez pourquoi, un autre développeur qui voit cela pourra réécrire, sachant comment résoudre le problème que vous avez résolu plus efficacement.
En conclusion, je veux dire. Le code reste imprimé pendant longtemps, mais les pensées et les raisons des gens qui à un moment donné dans une situation particulière, il a été pris pour s'évaporer le lendemain.