Eine der am stĂ€rksten ĂŒberlaufenen Idiotienberufe sind Manager, die Programmierer fĂŒhren. Nicht alle, sondern die, die selbst niemals Programmierer waren. Die, die denken, man könne die Effizienz (oder die âEffizienzâ?) mit Methoden aus BĂŒchern âsteigernâ. Nicht einmal die MĂŒhe machen, diese BĂŒcher zu lesen â schlieĂlich gibt es ja ein Video.
Die, die niemals Code geschrieben haben. Die, fĂŒr die Hollywood-Filme ĂŒber Programmierer gedreht werden â na ja, die, in denen man die E-Mails ĂŒber die Kommandozeile anschaut. Die, die an nichts interessiert sind, auĂer an Kennzahlen, Fristen und ihrem eigenen Gehalt.
Die, die die Mehrheit ausmachen.
Aber sie sind aus einem anderen Grund Idioten. Sie streben nach Effizienz oder zumindest nach Ergebnissen (komm schon, Manager, google, wo der Unterschied liegt), ohne sich in der einen oder anderen Richtung auszukennen. Sie verstehen ĂŒberhaupt nicht den Kern, den Prozess der Ergebnisgewinnung, die Verluste, die in diesem Prozess entstehen, die Kosten fĂŒr die Entwicklung. Kurz gesagt, sie arbeiten mit Programmierern wie mit einer Black Box.
Sie sind nur aus einem Grund ins Management von Programmierern gestĂŒrzt: Hier gibt es Hype, Geld, einen Markt und eine Menge anderer Idioten. Es gibt Platz, um sich zu verlieren.
WĂ€re der Hype in der Montageproduktion, wĂŒrden sie dorthin laufen. Schlecht ausgebildete Alleskönner. Ich werde nicht ĂŒberrascht sein, wenn der Typ, der im Dezember WeihnachtsbĂ€ume in unserem Viertel verkauft, ein IT-Manager im Urlaub ist.
Kurz gesagt, wenn sich die Gelegenheit bietet, schickt diese Leute zum Teufel. Macht euch keine Sorgen, sie finden einen neuen Job. Keiner von ihnen wird jemals etwas AnstÀndiges machen, bis er selbst Programmierer wird. Weil sie den Kern, den Mechanismus, die Logik des Prozesses, den sie leiten, nicht verstehen.
So, genug von Managern. Jetzt zum Wesentlichen fĂŒr Programmierer. Wie man die Effizienz der Entwicklung steigert, indem man lernt, qualitativ hochwertigen Code zu schreiben.
Um die Effizienz zu steigern, muss man Aufgaben schneller lösen, ohne die QualitĂ€t zu verlieren. Um Aufgaben schneller zu lösen, muss man in der Lage sein, sofort hochwertigen Code zu schreiben. Sowohl âhochwertigâ als auch âschreibenâ und âsofortâ. Ich werde es mit einer Metapher erklĂ€ren.
Qualitativ hochwertigen Code zu schreiben ist wie korrekt eine Fremdsprache zu sprechen. Wenn man die Sprache nicht kennt, verbringt man viel Zeit damit, seine Gedanken in ihr zu formulieren.
Wenn man schnell etwas sagen muss, klebt man einfach irgendwelche Worte zusammen, oft nicht die, die man braucht, vergisst Artikel, die richtige Wortstellung, ganz zu schweigen von den Zeiten der Verben und der misslungenen Aussprache.
Wenn man Zeit hat, um eine Antwort zu formulieren, muss man ein Wörterbuch oder einen Online-Ăbersetzer öffnen und viel Zeit damit verbringen, seine Gedanken zu formulieren. Das GefĂŒhl wird trotzdem unangenehm sein: Man sagt eine Antwort und weiĂ nicht, ob sie richtig ist oder nicht. Ăhnlich bei Code - man scheint etwas geschrieben zu haben, es funktioniert anscheinend, aber ob es von guter QualitĂ€t ist oder nicht - keine Ahnung.
Das fĂŒhrt zu einem doppelten Zeitverlust. Es kostet Zeit, sich eine Antwort auszudenken. Es kostet auch Zeit, diese Antwort zu formulieren, und zwar nicht wenig.
Wenn jedoch die FĂ€higkeit besteht, qualitativ hochwertigen Code zu schreiben, kann man die Antwort sofort formulieren, sobald sie im Kopf gereift ist, ohne zusĂ€tzliche Zeit fĂŒr die Ăbersetzung zu verschwenden.
Die FĂ€higkeit, qualitativ hochwertigen Code zu schreiben, hilft beim Entwurf von Architekturen. Man wird einfach keine falschen, nicht umsetzbaren oder zweifelhaften Optionen im Kopf in Betracht ziehen.
Zusammenfassend lÀsst sich sagen: Die FÀhigkeit, qualitativ hochwertigen Code zu schreiben, beschleunigt die Lösung von Aufgaben erheblich.
Aber das ist noch nicht alles. Aufgrund von Manager*innen, die nichts verstehen, gibt es ein Problem â wir haben keinen Anlass, qualitativ hochwertigen Code zu schreiben. Der Manager schaut sich den Code nicht an, der Kunde schaut sich den Code nicht an. Wir zeigen uns den Code nur selten, manchmal in bestimmten Projekten, wo es einen âPrĂŒferâ fĂŒr den Code gibt oder eine regelmĂ€Ăige Refaktorisierung.
Das bedeutet, in den meisten FĂ€llen kommt Schrottcode ins Produkt oder an den Kunden. Bei der Person, die diesen Schrottcode geschrieben hat, bildet sich eine stabile neuronale Verbindung - Schrottcode zu schreiben ist nicht nur möglich, sondern auch notwendig - man wird dafĂŒr akzeptiert und bekommt sogar Geld dafĂŒr.
Infolgedessen hat die FĂ€higkeit, qualitativ hochwertigen Code zu schreiben, ĂŒberhaupt keine Chance zur Entwicklung. Der von einem hypothetischen Mitarbeiter geschriebene Code wird von niemandem geprĂŒft, niemals. Der einzige Grund, warum er lernen wird, richtig zu programmieren, ist die innere Motivation.
Aber diese innere Motivation steht im Widerspruch zu den PlĂ€nen und Anforderungen an Effizienz und ProduktivitĂ€t. Dieser Widerspruch wird offensichtlich nicht zugunsten von qualitativ hochwertigem Code gelöst, denn bei Schrottcode wird man nicht einmal beschimpft. Und fĂŒr die NichterfĂŒllung des Plans â das schon.
Was tun? Ich sehe und schlage zwei Wege vor, die man kombinieren kann.
Der erste â zeige deinen Code jemandem innerhalb des Unternehmens. Nicht reaktiv (wenn man darum bittet/fordert), sondern proaktiv (hey, schau dir bitte meinen Code an). Dabei ist es wichtig, keine zuckerhaltigen Ausreden zu verwenden und Kritik am Code nicht in höfliche Formen zu kleiden. Wenn der Code schlecht ist, sagen wir einfach: Der Code ist schlecht. NatĂŒrlich mit ErklĂ€rungen und Empfehlungen, wie man ihn verbessern kann.
Aber dieser Weg ist auch nicht ideal. Seine Anwendbarkeit hĂ€ngt von dem Zeitpunkt ab, an dem der Kontakt stattfand. Wenn die Arbeit bereits in der Produktion ist und sich herausstellt, dass der Code schlecht ist, hat es keinen Sinn mehr, ihn umzubauen. Genauer gesagt, es gibt keinen Grund â auch die Metriken werden darunter leiden. Die Manager werden kommen und mit Anforderungen an die Effizienz ĂŒberrollen. Und versuche nicht einmal, ihnen zu erklĂ€ren, dass schlechter Code als Bugs zurĂŒckkommt â das wird dir nur schaden. Man kann sich nur verpflichten, es in Zukunft besser zu machen.
Wenn die Arbeit jedoch noch nicht eingereicht oder gerade erst begonnen wurde, kann es durchaus sinnvoll sein, den Code (oder sein Projekt, seine Idee) zu kritisieren â die Person wird es besser machen.
Der zweite Weg, der coolste â sich in der Freizeit mit der Entwicklung von Open Source zu beschĂ€ftigen. Das Ziel ist ja, dass viele Programmierer, genau genommen Programmierer, deinen Code sehen und sich dazu Ă€uĂern. Innerhalb des Unternehmens ist dafĂŒr niemand Zeit. Programmierer auf der ganzen Welt haben nichts zu tun, und wenn du etwas NĂŒtzliches schreibst, werden sie sicher einen Blick darauf werfen.
Der Hauptpunkt, meiner Meinung nach, ist das Schreiben von Code in der Freizeit, weil es das Dilemma zwischen CodequalitÀt und Geschwindigkeit der Ergebnisse auflöst. Du kannst ein Jahr an deiner Entwicklung arbeiten. Weder Fristen noch Anforderungen, noch Geld oder Chefs werden dir Druck machen. VollstÀndige Freiheit und KreativitÀt.
Nur in der kreativen Freiheit wirst du verstehen und fĂŒhlen, was groĂartiger Code ist, die Schönheit der Programmiersprachen und Technologien sehen und die Faszination von GeschĂ€ftsaufgaben erleben. Und du wirst lernen, qualitativ hochwertigen Code zu schreiben.
Das erfordert allerdings einen persönlichen Zeitaufwand. Wie jede andere Art von Lernen. Sieh es nicht als Kosten an, sondern als Investition â in dich selbst.
Quelle: habr.com
