Schuldlose Umgebung: Niemand sollte Qualitätscode schreiben

Bei RIT ++ hielt Nikita Sobolevn ( sobolevn ), wie er es selbst nannte, eine Predigt über die Qualität von Code und Prozessen im Unternehmen. Besonders empfindlich, gießen Sie sich bitte Kamillentee ein, aber wir bieten nicht an, sich von den Bildschirmen zu entfernen. Sie können mit keiner der Thesen einverstanden sein, darauf bestehen, dass das Sprechen über TV-Shows der Schlüssel zu einer gesunden Atmosphäre im Team ist, und behaupten, dass Sie keinen strengen Rahmen von Linter und CI benötigen, um guten Code zu schreiben. Aber wenn Sie jemals andere für Fehler bei der Arbeit verantwortlich gemacht haben, sollten Sie Nikitas Geschichte lesen oder ansehen .

Haben Sie jemals in einem schlechten Job gearbeitet?

Ich habe lange gearbeitet. Meine Firma war schrecklich. Alles war sehr schlecht, für nichts ist alles ungewöhnlich. Wir hatten widerliche Prozesse, hassten Kunden und unfähige Entwickler. Daran konnte nichts geändert werden. Wenn alles so schlecht ist, wissen Sie einfach nicht, was Sie nehmen sollen und wo Sie anfangen sollen. Sie fühlen sich wie ein elendes Zahnrad, das nichts beeinflussen kann.



Wenn ich sage, dass alles schlecht ist, meine ich, dass wir:

• schlechter Code - niemand dachte über die Qualität des Codes nach, niemand konnte sogar formulieren, wie die Qualität des Codes ist.
• schlechte Prozesse.
• wir konnten nicht normal kommunizieren,
• Wir haben nicht getan, was der Kunde wollte.

Ja, es war eine ausgelagerte Entwicklung, aber das hat es nicht schlecht gemacht. Die Leute haben sie so gemacht.

„Die Leute machen einen schlechten Job, es sind die Leute, die dafür verantwortlich sind, dass die Prozesse schlecht sind, der Code schlecht und die Kunden schlecht“ - dieser Gedanke quälte mich viele Jahre lang. Die Leute sind schuld daran, dass ich meine Arbeit nicht genieße.



Ich schrieb den Menschen alle möglichen Sünden zu und dachte, dass sie die Hauptursache für Probleme seien. Ich hatte gehofft, dass sie sich eines Tages ändern oder andere auftauchen und alles in Ordnung sein wird.

In aller Ernsthaftigkeit dachte ich darüber nach, dass andere Unternehmen grundlegend andere Leute beschäftigen, die sich in ihren internen Qualitäten und ihrer Professionalität unterscheiden, und dass diese anderen Leute aus einem anderen Test stammen.

Aber irgendwann begann ich zu vermuten, dass die Leute vielleicht nicht schuld sind - vielleicht ein Fehler auf einer anderen Ebene, irgendwo ging etwas so viel früher schief. Und dann erscheint der Weg zur Korrektur. Nur dann können Sie sich als Entwickler retten.

Mir wurde klar, dass wir eine Revolution brauchen, dass sich alles ändern muss: Die Art und Weise, wie ich arbeite, wie ich mich fühle, dass das Gehen zur Arbeit für mich kein Test wird. Ich wollte an einem guten Ort arbeiten.

Es gab nur ein Problem - es war meine Firma .



Ich bin die Person, die diese Revolution begonnen hat.

Mir wurde klar, dass Sie alles ändern müssen, um Ihr Lieblingsgeschäft wieder zu genießen. Ich liebe das Programmieren, ich bin bereit, es 12 Stunden am Tag zu tun und nenne es meine Ruhe und meine Arbeit.

Daher habe ich alle Fehler sehr schmerzhaft wahrgenommen. Sie waren nicht nur mit meinem Lieblingsgeschäft verbunden, sondern auch mit meinen Finanzen, meinem Selbstbewusstsein und meinen Beziehungen zu anderen Menschen und spiegelten sich stark in meinem ganzen Leben wider. Wenn etwas für mich nicht geklappt hat, konnte ich mich nicht ausruhen, mir fiel nichts anderes ein.

