Préface du traducteur: Après avoir lu cet article, vous pourriez être surpris ou même en colère. Oui, nous avons également été surpris: l'auteur n'aurait, semble-t-il, jamais entendu parler de la hiérarchie au sein de l'équipe, de la définition des tâches avec le statut «faire vite et sans raisonnement». Oui, c'est ça, c'est un texte un peu bizarre. En effet, l'auteur propose au programmeur de jouer le rôle d'un architecte de systèmes - pourquoi alors avez-vous besoin d'un architecte? Mais toutes ces objections ne devraient pas vous cacher l'essentiel - pourquoi nous avons néanmoins pris et traduit ce texte. Il ne s'agit pas de rôles. Ce texte porte sur l'approche professionnelle et la sensibilisation. La vérité est que si vous «faites ce qu'ils disent» sans penser à la signification de vos actions, vous ne deviendrez jamais un grand programmeur.Dites non au code supplémentaire. Tout ce que vous avez à faire est de rassembler les trois lettres et de dire le mot. Essayons de le faire ensemble: "Nooo!"
Mais bon. Pourquoi on fait ça? Après tout, la tâche principale d'un programmeur est d'écrire du code. Mais est-il nécessaire d'écrire le code qui vous est demandé? Non! "Comprendre quand vous ne devriez pas écrire de code est probablement la compétence la plus importante pour un programmeur."
L'art du code lisible .
Nous vous rappelons: pour tous les lecteurs de «Habr» - une remise de 10 000 roubles lors de l'inscription à un cours Skillbox en utilisant le code promo «Habr».
Skillbox recommande: Cours pratique "Mobile Developer PRO" .
La programmation est l'art de la résolution de problèmes. Et vous êtes les maîtres de cet art.
Parfois, en essayant de commencer le plus tôt possible, nous ne pensons à rien d'autre qu'à terminer la tâche. Et cela peut entraîner des problèmes encore plus graves.
À quoi les programmeurs ferment-ils les yeux?
Tout le code que vous écrivez doit être compris par les autres développeurs, ainsi que testé et débogué.
Mais il y a un problème: quoi que vous écriviez, cela compliquera votre logiciel et ajoutera probablement des bugs à l'avenir.
Selon Rich Skrent, le
code est notre ennemi . Voici ce qu'il écrit:
«Le code est mauvais car il commence à pourrir et nécessite un entretien constant. L'ajout de nouvelles fonctionnalités nécessite souvent la modification de l'ancien code. Plus il est grand, plus la probabilité qu'une erreur se produise est élevée et plus il faut de temps pour compiler. Un autre développeur a besoin de plus de temps pour le comprendre. Et si vous avez besoin d'une refactorisation, il y a certainement des fragments qui méritent d'être modifiés. Le code en masse signifie souvent réduire la flexibilité et la fonctionnalité d'un projet. Une solution simple et élégante est plus rapide qu'un code complexe. »
Comment savoir quand vous ne devez pas écrire de code?
Le problème est que les programmeurs exagèrent souvent le nombre de fonctions dont leur application a besoin. En conséquence, de nombreuses sections du code restent incomplètes ou personne ne l'utilise, mais elles compliquent l'application.
Vous devez être clairement conscient de ce dont votre projet a besoin ou non.Un exemple est une application qui ne résout qu'une seule tâche - elle gère le courrier électronique. Pour cela, deux fonctions ont été introduites: l'envoi et la réception de lettres. Vous ne devez pas vous attendre à ce que le gestionnaire de messagerie devienne simultanément un gestionnaire de tâches.
Vous devez fermement dire non aux suggestions pour ajouter des fonctions 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.
Jamais floue votre application.Demandez-vous toujours:
- Quelle fonction devrait être mise en œuvre maintenant?
- Quel code mérite d'être écrit?
Remettez en question les idées qui vous viennent à l'esprit et évaluez les suggestions de l'extérieur. Sinon, le code supplémentaire peut simplement tuer le projet.
Savoir quand vous ne devez pas en ajouter trop gardera la base de code sous contrôle strict.
Au tout début du chemin, le programmeur n'a que deux ou trois fichiers sources. Tout est simple. La compilation et l'exécution de l'application nécessitent un minimum de temps; il est toujours clair où et quoi chercher.
À mesure que l'application se développe, de plus en plus de fichiers de code apparaissent. Ils remplissent le répertoire, chacun avec des centaines de lignes. Pour organiser tout cela correctement, vous devrez créer des répertoires supplémentaires. En même temps, il devient de plus en plus difficile de se rappeler quelles fonctions sont responsables de quoi et quelles actions elles provoquent; attraper des bogues prend également plus de temps. La gestion de projet devient de plus en plus compliquée, pas seulement un, mais plusieurs développeurs sont nécessaires pour garder une trace de tout. En conséquence, les coûts, tant monétaires que temporaires, augmentent et le processus de développement est freiné.
Le projet finit par devenir énorme, l'ajout de chaque nouvelle fonction est donné avec beaucoup de difficulté. Même pour quelque chose de très insignifiant, vous devez passer plusieurs heures. La correction d'erreurs existantes entraîne l'émergence de nouvelles erreurs, les dates de sortie de l'application sont perturbées.
Maintenant, nous devons nous battre pour la durée de vie du projet. Pourquoi?
Le fait est que vous n'avez tout simplement pas compris quand vous n'aviez pas besoin d'ajouter de code supplémentaire, et ils ont répondu «oui» à chaque phrase et idée. Vous étiez aveugle, le désir de créer quelque chose de nouveau vous a fait ignorer des faits importants.
Cela ressemble à un script de film d'horreur, non?
C'est exactement ce qui se passera si vous continuez à dire oui. Essayez de comprendre quand le code ne vaut pas la peine d'être ajouté. Supprimez les inutiles du projet - cela vous facilitera grandement la vie et prolongera l'existence de l'application.
«L'un de mes jours les plus productifs a été celui où j'ai supprimé 1 000 lignes de code.»
- Ken Thompson.
Il est difficile d'apprendre à comprendre lorsque vous n'avez pas besoin d'écrire du code. Mais c'est nécessaire.
Oui, je sais que vous venez de vous lancer sur le chemin 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 dus à 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 une leçon de ce qui précède, votre travail deviendra plus conscient.
Continuez à créer, mais sachez quand dire non.
Skillbox recommande: