Environnement irréprochable: personne ne devrait écrire de code de qualité

Au RIT ++, Nikita Sobolevn ( sobolevn ) a prononcé, comme il l'appelait lui-même, un sermon sur la qualité du code et des processus dans l'entreprise. Particulièrement sensible, versez-vous du thé à la camomille, mais nous ne proposons pas de vous éloigner des écrans. Vous pouvez être en désaccord avec l'une des thèses, insister sur le fait que parler d'émissions de télévision est la clé d'une atmosphère saine dans l'équipe et affirmer que vous n'avez pas besoin d'un cadre strict de linter et de CI pour écrire un bon code. Mais si jamais vous blâmiez les autres d'avoir échoué au travail, vous devriez lire ou regarder l'histoire de Nikita.

Avez-vous déjà travaillé dans un mauvais travail?

J'ai travaillé longtemps. Ma compagnie était terrible. Tout était très mauvais, pour rien, tout sort de l'ordinaire. Nous avions des processus dégoûtants, détestions les clients et les développeurs incompétents. On ne pouvait rien y faire. Quand tout va si mal, vous ne savez pas quoi prendre, par où commencer. Vous vous sentez comme un rouage misérable qui ne peut rien influencer.



Quand je dis que tout va mal, je veux dire que nous avons eu:

• mauvais code - personne ne pensait à la qualité du code, personne ne pouvait même formuler quelle était la qualité du code.
• mauvais processus.
• nous ne pouvions pas communiquer normalement,
• nous n'avons pas fait ce que le client voulait.

Oui, c'était un développement externalisé, mais cela ne l'a pas rendu mauvais. Les gens l'ont fait comme ça.

"Les gens font un mauvais travail, ce sont les gens qui sont à blâmer pour le fait que les processus sont mauvais, le code est mauvais et les clients sont mauvais" - cette pensée m'a tourmenté pendant de nombreuses années. Les gens sont à blâmer pour le fait que je n'aime pas mon travail.



J'ai attribué tous les péchés possibles aux gens et j'ai pensé qu'ils étaient la principale source de problèmes. J'espérais qu'un jour ils changeraient, ou que d'autres apparaîtront, et tout ira bien.

Sérieusement, j'ai pensé au fait que d'autres entreprises emploient des personnes fondamentalement différentes qui diffèrent par leurs qualités internes et leur professionnalisme, et que ces autres personnes sont issues d'un test différent.

Mais à un moment donné, j'ai commencé à deviner que peut-être les gens ne sont pas à blâmer - peut-être une erreur à un niveau différent, quelque part quelque chose s'est mal passé tant plus tôt. Et puis le chemin de la correction apparaît. Ce n'est qu'alors que vous pourrez vous enregistrer en tant que développeur.

J'ai réalisé que nous avons besoin d'une révolution, que tout doit changer: ma façon de travailler, ce que je ressens, qu'aller travailler ne devient pas un test pour moi. Je voulais travailler dans un bon endroit.

Il n'y avait qu'un seul problème - c'était mon entreprise .



Je suis la personne qui a commencé cette révolution.

J'ai réalisé que vous devez tout changer pour profiter à nouveau de votre entreprise préférée. J'adore la programmation, je suis prête à le faire 12 heures par jour et je l'appelle mon repos et mon travail.

Par conséquent, j'ai perçu tous les échecs très douloureusement. Non seulement ils étaient liés à mon entreprise préférée, ils étaient liés à mes finances, à mon sens de soi et à mes relations avec les autres et étaient fortement reflétés dans toute ma vie. Quand quelque chose ne marchait pas pour moi, je ne pouvais pas me reposer, je ne pouvais penser à rien d'autre.

J'ai décidé que la chose la plus importante que je puisse faire maintenant pour améliorer ma vie est de bien faire mon travail. Pour cela, je devais repenser tout le chaos que nous avions et y mettre de l'ordre.



Mais quand vous regardez dans le chaos, vous ne voyez pas de modèles - rien qui n'indiquerait comment cela devrait être.

Créer de l'ordre à partir du chaos est un acte de création difficile.