Ich entschied, dass das Wichtigste, was ich jetzt tun kann, um mein Leben zu verbessern, darin besteht, meine Arbeit gut zu machen. Dafür musste ich das Chaos, das wir hatten, überdenken und Ordnung schaffen.



Aber wenn Sie in das Chaos schauen, sehen Sie keine Muster - nichts, was darauf hindeutet, wie es sein sollte.

Ordnung aus dem Chaos zu schaffen, ist ein Schöpfungsakt, der schwierig ist.

Sie müssen von vorne beginnen, um zu verstehen, wann alles ins Chaos geraten ist. Sie müssen eine neue Reihenfolge festlegen und sich selbst erklären, was zu tun ist. Das sind schöne Worte: „Lass uns alles gut machen!“. Aber Sie kommen zur Arbeit und verstehen nicht wirklich, was Sie tun müssen, um alles zu ändern. Es gibt keine Ideen.

Die Ausbildung, die Sie erhalten haben, und die Bücher, die Sie lesen, helfen nicht weiter, denn alles, was Sie zuvor getan haben, haben Sie aus diesen Büchern und aus dieser Ausbildung gelernt.

Erklärung des Problems

Dann dachte ich - was ist das größte Problem? Wo ist der schmerzhafteste Punkt, an dem man nicht leben und arbeiten kann? Mir wurde klar, dass dies eine Erklärung des Problems ist . Das Festlegen einer Aufgabe war für mich immer eine Option.

Ich denke, viele von Ihnen haben die Aufgabe aus einer Überschrift "Beheben Sie den Fehler auf dem Produkt" gesehen. Wir hatten viele davon, ich habe sie in einer Zeile geschrieben, und dann haben die Leute etwas falsch gemacht und versucht, es falsch zu beheben. Ich dachte: „Warum denken sie nicht mit ihren eigenen Köpfen? Was machst du überhaupt Sie müssen einen einfachen Fehler beheben und nicht all diesen Unsinn machen. "

Dann habe ich nicht bemerkt, dass ich die Aufgaben wirklich schlecht gestellt habe. Aber irgendwann wurde mir immer noch klar, dass ich das ganz anders machen musste, und ich entwickelte mehrere Prinzipien.



Aufgaben sollten kurz sein . Nicht in Bezug auf die Beschreibung, wie „ein Fehler am Produkt behoben werden kann“, sondern von kurzer Natur. Kurze, kleine Aufgaben sind bequem zu erledigen. Sie sind für jeden verständlich: ein Anfänger, ein durchschnittlicher, erfahrener Entwickler. Jeder kann eine solche Aufgabe verstehen und zum Beispiel in einem halben Arbeitstag erledigen. Sie können damit beginnen.

Aufgaben sollten bestellt werden . Wenn sie Aufgaben festlegen, denken sie oft nicht darüber nach, in welcher Reihenfolge sie erledigt werden sollen. Aufgaben können sich jedoch gegenseitig blockieren, parallelisieren oder anderen Aufgaben zusätzliche Komplexität hinzufügen, wenn sie im Voraus erledigt werden usw.

Über die Reihenfolge der Aufgaben wird sehr wenig gesagt: Sie werden nach Jira oder Trello gebracht und von dort übernommen. Aber nur wenige denken und in welcher Reihenfolge, warum und warum ist die Reihenfolge genau dies.

Alle Aufgaben müssen individuell sein . Was bedeutet das? Aufgaben sind Entitäten, die innerhalb eines Projekts existieren und immer jemandem gehören. Manchmal finden Sie direkt in der Beschreibung des Problems: „Sergey, Masha, bitte korrigieren Sie dies. Sie wissen, wie es geht. " Sie können dies nicht tun, Sie müssen den gesamten Kontext angeben, damit diese Aufgabe in sich selbst individuell wird, damit jede Person, die sie liest, sie erfüllen kann. Damit es kein verstreutes Wissen über das Projekt gibt und es im Rahmen dieser Aufgabe keine versteckten Bedeutungen gibt.

