Python-Codierungsstandards vs. Produktivität

Ich arbeite für eine große humanitäre Organisation an einer Projektentwicklungssoftware, die in Notfällen Leben retten kann, indem sie die Verteilung von Nahrungsmitteln beschleunigt. Viele NGOs brauchen dringend unsere Software und wir sind Wochen hinter dem Zeitplan zurück.

Eine Sache, die mich in diesem Projekt beunruhigt, ist meiner Meinung nach ein übermäßiger Fokus auf Codierungsstandards. Wir schreiben in Python / Django und verwenden eine Version von PEP0008, mit verschiedenen Modifikationen, z. B. können die Zeilenlängen bis zu 160 Zeichen betragen, und alle Zeilen sollten möglichst so lang sein, keine Leerzeilen zwischen den Importen, Zeilenumbruchregeln, die nur für bestimmte Arten gelten von Klassen, viele Vorlagen, die wir verwenden müssen, auch wenn sie nicht der beste Weg sind, um ein Problem zu lösen usw. usw.

Ein Kernentwickler verbrachte eine Woche damit, einen Großteil des Systems neu zu schreiben, um die damals neuen Codierungsstandards zu erfüllen, und warf dabei mehrere Testreihen weg, da das Umschreiben bedeutete, dass sie "ungültig" waren. Wir haben zwei Wochen damit verbracht, alle verlorenen Funktionen neu zu schreiben und Fehler zu beheben. Er ist der leitende Entwickler und sein Wort hat Gewicht. Deshalb hat er den Projektmanager davon überzeugt, dass diese Standards notwendig sind. Die Junior-Entwickler tun, was ihnen gesagt wird. Ich habe das Gefühl, dass der Projektmanager ein starkes Gefühl der kognitiven Dissonanz bei all dem hat, aber trotzdem vehement damit einverstanden ist, da er sich unsicher fühlt, was er sonst noch tun soll.

Heute bekam ich ernsthafte Probleme, weil ich vergessen hatte, in einem Keyword-Argument ein Leerzeichen nach dem Komma einzufügen. Ich wurde während eines Skype-Anrufs buchstäblich von zwei anderen Entwicklern und dem Projektmanager angeschrien. Persönlich denke ich, dass Codierungsstandards wichtig sind, aber wir denken auch, dass wir viel Zeit damit verschwenden, und als ich das verbalisierte, hat es Wut ausgelöst. Ich werde als Unruhestifter im Team gesehen, ein Team, das nach Sündenböcken für seine Fehler sucht. Seit der Einführung der Kodierungsstandards ist die Produktivität des Teams messbar gesunken, dies verstärkt jedoch nur die Besessenheit, dh der leitende Entwickler macht einfach unsere Nichteinhaltung von Standards für den mangelnden Fortschritt verantwortlich. Er glaubt, dass wir den Code des anderen nicht lesen können, wenn wir die Konventionen nicht einhalten.

Dies fängt an, klebrig zu werden. Jetzt versuche ich verschiedene Skripte zu modifizieren, autopep8, pep8ify und PythonTidy, um zu versuchen, den Konventionen zu entsprechen. Wir führen pep8 auch gegen Quellcode aus, aber es gibt so viele implizite Änderungen an unserem Standard, dass es schwierig ist, sie alle zu verfolgen. Der leitende Entwickler sucht nach Fehlern, die das pep8-Skript nicht aufgreift, und schreit uns beim nächsten Stand-up-Meeting an. Jede Woche gibt es neue Ergänzungen der Codierungsstandards, die uns zwingen, vorhandenen, funktionierenden und getesteten Code neu zu schreiben. Gott sei Dank haben wir immer noch Tests (ich habe einige Commits rückgängig gemacht und ein paar von denen repariert, die er entfernt hat).

Gleichzeitig steigt der Druck, die Frist einzuhalten.

Ich glaube, ein grundlegendes Problem ist, dass der Lead-Entwickler und ein anderer Core-Entwickler sich weigern, anderen Entwicklern zu vertrauen, ihre Arbeit zu erledigen. Aber wie geht man damit um? Wir können unseren Job nicht machen, weil wir zu beschäftigt sind, alles neu zu schreiben.

Ich habe diese Dynamik in einem Software-Engineering-Team noch nie erlebt. Bin ich falsch, ihre Einhaltung von Kodierungsstandards in Frage zu stellen? Hat jemand eine ähnliche Situation erlebt und wie ist er erfolgreich damit umgegangen? (Ich bin nicht auf der Suche nach einer Diskussion, sondern nach tatsächlichen Lösungen, die die Leute gefunden haben.)

Die Kodierungsstandards sind nicht das Problem. Das Problem ist, dass das Management nicht herausfinden kann, wo das Problem liegt. Dies führt zu "Tu etwas ... irgendetwas!" Modus. Sie suchen nach einer rationalen Lösung, aber es ist ein irrationales Problem. Das Beste, was Sie tun können, ist:

• Geben Sie konstruktive Kritik an ihren Ideen, aber wenn die Entscheidung einmal gefallen ist, jammern Sie nicht ständig darüber.
• Tun Sie alles, um das Umschreiben zu vereinfachen.
• Hör auf zu stressen. Versäumte Termine sind das Problem des Managements, nicht Ihres. Gib dein Bestes, aber übernimm keine Verantwortung für ihre schlechten Entscheidungen.
• Wenn Sie etwas wissen, das Ihnen helfen könnte, sagen Sie es ihnen. Ihre Erwähnung von Stand-ups klingt, als ob Sie versuchen, agil zu sein, aber der Rest klingt nicht sehr agil. Sehen Sie nach, ob Sie eingeschränkte Funktionen früher bereitstellen können, anstatt zu versuchen, eine große Frist mit allem einzuhalten. Erstellen Sie User Stories für die Umschreibungen, damit klar ist, wie sie sich auf den Rückstand auswirken.
• Suche nach einem anderen Job. Ernst. Unternehmen in einem solchen Staat sind nicht weit davon entfernt, Menschen zu entlassen.
• Lass dir ein paar T-Shirts ausdrucken :-)

Jemand muss entscheiden, ob der Versand oder die Einhaltung der Kodierungsstandards die eigentliche Priorität ist. Ich weiß, was meine Präferenz sein würde; Wenn es Einheits- und Abnahmetests besteht, sage ich Schiff. Sobald die Lieferung erfolgt ist, kann das Unternehmen entscheiden, ob es Zeit und Geld für die Begleichung der technischen Schulden aufwenden möchte oder nicht.

Probleme mit Leerzeichen nach Kommas lassen sich leicht mit einem Code-Prettifying-Tool lösen. Suchen Sie ein Tool, das alle Ihre Codierungskonventionen erzwingt, und führen Sie dieses Tool für den gesamten geänderten Code aus, bevor das Erstellen und Testen stattfindet. Anständige IDE tun dies bereits, während Sie den Code schreiben.

Bin ich falsch, ihre Einhaltung von Kodierungsstandards in Frage zu stellen?

Das hängt von der Gruppe ab. Persönlich denke ich, dass alles in Frage gestellt werden sollte. Einige Leute halten diese Befragung für einen Affront; dass ich ihnen nicht vertraue.

Hat jemand eine ähnliche Situation erlebt und wie ist er erfolgreich damit umgegangen?

Ich fragte, wie diese Standards die Produktivität verbessern. Ich habe die Zeit gemessen, die ich damit verbracht habe, mich mit den Standards zu beschäftigen, anstatt Dinge zu erledigen. Am Ende bleiben die Befugnisse, die entschieden werden, bei den Standards. Es passiert. Ich beschwerte mich lauter als gewöhnlich über sie, als sie die Ursache dafür waren, dass ich nicht alles erledigte, sondern mich ansonsten darauf konzentrierte, meine Arbeit zu erledigen. Kontinuierliche Kämpfe sind auch nicht gut für die Produktivität ...

Wenn, wie Sie sagen, die Dinge aufgrund der Standards messbar schlechter sind, sollte die Einhaltung der Standards das Argument des Lead ungültig machen und Ihr Argument verlassen. Wenn die Menschen diesen (weitgehend) objektiven Zusammenhang zwischen der Implementierung des Standards und dem Rückgang der Produktivität nicht erkennen können, können Sie nicht viel mehr tun. Lernen Sie damit umzugehen, und wenn Sie nicht können, suchen Sie sich einen weniger bürokratischen Ort.

Standards sollten nicht zu einem späteren Zeitpunkt mit einem bevorstehenden Termin eingeführt werden. Es ist etwas, das zu Beginn des Projekts oder zu einem Zeitpunkt, zu dem der Zeitplan des Projekts (vorzugsweise nach dem Ausliefern des ersten Schiffs) für einen (potenziell) großen Code-Refactor, der einen Verstoß darstellt, festgelegt werden sollte.

Wenn dies tatsächlich zu einem späten Zeitpunkt in das Projekt eingefügt wurde, dann ist es ein Fehler, den Ihr Lead (IMHO) begangen hat.

Dies bedeutet jedoch nicht, dass Sie, wenn Sie mit Ihrem Hinweis nicht einverstanden sind, nur mit Meuterei rechnen sollten. Das ist dein Job . Du arbeitest als Team . Sie haben einen Vorsprung . Es sollte auf jeden Fall ein gewisses Maß an Demokratie im Team geben, aber am Ende ist die Führung der Diktator. Wenn er sagt, dass er etwas tun soll, dann tust du es.

Wenn Sie seine Anforderungen und Standards erfüllen, können Sie ihm letztendlich keinen einfachen Sündenbock für fehlende Termine liefern.

Ich bin auch ein großer Befürworter von Codierungsstandards (vor allem, wenn die Größe eines Teams wächst), aber sie sollten implementiert werden, wenn es Sinn macht.

Ihre Frage lautete "Bin ich falsch, ihre Einhaltung von Kodierungsstandards in Frage zu stellen?". http://c0x.coding-guidelines.com/Introduction.pdf (für C-Programmiersprache) enthält einige referenzierte Studien zum Wert von Codierungsrichtlinien. Siehe Abschnitt 9 ab Seite 39.

Codierungsstandards sind aus einem bestimmten Grund implementiert. Eine Sache, die in der ursprünglichen Frage zu fehlen scheint, ist das Verständnis für den Grund für diese bestimmten Standards für das bestimmte Projekt (oder in der bestimmten Organisation). Die Entscheidung, sie in vorhandenen Code zu implementieren, basierte auf einer Logik. Ohne die Logik zu kennen, ist es schwierig, die „Güte“ dieser Entscheidung zu kommentieren.

Ich werde dem folgen, was jemand gesagt hat, dass Standards für "Langzeitproduktivität" implementiert sind - Themen wie die Wartbarkeit des Codes. Möglicherweise ist ein Ereignis eingetreten, das das Projekt aufgrund von Verwirrung und Fehlinterpretation stark beeinträchtigt hat.

Es hört sich so an, als ob es auf beiden Seiten eine Menge Emotionen gibt - versuchen Sie, zu einer begründeten Diskussion zu gelangen.

Wie Sie wahrscheinlich an den anderen Antworten und Kommentaren gesehen haben, hat Ihr Projekt große Probleme. Ich schlage vor, dass es keine großen Erfolgschancen hat, aber Sie können es versuchen, ohne ein allzu großes Risiko einzugehen deine eigene Haut.

Bitten Sie Ihren leitenden Entwickler um ein Treffen mit vier Augen. Angenommen, Sie möchten die Vorteile des strengen Kodierungsstandards gründlich verstehen und wissen, warum die Kodierungsbasis vor ihrer Einführung in einem so schlechten Zustand war. Es ist sehr wichtig, dass Sie während dieser Diskussion eine sehr offene und lernwillige Haltung einnehmen. Ihr leitender Entwickler ist wahrscheinlich bereits mehr gestresst als Sie oder jemand anderes in Ihrem Team und wird wahrscheinlich sehr defensiv sein, sobald er Kritik wittert.

Versuchen Sie, die Diskussion in die Richtung zu lenken, in der Sie versuchen, Wege zu finden, um Ihr gemeinsames Ziel zu erreichen. Schnelle Lieferung funktionierender und wartungsfähiger Software.

Zum Beispiel sollen einige niedrig hängende Früchte den Kodierungsrichtlinien nichts mehr hinzufügen. In jedem Fall funktioniert Code, der zuvor die Richtlinien eingehalten hat, nicht mehr. Dies führt dazu, dass Sie Codestücke neu schreiben müssen. Ihr leitender Entwickler kann hoffentlich feststellen, dass die zusätzliche Regel (aus seiner Sicht) zwar einen Mehrwert bringt, aber möglicherweise nicht so gut ist, dass sie das Umschreiben in dieser Phase des bereits verspäteten Projekts motiviert.

Wenn dies funktioniert, können Sie versuchen, ihn die willkürlicheren Regeln entfernen zu lassen, die mit einem Tool nicht automatisch formatiert werden können.

Codierungsstandards sind gut. Das Ändern von Codierungsstandards ist teuer (naja, es ist teuer, wenn Sie sie weniger freizügig machen; wenn eine Änderung des Standards dazu führt, dass der gesamte vorhandene Code weiterhin kompatibel ist, ist dies kein Problem) und sollte daher nur dann durchgeführt werden, wenn dies unbedingt erforderlich ist.

Eine Sache, die Sie vielleicht tun müssen, ist, dass der Lead vor dem Commit / Merge / Was auch immer den gesamten Code überprüft, um sicherzustellen, dass er dem Standard entspricht, da die vorhandene Toolkette anscheinend nicht in der Lage ist, ihn automatisch zu überprüfen.

Software, die in Notfällen Leben retten kann, indem sie die Verteilung von Nahrungsmitteln beschleunigt

Ich glaube an gute Codierungsstandards, aber ich glaube auch, dass es viel wichtiger ist , Leben zu retten .

Ihre größte Priorität muss darin bestehen , Menschenleben zu retten . Stellen Sie sich vor, diese Software verteilt Lebensmittel an Ihre Familie oder Ihr Team. Alles andere kann als nächstes kommen.

Die gute Nachricht: Sie haben Tests. Tests helfen Ihnen dabei, Ihre Codierungsstandards einzuhalten, ohne die Funktionalität zu beeinträchtigen. Dies sollte jedoch nach dem Versand geschehen , nicht zuvor.