Préface du traducteur: Après avoir lu cet article, vous pourriez être surpris, voire en colère. Oui, nous avons aussi été surpris : l'auteur n'aurait apparemment jamais entendu parler de la hiérarchie dans l'équipe, de la définition de tâches avec le statut « faites-le rapidement et sans raisonnement ». Oui, c'est vrai, c'est un texte un peu étrange. En effet, l'auteur suggère que le programmeur assume le rôle d'un architecte système - pourquoi alors avez-vous besoin d'un architecte ? Mais toutes ces objections ne doivent pas vous aveugler sur l’essentiel : pourquoi nous avons néanmoins repris et traduit ce texte. Il ne parle pas de rôles. Ce texte porte sur une démarche professionnelle et une prise de conscience. La vérité est que tant que vous « faites ce qu’on vous dit » sans réfléchir au sens de vos actions, vous ne deviendrez jamais un grand programmeur.
Dites non au code inutile. Tout ce que vous avez à faire est d’assembler trois lettres et de prononcer le mot. Essayons de le faire ensemble : "Nooooon !"
Mais attendez. Pourquoi fait-on ça? Après tout, la tâche principale d’un programmeur est d’écrire du code. Mais avez-vous besoin d’écrire le code qui vous est demandé ? Non! « Comprendre quand il ne faut pas écrire de code est probablement la compétence la plus importante pour un programmeur. » .
Nous rappelons: pour tous les lecteurs de "Habr" - une remise de 10 000 roubles lors de l'inscription à n'importe quel cours Skillbox en utilisant le code promotionnel "Habr".
Skillbox vous recommande : Cours pratique .
La programmation est l'art de résoudre des problèmes. Et vous êtes maîtres de cet art.
Parfois, dans le but de commencer à travailler le plus rapidement possible, nous ne pensons à rien d'autre qu'à terminer la tâche à accomplir. Et cela peut entraîner des problèmes encore plus graves.
Sur quoi les programmeurs ferment-ils les yeux ?
Tout le code que vous écrivez doit être compréhensible pour les autres développeurs et doit être testé et débogué.
Mais il y a un problème : quoi que vous écriviez, cela compliquera votre logiciel et introduira probablement des bugs dans le futur.
Selon Rich Skrent, . Voici ce qu'il écrit:
« Le code est mauvais car il commence à pourrir et nécessite une maintenance constante. L'ajout de nouvelles fonctionnalités nécessite souvent de modifier l'ancien code. Plus il est grand, plus la probabilité qu'une erreur se produise est élevée et plus la compilation prend du temps. Il faut plus de temps à un autre développeur pour le comprendre. Et si une refactorisation est nécessaire, il y aura certainement des fragments qui mériteront d'être modifiés. Un code volumineux signifie souvent une flexibilité et une fonctionnalité réduites du projet. Une solution simple et élégante est plus rapide qu’un code complexe.
Comment savoir quand ne pas écrire de code ?
Le problème est que les programmeurs exagèrent souvent le nombre de fonctionnalités dont leurs applications ont besoin. En conséquence, de nombreuses sections de code restent inachevées ou personne ne les utilise, mais elles compliquent l'application.
Vous devez clairement comprendre ce dont votre projet a besoin et ce dont il n’a pas besoin.
Un exemple est une application qui ne résout qu'une seule tâche : la gestion du courrier électronique. A cet effet, deux fonctions ont été introduites : l'envoi et la réception de lettres. Il ne faut pas s’attendre à ce que le gestionnaire de messagerie devienne en même temps un gestionnaire de tâches.
Vous devez dire fermement « non » aux propositions d'ajout de fonctionnalités qui ne sont pas liées à la tâche principale de l'application. C’est exactement le moment où il devient clair qu’aucun code supplémentaire n’est nécessaire.
Ne perdez jamais le focus de votre candidature.
Demandez-vous toujours :
— Quelle fonction faut-il implémenter maintenant ?
— Quel code dois-je écrire ?
Remettez en question les idées qui vous viennent à l’esprit et évaluez les suggestions venant de l’extérieur. Sinon, du code supplémentaire peut simplement tuer le projet.
Savoir quand ne pas ajouter d’éléments inutiles vous aidera à garder votre base de code sous contrôle.
Au tout début du chemin, le programmeur ne dispose que de deux ou trois fichiers sources. C'est simple. La compilation et le lancement de l'application nécessitent un minimum de temps ; Il est toujours clair où et quoi chercher.
Au fur et à mesure que l'application se développe, de plus en plus de fichiers de code apparaissent. Ils remplissent le catalogue, chacun avec des centaines de lignes. Afin d'organiser correctement tout cela, vous devrez créer des répertoires supplémentaires. Dans le même temps, il devient de plus en plus difficile de se rappeler quelles fonctions sont responsables de quoi et quelles actions les provoquent ; attraper des bugs prend également plus de temps. La gestion de projet devient également plus complexe : non pas un, mais plusieurs développeurs sont nécessaires pour tout suivre. En conséquence, les coûts, tant monétaires que temporels, augmentent et le processus de développement ralentit.
Le projet finit par devenir énorme et l'ajout de chaque nouvelle fonctionnalité demande de plus en plus d'efforts. Même pour quelque chose de très insignifiant, il faut y consacrer plusieurs heures. La correction des erreurs existantes entraîne l'apparition de nouvelles et les délais de publication des applications ne sont pas respectés.
Il faut maintenant se battre pour la vie du projet. Pourquoi?
Le fait est que vous n'avez tout simplement pas compris quand vous ne devriez pas ajouter de code supplémentaire et que vous avez répondu « oui » à chaque suggestion et idée. Vous étiez aveugle, le désir de créer de nouvelles choses vous faisait ignorer des faits importants.
Cela ressemble à un scénario de film d’horreur, non ?
C’est exactement ce qui arrivera si vous continuez à dire oui. Essayez de comprendre quand le code ne doit pas être ajouté. Supprimez les éléments inutiles du projet - cela vous facilitera grandement la vie et prolongera la durée de vie de l'application.
"L'un de mes jours les plus productifs a été celui où j'ai supprimé 1000 XNUMX lignes de code."
—Ken Thompson.
Apprendre quand ne pas écrire de code est difficile. Mais c'est nécessaire.
Oui, je sais que vous venez de vous lancer sur la voie d'un développeur et que vous souhaitez écrire du code. C'est bien, ne perdez pas cette première impression, mais ne perdez pas de vue les facteurs importants à cause de l'enthousiasme. Nous avons tout réalisé par essais et erreurs. Vous ferez également des erreurs et en tirerez des leçons. Mais si vous pouvez tirer les leçons de ce qui précède, votre travail deviendra plus conscient.
Continuez à créer, mais sachez quand dire non.
Skillbox vous recommande :
- Cours appliqué en ligne .
- Cours en ligne .
- Cours pratique de l'année .
Source: habr.com