Als die Aufgaben individuell, kurz und ordentlich wurden, begannen die Leute, sie so zu erledigen, wie ich es wollte.

Ich änderte nur die Art der Kommunikation und stellte sicher, dass genau die Leute, die diesen Unsinn gemacht hatten, anfingen zu tun, was ich wollte - ist es nicht Magie? Ist dies nicht ein Beweis dafür, dass vieles leicht zu ändern ist? Und ich begann mich weiter mit diesem Thema zu beschäftigen.

Wir haben den Kunden oft im Stich gelassen, nicht getan, was ihm nützen würde. Ich dachte, wenn Entwickler anfangen, unsere Aufgaben zu verstehen und sie so zu tun, wie sie sollten, können sie dann verstehen, was der Kunde wirklich will und tun, was der Kunde will?

Ich habe versucht, dies zu einer Art zweiseitiger Figur zu kombinieren, die einerseits wie ein Entwickler denkt, andererseits wie ein Kunde.



Dies ist keine neue Aufgabe. Im Allgemeinen wird dieser Ansatz als domänengesteuertes Design bezeichnet und wird seit vielen Jahren erfolgreich angewendet. Ich entschied mich für das Beste - eine Art der Kommunikation, Tools, Technologien und versuchte, den Entwicklern verständlich zu machen, was getan werden muss, um die Wünsche des Kunden zu erfüllen.

Die Aufgabe war sehr schwierig und ich arbeite immer noch an ihrer Lösung. Aber ich habe eine einfache Formel für mich entwickelt.

Anforderungen . Alles beginnt bei ihnen, der Kunde drückt uns, den Entwicklern, seinen Willen in Form von Anforderungen aus. Der Client sagt unter bestimmten Bedingungen: "Ich fordere, dass die Anmeldeseite funktioniert." Ihr Bewusstsein beginnt und kritzelt in Form von Tabellen, Listen, Grafiken usw. Die Anforderungen bleiben als wichtigster Teil Ihres Projekts bei Ihnen. Dies ist, was Sie auf höchstem Niveau tun.

Diese Anforderungen sind für den Entwickler jedoch nicht funktionsfähig, sie sind zu hoch und zu roh. Zu Beginn benötigt der Programmierer eine Dokumentation.

Dokumentation und Anforderungen sind Zwillingsbrüder, das ist doppelte Einheit. Anforderungen - das ist, was Sie tun müssen, und die Dokumentation - wie es geht.

Als ich feststellte, dass Dokumentation grundsätzlich aus Anforderungen generiert werden kann, wurde dies ein wichtiger Bestandteil unseres Geschäftsprozesses. Wir haben gelernt, Anforderungen in einem speziellen Format aufzuzeichnen und Dokumentation zu erstellen.

Tests . Der nächste logische Schritt besteht darin, zu überprüfen, ob es funktioniert. Wir haben begonnen, unsere Anforderungen zu testen, um sicherzustellen, dass wir wirklich das tun, was benötigt wird.

Das Interessanteste ist, dass ich nichts erfunden habe - ich habe keine einzige Codezeile geschrieben, damit dies funktioniert. Ich habe gerade die vorhandenen Technologien genommen und erhalten: Anforderungen, sie sind Dokumentation, sie sind Tests.

Der nächste logische Schritt bestand darin, den Code für das Ganze abzurufen, da der Code das ist, woran wir direkt beteiligt sind.

Code - für den eigentlich alles gestartet wird. Damit sich der Kunde und der Entwickler verbinden können, müssen Sie anscheinend in einen von ihnen im Kopf eindringen und sicherstellen, dass sie sich verstehen. Aber um in den Kopf zu kommen, können Sie dieselben Tools nehmen und verbinden, damit der Entwickler beginnt zu verstehen, was passiert. Hier können Sie lesen, wie ich es in der Praxis mache.

