Tout ce qui est vieux redevient un jour nouveau. Il arrive un moment où même des programmeurs expérimentés marchent sur le même chemin. Il est impossible d'énumérer toutes les «règles non écrites» d'une discipline, en partie parce que nombre d'entre elles ne sont même pas des règles . C'est souvent un moyen de reformuler des vérités abstraites et éternelles.

Marie Kondo a fait carrière en appliquant les principes universels d'efficacité, de propreté et de beauté à la tâche ménagère de l'entretien ménager. Il s'avère que beaucoup de gens ont juste besoin d'un traducteur entre la sagesse éternelle et leur vie quotidienne afin de vraiment «comprendre» le sens de ce qui se passe autour (voir aussi «Zen et l'art de l'entretien des motos» ). Nous espérons sincèrement que vous apprécierez notre tentative de faire de même pour la programmation.

1. Aucun dépôt le vendredi

Même si vous disposez d'un système de déploiement continu. Le vendredi est le jour le plus inapproprié pour démarrer le master, pour la raison évidente: il ne reste qu'une demi-journée pour réparer d'éventuels jambages. Habituellement, après les mises à jour, des flambées de tickets de support technique sont observées, en particulier après la sortie de nouvelles fonctions et, inévitablement, de nouvelles erreurs. Les vendredis sont somnolents, inattentifs, ont tendance à tout remettre à plus tard ... vous savez comment ça se passe.

Personne n'est à l'abri des forces d'un autre monde qui choisissent toujours vendredi pour les bugs! Par conséquent, observez les meilleures pratiques et, si vous n'êtes pas sûr, faites attention aux leaders de l'industrie. Par exemple, Apple serait censé publier les mardis , laissant suffisamment de temps des deux côtés d'un événement aussi critique que le Deploy: lundi pour tester et détecter les derniers bugs, et du mercredi au vendredi pour apporter des modifications urgentes. Et avec les revenus d'Apple, vous vous rendez compte que leur modèle de déploiement est lavé dans le sang et la sueur.

2. Sauvegardes régulières

Il est difficile de surestimer l'importance des sauvegardes régulières. Toute notre industrie repose sur un système de sauvegarde progressif abstrait. Bien sûr, je parle de Git, mais ce n'est pas suffisant. Votre base de données, clés cryptographiques, fichiers de configuration, images VM, images / vidéos ... même les packages importés doivent être stockés de manière sécurisée où ils seront toujours disponibles en cas d'urgence. Si vous ne disposez pas d'un système automatisé, laissez au moins quelques employés archiver régulièrement le dossier de travail et le copier sur un disque externe. Oui, juste un couple - la redondance n'est pas superflue.

Vous n'aurez probablement jamais besoin de 9 sauvegardes sur 10. Mais un jour, comme je le suis aujourd'hui, vous voudrez revenir dans le passé et savoir exactement quand nous avons fait cette erreur discrète mais complètement mortelle que personne n'a jamais remarquée?! Ensuite, vous serez heureux d'avoir pris le temps de sauvegarder. Ou, vous savez, lorsqu'un nouvel employé supprime accidentellement 100 000 lignes de code. Ça arrive. Nous n'avons pas de rancune envers les gens, mais apprenons des erreurs. Faites des sauvegardes, même si c'est difficile!

3. Obtenez les spécifications complètes avant de commencer le développement

Je souffre souvent du syndrome «commencé trop tôt». Plus d'une fois, j'ai dû réécrire de gros fragments de code, car je n'ai pas posé suffisamment de questions lors des premières rencontres avec le client, où il a tracé les contours de la tâche. Notre cerveau est vraiment minuscule, et il déteste la précision, surtout lorsque la précision est complexe et coûteuse (lire: nécessaire pour le client). Il trouve des similitudes où il n'est même pas proche. Cela est particulièrement vrai dans la conception de programmes - dans une application assez complexe, dix boutons similaires effectuent une douzaine de tâches complètement différentes. Avant de commencer à coder, vous devez saisir ces subtilités si vous souhaitez tirer le meilleur parti de votre temps et du temps des clients. Ne soyez pas comme moi ou mon cerveau. Dessinez tout sur du papier, assurez-vous que tout est clair, et si nécessaire, vous pouvez redessiner le système à partir de zéro (en tenant compte du temps suffisant pour la préparation - nous sommes tous humains).

Personne n'atteindra jamais la perfection dans ce processus. Je compte encore trop sur les conjectures. Mais depuis que j'ai réalisé le problème, les hypothèses non fondées sont devenues moins nombreuses. Il doit être pensé comme un ordinateur: sans équivoque et irréfléchi dans sa logique. Dans le concept de conception de système, étudiez les situations frontalières, soyez un «défenseur des testeurs» - et vous trouverez probablement une conception qui élimine immédiatement des classes entières d'erreurs autorisées dans une conception moins réfléchie.

4. Si vous voyez des bêtises sans importance, dites-le

Essayez d'arrêter doucement ou d'empêcher les discussions improductives avant qu'elles ne deviennent incontrôlables. Notre temps de travail est presque aussi précieux que les 3-8 heures que nous passons sans connaissance chaque nuit - c'est-à-dire, c'est très important! D'un point de vue commercial, plus il y a de personnes, plus la réunion devrait être efficace, car le salaire horaire est multiplié par 20 à 500 développeurs dans une seule salle / salle de conférence / etc. C'est de l'argent fou, surtout en Californie ensoleillée avec ses salaires. Le temps c'est de l'argent! Et nous travaillons cet argent en inventant des astuces intellectuelles autour de monstres avec des tentacules qui sont cachés derrière chaque base de code et attendons de briser les attentes innocentes avec des bogues et des plantages cruels.

Mais nous ne nous promenons pas toujours dans des catacombes de code oubliées avec une torche tremblante et un front en sueur. Parfois, nous nous asseyons lors de réunions ou discutons de quelque chose de tendu en dehors des réunions formelles. Slack est célèbre pour augmenter la cohésion de l'équipe, mais à quel prix (autre qu'un abonnement mensuel)? D'après mon expérience, Slack augmente considérablement le «temps vide de sens» de votre cerveau - le temps nécessaire pour filtrer un autre flux constant d'alertes sonores (souvent inappropriées) lorsque vous essayez de faire ce que l'entreprise vous paie; c'est-à-dire développer et réparer du code utile. Et les gens tombent assez facilement dans des disputes inutiles.

Vous pouvez demander de mettre fin à la discussion si cela prend trop de temps. De nos jours, les enfants aiment dire que «le présent voit le présent»: des gens qui font vraiment du vrai travail, aident les clients, les utilisateurs et le monde - ils vous seront reconnaissants de vous demander de mettre fin à la discussion sur la question de savoir si le nouveau réfrigérateur doit être noir ou chromé. "Oui, vous jetez une pièce, quelle est la différence ... nous avons des problèmes plus graves." Et bon nombre des personnes qui font attention à vous appartiendront au leadership.

Merci de vous joindre à moi pour ce voyage. Puissiez-vous voir la même sagesse que ceux qui ont écrit ces conseils avant nous. Et s'il vous plaît, si selon votre expérience, vous avez appris d'autres règles tacites, écrivez-les et faites-le nous savoir!