Vous devez commencer dès le début pour comprendre quand tout s'est envolé dans le chaos. Vous devez déterminer une nouvelle commande et vous expliquer quoi faire. Ce sont de beaux mots: «Faisons tout bien!». Mais vous venez travailler et vous ne comprenez pas vraiment quoi entreprendre pour tout changer, il n'y a pas d'idées.

L'éducation que vous avez reçue et les livres que vous lisez n'aident pas, car tout ce que vous avez fait avant que vous avez appris de ces livres et de cette éducation.

Énoncé du problème

Alors j'ai pensé - quel est le plus gros problème? Où est le point le plus douloureux qui ne permet pas de vivre et de travailler? J'ai réalisé qu'il s'agit d'un énoncé du problème . Pour moi, définir une tâche a toujours été assez facultatif.

Je pense que beaucoup d'entre vous ont vu la tâche d'une seule rubrique "Corriger le bug sur la prod." Nous en avions beaucoup, je les ai écrits sur une seule ligne, puis les gens ont fait quelque chose de mal et ont essayé de le réparer. J'ai pensé: «Pourquoi ne pensent-ils pas de leur propre tête? Que fais-tu du tout? Vous devez corriger un bug simple et ne pas faire toutes ces bêtises. "

Ensuite, je ne me suis pas rendu compte que j'avais vraiment mal réglé les tâches. Mais à un moment donné, j'ai toujours réalisé que je devais le faire d'une manière complètement différente, et j'ai développé plusieurs principes.



Les tâches doivent être courtes . Pas en termes de description de la façon de «corriger un bogue sur la prod», mais de nature courte. De petites et courtes tâches sont pratiques à réaliser. Ils sont compréhensibles par tous: un débutant, un développeur moyen et expérimenté. Tout le monde peut comprendre une telle tâche et le faire, par exemple, en une demi-journée de travail. Vous pouvez commencer par cela.

Les tâches doivent être ordonnées . Quand ils définissent des tâches, ils ne pensent souvent pas dans quel ordre ils doivent être faits. Mais les tâches peuvent se bloquer, se paralléliser ou ajouter de la complexité à d'autres tâches si elles sont effectuées à l'avance, etc.

Très peu est dit sur l'ordre des tâches: elles sont amenées à Jira ou à Trello, puis elles sont emmenées de là. Mais peu pensent, et dans quel ordre, pourquoi et pourquoi l'ordre est juste ça.

Toutes les tâches doivent être individuelles . Qu'est-ce que cela signifie? Les tâches sont des entités qui existent dans un projet et appartiennent toujours à quelqu'un. Parfois, dans la description du problème, vous pouvez trouver: «Sergey, Masha, veuillez corriger cela. Vous savez comment le faire. " Vous ne pouvez pas faire cela, vous devez donner tout le contexte pour que cette tâche devienne individuelle en elle-même, afin que toute personne qui la lit puisse l'accomplir. De sorte qu'il n'y a pas de connaissances dispersées dispersées sur le projet, et il n'y a pas de significations cachées dans le cadre de cette tâche.

Lorsque les tâches sont devenues individuelles, courtes et ordonnées, les gens ont commencé à les faire comme je le souhaitais.

En changeant simplement le mode de communication, je me suis assuré que les personnes mêmes qui avaient fait ce non-sens commençaient à faire ce que je voulais - n'est-ce pas magique? N'est-ce pas la preuve que beaucoup de choses sont faciles à changer. Et j'ai commencé à approfondir cette question.

Nous avons souvent échoué le client, n'avons pas fait ce qui lui serait bénéfique. Je pensais que si les développeurs commençaient à comprendre nos tâches et à les faire comme ils le devraient, peuvent-ils comprendre ce que le client veut vraiment et faire comme le veut le client?

J'ai essayé de combiner cela en une sorte de figure à deux visages qui, d'une part, pense comme un développeur, d'autre part - comme un client.



Ce n'est pas une nouvelle tâche. En général, cette approche est appelée conception pilotée par domaine et a été appliquée avec succès pendant de nombreuses années. J'ai décidé de prendre le meilleur - un moyen de communication, des outils, des technologies et d'essayer de faire comprendre aux développeurs ce qui doit être fait pour satisfaire les désirs du client.

La tâche a été très difficile et je travaille toujours sur sa solution. Mais j'ai développé une formule simple pour moi.

Exigences . Tout commence par eux, le client exprime sa volonté à nous, développeurs, sous forme d'exigences. Le client dit conditionnellement: "J'exige que la page de connexion fonctionne." Leur prise de conscience commence, gribouillant sous forme de tableaux, de listes, de graphiques, etc. Les exigences restent avec vous comme la partie la plus importante de votre projet. C'est ce que vous faites au plus haut niveau.

Mais ces exigences ne sont pas exploitables pour le développeur, elles sont trop élevées et brutes. Pour commencer, le programmeur a besoin de documentation.

La documentation et les exigences sont des frères jumeaux, c'est une double unité. Exigences - c'est ce que vous devez faire et la documentation - comment le faire.

Lorsque j'ai réalisé qu'en principe, la documentation peut être générée à partir des exigences, cela est devenu une partie importante de notre processus opérationnel. Nous avons appris à enregistrer les exigences dans un format spécial et à générer de la documentation.

Tests . La prochaine étape logique consiste à vérifier que cela fonctionne. Nous avons commencé à tester nos exigences pour nous assurer que nous faisons vraiment ce qui est nécessaire.

La chose la plus intéressante est que je n'ai rien inventé - je n'ai pas écrit une seule ligne de code pour que cela fonctionne. Je viens de prendre les technologies existantes et de recevoir: des exigences, ce sont de la documentation, ce sont des tests.

La prochaine étape logique consistait à extraire le code de l'ensemble, car le code est ce dans quoi nous sommes directement impliqués.

Code - pour le bien de laquelle tout est réellement démarré. Pour que le client et le développeur se connectent, il semblerait que vous devez entrer dans l'un d'eux dans la tête et vous assurer qu'ils se comprennent. Mais pour entrer dans la tête, vous pouvez prendre les mêmes outils et les connecter pour que le développeur commence à comprendre ce qui se passe. Ici, vous pouvez lire comment je le fais dans la pratique.

Dès que nous avons combiné (le Code en est un!) Les développeurs et le client à l'aide d'une imbrication si ingénieuse de différentes entités, nous avons atteint un objectif très important: nos développeurs ont finalement commencé à faire ce dont l'entreprise avait besoin . Ils ont arrêté d'introduire quelque chose comme ça, parce qu'ils ont vu les exigences et les ont comprises, ont compris ce qui devait être fait.

Pour nous assurer que nous exécutons, nous avons des tests qui sont écrits sous forme d'exigences, et ces exigences sont suffisamment claires pour être implémentées dans un langage compréhensible dans le code, et écrire du bon code en fonction de ces exigences.

La communication

J'ai déjà mentionné à plusieurs reprises la «communication». J'adore parler avec mes amis et ma famille, mais pas au travail. Au travail, je dois communiquer avec les gens - je ne les ai pas choisis sur cette base. Très souvent, la communication au travail n'aide pas .

Nous communiquons tous avec des collègues sur des sujets qui ne fonctionnent pas (discuter des émissions de télévision, etc.), parce que nous sommes des gens. Heureusement, cette faille est réparable. Afin de comprendre à quel point la communication est vraiment désastreuse pour nous, vous pouvez consulter divers exemples.

Tout d'abord, les gens se distraient et se déchirent d'un état de flux. L'homme vient d'arriver et dit quelque chose - que dois-je faire avec ça maintenant? Pourquoi m'a-t-il dit qu'il voulait transmettre cela?

Ou des rassemblements. Je les déteste, je me sens toujours comme un idiot quand je m'assois en réunion. Tout le monde semble comprendre quelque chose, ils ont des visages intelligents, et j'en manque un et je pense quand cela se terminera. Je veux partir parce que tout ce dont nous discutons peut être discuté beaucoup plus rapidement.

Les rallyes volent énormément de temps et ne servent à rien.