Sobald wir Entwickler und Kunden mithilfe einer solch ausgeklügelten Verflechtung verschiedener Entitäten zusammengebracht haben (der Kodex ist einer!), Haben wir sehr viel erreicht: Unsere Entwickler haben endlich begonnen, das zu tun, was das Unternehmen brauchte . Sie hörten auf, so etwas einfach einzuführen, weil sie die Anforderungen sahen und verstanden und verstanden, was zu tun war.

Um sicherzustellen, dass wir ausgeführt werden, haben wir Tests, die in Form von Anforderungen geschrieben sind. Diese Anforderungen sind klar genug, um in einer verständlichen Sprache im Code implementiert zu werden, und schreiben guten Code gemäß diesen Anforderungen.

Kommunikation

Ich habe bereits oft von „Kommunikation“ gesprochen. Ich liebe es, mit meinen Freunden und meiner Familie zu reden, aber nicht bei der Arbeit. Bei der Arbeit muss ich mit Menschen kommunizieren - ich habe sie nicht auf dieser Basis ausgewählt. Sehr oft hilft die Kommunikation bei der Arbeit nicht .

Wir alle kommunizieren mit Kollegen über nicht arbeitende Themen (Diskussion von Fernsehsendungen usw.), weil wir Menschen sind. Glücklicherweise kann dieser Fehler behoben werden. Um zu verstehen, wie katastrophal die Kommunikation für uns ist, können Sie sich verschiedene Beispiele ansehen.

Zuallererst lenken sich die Menschen gegenseitig ab und reißen aus einem Flusszustand heraus. Der Mann kam gerade und sagte etwas - was soll ich jetzt damit machen? Warum hat er mir gesagt, dass er das vermitteln will?

Oder Kundgebungen. Ich hasse sie, ich fühle mich immer wie ein Idiot, wenn ich bei Meetings sitze. Jeder scheint etwas zu verstehen, sie haben kluge Gesichter, und ich vermisse eines und denke darüber nach, wann es enden wird. Ich möchte gehen, weil alles, was wir besprechen, viel schneller besprochen werden kann.

Rallyes stehlen viel Zeit und nützen nichts.

Es gibt noch einige andere wichtige Themen, zum Beispiel, die Leute beginnen bei diesen Kundgebungen zu schwören. Stellen Sie sich vor, Sie wären in einem kleinen Raum voller Menschen untergebracht, die Sie nicht wirklich sehen möchten. Sie wollen gehen, und diese Leute treffen Sie, um einige ernsthafte Entscheidungen zu treffen. Natürlich beginnt Missbrauch - zuerst passive Aggression, dann offensichtliche Beleidigungen. Leider kann damit nichts gemacht werden, weil Menschen widersprüchliche Wesen sind. Egal wie Sie versuchen, die Situation zu mildern, egal wie Sie gute Leute aufnehmen, die nicht schwören - die Leute werden schwören, und das ist normal .

Es gibt ein weiteres Problem in unserem Geschäft - Menschen verschwinden . Ihr Front-End oder Ihre Entwickler können eines Tages leicht nicht mehr reagieren. Insbesondere Personen, die remote arbeiten, können das Telefon einfach ausschalten und das Gespräch einseitig beenden.

Diese und einige andere Probleme scheinen unlösbar. Sie können nicht allen Menschen beibringen, gut, konfliktfrei und verantwortungsbewusst zu sein - es ist einfach unmöglich.

Aber du kannst damit leben. Als Realist können Sie verstehen, dass das Leben so ist: Menschen werden verschwinden, fluchen, nicht mit Ihnen kommunizieren wollen - das ist normal. Ich habe dieses Problem wie folgt gelöst - strukturierte Kommunikation.



Um die Kommunikation zu strukturieren, reichen zwei Schritte aus:

• Gehen Sie jetzt zu Telegramm und löschen Sie es. Sobald Sie alle Ihre Seiten in sozialen Netzwerken gelöscht haben, können Ihnen keine Personen mehr schreiben.
• Starten Sie danach einen Kanal und sagen Sie, dass Sie nur auf diese Weise kommunizieren können.

Wenn Sie in der Lage sind, anderen Menschen Ihren Willen zu diktieren, bringen Sie ihnen das Kommunizieren bei. Sie zeigen, dass die Kommunikation für alle Teilnehmer strukturiert und nützlich sein sollte .

Wir haben uns für die Kommunikation über GitLab entschieden. Wenn Sie eine Frage haben, stellen Sie diese in GitLab. Wenn Sie eine seltsame Frage stellen möchten, stellen Sie sie dort. Wenn Sie verstehen, dass es keinen Ort gibt, an dem Sie eine solche Frage stellen können, muss sie möglicherweise nicht gestellt werden.

Wir kommunizieren nur zu Arbeitsthemen . Wenn jemand über das Game of Thrones sprechen möchte - Entschuldigung, wir arbeiten und besprechen das Game of Thrones mit Ihren Freunden. Wenn Sie eine neue Technologie diskutieren möchten, erstellen Sie ein Ticket, lassen Sie uns darüber diskutieren: Vielleicht kommt es dem Projekt zugute. Aber "Game of Thrones" wird dem Projekt sicherlich keine Vorteile bringen.

Strukturierte Kommunikation macht verschiedene Menschen gleich. GitLab hat sogar Avatare, die alle ungefähr gleich sind - einer hat den Buchstaben K, der andere C, und ich weiß nicht, wer diese Leute sind. Es ist mir egal, was sie sind, die Hauptsache ist, dass sie innerhalb der Struktur kommunizieren.

Nachdem wir die Kommunikation strukturiert, die Arbeit mit dem Kunden aufgebaut und gelernt haben, verständliche Tickets zu schreiben, ist es Zeit, uns mit dem Code zu befassen.

Code

Und hier liegt ein neues Problem in der Wartezeit - die Leute wissen nicht, wie man Code schreibt, und das ist normal . Früher dachte ich, dass andere schlechten Code schreiben, und ich bin gut. Aber dann wurde mir klar, dass ich selbst schlechten Code schrieb. Und nach einer Weile wurde mir klar, dass alle Leute schlechten Code schreiben , und das ist in Ordnung.

Menschen müssen keinen Code schreiben. Programmierung ist eine aggressive Umgebung, für die eine Person nicht prädisponiert ist. Der Code ist sehr komplex: Architektur und eine große Menge an Informationen. In verteilten Systemen ist es schrecklich. Es ist schwierig für eine Person, mit dem Informationsfluss umzugehen. Und das ist normal.

Aber wenn ja, können Sie etwas damit anfangen und lernen, wie man unter diesen Bedingungen arbeitet.



Um damit arbeiten zu können, benötigen Sie strenge CI-Werte und Tests, die so streng wie möglich sind. Es muss das Jüngste Gericht sein - ein Werkzeug, das die Frage beantwortet, ob es sich um einen guten oder einen schlechten Code handelt. Nur wenn Sie es betrachten, wird das allsehende Auge von CI erkennen, ob Ihre Arbeit zum Meister wird oder irgendwo auf der Bühne bleibt.

Ein solches CI sollte natürlich unvermeidlich sein. Sobald jemand das ausschließliche Recht erhält, sich zum Master zu verpflichten, fallen alle Versuche, Prozesse aufzubauen, auseinander, weil dieser jemand anfängt, alle Arten von Unsinn zu machen.

Das unvermeidliche und strenge CI bietet einige coolere Funktionen. Dies ist eine Gelegenheit zur Entwicklung, da es jetzt eine Basisleiste gibt, auf der Sie aufbauen können: Jeder nachfolgende Code ist besser als der vorherige. Jeder nachfolgende Code erhöht den Wert des Projekts und verbessert das CI. Jeder nachfolgende Code ist ein Schritt in Richtung Entwicklung.

Sobald das Fundament fertig ist, können Sie fortfahren.

Aber die Leute werden immer noch Fehler machen, weil kein CI, selbst wenn es strengstens konfiguriert ist, alle Fehler auffangen kann . Und sie werden an Orten erscheinen, an die sonst niemand denken wird.