Il y a plusieurs autres problèmes importants, par exemple, les gens commencent à jurer lors de ces rassemblements. Imaginez que vous étiez placé dans une petite pièce pleine de gens que vous ne voulez pas vraiment voir. Vous voulez partir, et ces gens vous font prendre des décisions sérieuses. Tout naturellement, les abus commencent - d'abord l'agression passive, puis les insultes évidentes. Malheureusement, rien ne peut être fait avec cela, car les gens sont des êtres en conflit. Peu importe comment vous essayez de modérer la situation, peu importe comment vous choisissez de bonnes personnes qui ne jurent pas - les gens jurent, et c'est normal .

Il y a un autre problème dans notre entreprise - les gens disparaissent . Votre front-end ou devops peut facilement cesser de répondre un jour. En particulier, les personnes qui travaillent à distance peuvent simplement éteindre le téléphone et mettre fin à la conversation unilatéralement.

Ces problèmes et certains autres semblent insolubles. Vous ne pouvez pas apprendre à tout le monde à être bon, non conflictuel, responsable - c'est tout simplement impossible.

Mais vous pouvez vivre avec. En étant réaliste, vous pouvez comprendre que la vie est comme ça: les gens vont disparaître, maudire, ne pas vouloir communiquer avec vous - c'est normal. J'ai résolu ce problème comme suit - communication structurée.



Pour structurer la communication, il suffit de prendre deux étapes:

• Allez dans Telegram maintenant et supprimez-le. Une fois que vous aurez supprimé toutes vos pages sur les réseaux sociaux, les gens ne pourront plus vous écrire.
• Après cela, démarrez un canal et dites que vous ne pouvez communiquer que de cette façon.

Lorsque vous êtes en mesure de dicter votre volonté à d'autres personnes, vous leur apprenez à communiquer. Vous montrez que la communication doit être structurée et utile pour tous les participants .

Nous avons choisi la communication via GitLab. Si vous avez une question, posez-la dans GitLab. Si vous voulez poser une question étrange, posez-la ici. Si vous comprenez qu'il n'y a aucun endroit où vous pouvez poser une telle question, il n'est peut-être pas nécessaire de la poser.

Nous ne communiquons que sur des sujets de travail . Si quelqu'un veut discuter du Game of Thrones - désolé, nous travaillons et discutons du Game of Thrones avec vos amis. Si vous souhaitez discuter d'une nouvelle technologie, créer un ticket, discutons-en: cela bénéficiera peut-être au projet. Mais "Game of Thrones" n'apportera certainement pas d'avantages au projet.

Une communication structurée rend différentes personnes identiques. GitLab a même des avatars à peu près les mêmes - l'un a la lettre K, l'autre C, et je ne sais pas qui sont ces gens. Peu m'importe ce qu'ils sont, l'essentiel est qu'ils communiquent au sein de la structure.

Après avoir structuré la communication, établi un travail avec le client, appris à écrire des tickets compréhensibles, il est temps de passer au code.

Code

Et ici, un nouveau problème attend: les gens ne savent pas écrire du code, et c'est normal . J'avais l'habitude de penser que d'autres écrivaient du mauvais code, et je suis bon. Mais j'ai réalisé que j'écrivais moi-même du mauvais code. Et après un certain temps, j'ai réalisé que tout le monde écrivait du mauvais code , et c'est très bien.

Les gens ne sont pas faits pour écrire du code. La programmation est un environnement agressif auquel une personne n'est pas prédisposée. Le code a beaucoup de complexités: l'architecture et une énorme quantité d'informations. Dans les systèmes distribués, c'est terrible en général. Il est difficile pour une personne de faire face à la circulation de l'information. Et c'est normal.

Mais si c'est le cas, vous pouvez faire quelque chose avec cela et apprendre à travailler dans ces conditions.



Pour travailler avec cela, vous avez besoin de rigueur - CI et des tests qui seront aussi stricts que possible sur ce que vous faites. Ce doit être le Jugement dernier - un outil qui répond à la question, bon ou mauvais. Ce n'est qu'en le regardant que l'œil qui voit tout de CI dira si votre travail ira au maître ou restera quelque part sur scène.

Un tel IC, bien sûr, devrait être inévitable. Dès que quelqu'un obtient le droit exclusif de s'engager à maîtriser, toutes les tentatives de création de processus s'effondrent, car cette personne commence à faire toutes sortes de bêtises.

Le CI inévitable et rigoureux fournit des fonctionnalités plus intéressantes. C'est une opportunité à développer, car maintenant il y a une barre de base à partir de laquelle vous pouvez construire: chaque morceau de code suivant est meilleur que le précédent. Chaque morceau de code suivant ajoute de la valeur au projet et améliore le CI. Chaque morceau de code suivant est une étape vers le développement.

Une fois la fondation prête, vous pouvez continuer.

Mais les gens feront toujours des erreurs, car aucun CI, même configuré de la manière la plus rigoureuse, ne peut détecter toutes les erreurs . Et ils apparaîtront dans des endroits auxquels personne d'autre ne pensera.

Que peut-on faire à ce sujet? Vous pouvez revenir à la tactique habituelle et dire: «Vous avez fait une erreur, corrigez-la. Vous avez écrit un mauvais code - allez apprendre à écrire du code. " C'est une mauvaise voie qui ne mène pas au développement.

Pour vraiment écrire correctement et développer votre produit, vous avez besoin d'une nouvelle approche et d'une nouvelle mentalité.

Environnement irréprochable

J'ai appelé cette approche un environnement irréprochable - cela signifie que je ne blâme jamais les gens pour rien . Si un bogue est entré dans votre projet, c'est un problème de projet. Ce bug doit être corrigé afin qu'il ne se reproduise plus. S'il s'agit d'un bogue dans le code, vous devez écrire un test de régression. S'il s'agit d'un bogue dans l'infrastructure du projet, vous devez écrire un outil qui évitera ce bogue.



Lorsque vous commencez non seulement à corriger des bogues et à espérer que tout ne se désagrège pas en production, mais à les corriger au niveau du système, vous commencez à créer et à créer - créer de nouveaux outils, développer de nouvelles approches et modèles architecturaux. Vous commencez à penser avec votre tête et assurez-vous que les bogues ne se reproduisent pas.

Un travail constant sur les erreurs amène le développeur à un niveau fondamentalement différent. Vous commencez à inventer des outils pour les développeurs, à les implémenter, à promouvoir, etc.

La création dont je parle maintenant est massive. Lorsque vous essayez d'utiliser cette approche, vous découvrirez que tout ce qui existe maintenant, en particulier pour certains langages de programmation, n'est pas assez strict.

Une fois, je me suis demandé si je pouvais écrire un linter qui ferait écrire à tout le monde le même code. J'étais très strict et incluais toutes les règles possibles que je pouvais trouver. Mais les gens écrivent toujours un code différent . C'est très similaire, mais je peux toujours comprendre que ce code a été écrit par différentes personnes. Donc, mon linter n'est pas encore assez strict - attendez les nouvelles versions.

L'approche reste, on attend que la machine réponde, le programme est bien fait ou pas. Et cela fonctionne, car ces outils aident au travail.

Mais nous ne devons pas oublier que les gens sont des participants nécessaires au processus . Quels que soient les excellents paramètres techniques que vous effectuez, si l'apparence expérimentée de la personne n'a pas traversé votre code, il peut toujours y avoir quelque chose qui fait que vos cheveux restent debout, bien que CI soit passé.

D'une part, nous avons réglé notre problème et nous avons rejeté un très mauvais code. Mais, néanmoins, nous ne sommes pas complètement isolés de lui. Un processus de révision du code est requis . Si le code n'a pas réussi l'examen du code, alors tout ce que vous avez fait auparavant est inutile.

Chaque étape suivante n'a de sens que lorsqu'il existe une base pour la précédente.

, , , - CI . , , . - — .



— .

— . . : « , ?!» , , .

: , . , , , — : . , .

- — . , , , : « ? . , - ». — , - , - . .

— , — .

— , . , .

, , . . . , .

, , , , . , , , .

, , , , , , , .

— . , — , , , .

, . , , . open source , .

. , , , — .

. , , , , . , — , — . , .

. , . : — , — . .

. , , — ? , , , . .

. , , — , . - , , . , . open source.

. , , , , , . , , , .. !

. : . - , . , , . . , , . .

. , , - , . -, .

. , . - — , . , .

, . , . , .

Agile , . QualityConf , ++, — . , , .