Was kann man dagegen tun? Sie können zur üblichen Taktik zurückkehren und sagen: „Sie haben einen Fehler gemacht, korrigieren Sie ihn. Sie haben einen schlechten Code geschrieben - lernen Sie, Code zu schreiben. " Dies ist ein schlechter Weg, der nicht zur Entwicklung führt.

Um wirklich richtig zu schreiben und Ihr Produkt zu entwickeln, brauchen Sie einen neuen Ansatz und eine neue Mentalität.

Schuldlose Umgebung

Ich habe diesen Ansatz als tadellose Umgebung bezeichnet - das bedeutet, dass ich niemals Menschen für irgendetwas verantwortlich mache. Wenn ein Fehler in Ihr Projekt eingedrungen ist, ist dies ein Projektproblem. Dieser Fehler sollte behoben werden, damit er nie wieder auftritt. Wenn dies ein Fehler im Code ist, müssen Sie einen Regressionstest schreiben. Wenn dies ein Fehler in der Projektinfrastruktur ist, müssen Sie ein Tool schreiben, das diesen Fehler verhindert.



Wenn Sie nicht nur Fehler beheben und hoffen, dass bei der Produktion nicht alles auseinander fällt, sondern auf Systemebene korrigiert wird, beginnen Sie mit dem Erstellen und Erstellen - Erstellen neuer Tools, Entwickeln neuer Ansätze und Architekturmuster. Sie beginnen mit dem Kopf zu denken und stellen sicher, dass Fehler nicht erneut auftreten.

Die ständige Arbeit an Fehlern bringt den Entwickler auf eine grundlegend andere Ebene. Sie beginnen, Tools für Entwickler zu erfinden, sie zu implementieren, zu fördern usw.

Die Schöpfung, von der ich jetzt spreche, ist riesig. Wenn Sie versuchen, diesen Ansatz zu verwenden, werden Sie feststellen, dass alles, was jetzt existiert, insbesondere für einige Programmiersprachen, nicht streng genug ist.

Einmal fragte ich mich, ob ich einen Linter schreiben könnte, der alle dazu bringt , den gleichen Code zu schreiben. Ich war sehr streng und schloss alle möglichen Regeln ein, die ich mir ausdenken konnte. Aber die Leute schreiben immer noch anderen Code . Es ist sehr ähnlich, aber ich kann immer verstehen, dass dieser Code von verschiedenen Personen geschrieben wurde. Mein Linter ist also immer noch nicht streng genug - warten Sie auf neue Releases.

Der Ansatz bleibt bestehen, wir warten darauf, dass die Maschine reagiert, das Programm ist gut gemacht oder nicht. Und es funktioniert, weil solche Tools bei der Arbeit helfen.

Wir dürfen aber nicht vergessen, dass Menschen notwendige Teilnehmer am Prozess sind . Unabhängig davon, welche hervorragenden technischen Einstellungen Sie vornehmen, kann das erfahrene Aussehen der Person Ihren Code nicht durchlaufen, es kann dennoch etwas geben, von dem Ihre Haare zu Berge stehen, obwohl CI bestanden hat.

Einerseits haben wir uns mit unserem Problem befasst und sehr schlechten Code abgelehnt. Trotzdem sind wir nicht völlig von ihm isoliert. Ein Codeüberprüfungsprozess ist erforderlich . Wenn der Code die Codeüberprüfung nicht bestanden hat, ist alles, was Sie zuvor getan haben, sinnlos.

Jeder nächste Schritt ist nur dann sinnvoll, wenn eine Grundlage für den vorherigen vorhanden ist.

Wenn Sie nicht verstehen, was Sie tun, oder wenn Sie die Aufgabe falsch eingestellt haben, helfen keine Codeüberprüfung und kein CI. , , . - — .



— .

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

: , . , , , — : . , .

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

— , — .

— , . , .

, , . . . , .

, , , , . , , , .

, , , , , , , .

— . , — , , , .

, . , , . open source , .

. , , , — .

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

. , . : — , — . .

. , , — ? , , , . .

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

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

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

. , , - , . -, .

. , . - — , . , .

, . , . , .

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