Einer der überlasteten Idioten sind Manager, die Programmierer verwalten. Nicht alle, aber diejenigen, die selbst keine Programmierer waren. Diejenigen, die denken, dass es möglich ist, die Effizienz durch Methoden aus Büchern zu "steigern" (oder die "Effizienz" zu steigern?). Ohne sich die Mühe zu machen, genau diese Bücher zu lesen - Vidosik ist schließlich eine Zigeunerin.
Diejenigen, die nie Code geschrieben haben. Diejenigen, für die Hollywood-Filme über Programmierer gemacht wurden - also diejenigen, bei denen sie E-Mails über die Befehlszeile abrufen. Diejenigen, die sich für nichts anderes interessieren als Indikatoren, Begriffe und ihr eigenes Gehalt.
Diejenigen, die am meisten sind.
Aber sie sind aus einem anderen Grund Idioten. Sie möchten Effizienz oder zumindest Produktivität (los, Manager, Google, was ist der Unterschied), ohne die eine oder die andere zu verstehen. Im Allgemeinen nicht das Wesen, den Prozess der Erlangung des Ergebnisses, die Verluste in diesem Prozess, die Entwicklungskosten zu verstehen. Kurz gesagt: Arbeiten mit einem Programmierer wie mit einer Blackbox.
Sie sind aus genau einem Grund auf das Management von Programmierern gestoßen: Hier gibt es Hype, Geld, den Markt und ein Haufen derselben Idioten. Es gibt Orte, an denen man sich verirren kann.
Wenn es einen Hype in der mechanischen Montageindustrie gäbe, würden wir dorthin rennen. Kombis sind schlecht. Ich bin nicht überrascht, dass der Typ, der im Dezember in unserem Viertel Weihnachtsbäume verkauft, ein IT-Manager im Urlaub ist.
Kurz gesagt, wenn möglich, jagen Sie diese Typen in den Nacken. Mach dir keine Sorgen, sie werden einen Job finden. Keiner von ihnen wird jemals etwas Anständiges tun, bis er Programmierer wird. Weil er das Wesen, den Mechanismus und die Logik des Prozesses, den er kontrolliert, nicht versteht.
Nun, das reicht für die Manager. Jetzt für Programmierer. Wie Sie die Entwicklungseffizienz steigern, indem Sie lernen, hochwertigen Code zu schreiben.
Um die Effizienz zu steigern, müssen Probleme schnell und ohne Qualitätsverlust gelöst werden. Um Probleme schneller zu lösen, müssen Sie in der Lage sein, sofort hochwertigen Code zu schreiben. Und "Qualität" und "Schreiben" und "sofort". Ich werde es mit einer Metapher erklären.
Das Schreiben eines Qualitätscodes ist wie kompetentes Sprechen in einer Fremdsprache. Wenn Sie die Sprache nicht kennen, verbringen Sie viel Zeit damit, Ihre Gedanken darüber zu formulieren.
Wenn Sie es dringend sagen müssen, kleben Sie einfach ein paar Wörter, oft nicht die, die Sie brauchen, vergessen Sie die Artikel, die richtige Wortreihenfolge und die Zeitformen der Verben und die schlechte Aussprache.
Wenn für den Wortlaut der Antwort Zeit ist, müssen Sie ein Wörterbuch oder einen Internetübersetzer öffnen und viel Zeit mit dem Wortlaut Ihrer Gedanken verbringen. Das Gefühl wird jedoch immer noch unangenehm sein: Sie sagen die Antwort und wissen nicht, ob sie richtig ist oder nicht. Ähnlich mit dem Code - es scheint geschrieben zu haben, es scheint zu funktionieren, aber es ist Qualität oder nicht - HZ.
Es stellt sich ein doppelter Zeitverlust heraus. Es braucht Zeit, um eine Antwort zu finden. Es braucht auch Zeit, um diese Antwort zu formulieren - im Übrigen nicht so wenig.
Wenn die Fähigkeit zum Schreiben von qualitativ hochwertigem Code vorhanden ist, kann die Antwort sofort formuliert werden, sobald sie im Kopf gereift ist, ohne dass zusätzliche Zeit für die Übersetzung aufgewendet werden muss.
Die Fähigkeit, Qualitätscode zu schreiben, hilft bei der architektonischen Gestaltung. Sie werden einfach nicht die falschen, nicht realisierbaren oder Hand-zu-Hand-Optionen in Ihrem Kopf berücksichtigen.
Zusammenfassend: Die Fähigkeit, hochwertigen Code zu schreiben, beschleunigt die Lösung von Problemen erheblich.
Das ist aber noch nicht alles. Dank Valenki-Managern gibt es einen Haken - wir haben also keinen Grund, hochwertigen Code zu schreiben. Der Code-Manager sieht nicht aus, der Client-Code sieht nicht aus. In einigen Projekten, in denen es einen bestimmten „Code Inspector“ oder ein periodisches Refactoring gibt, zeigen wir einander nur gelegentlich Code.
In den meisten Fällen geht der govnokod in die Produktion oder an den Kunden. Die Person, die den govnokod geschrieben hat, bildet eine stabile neuronale Verbindung - der govnokod kann nicht nur geschrieben werden, sondern ist auch notwendig - er wird akzeptiert und sogar dafür bezahlt.
Infolgedessen hat die Fähigkeit, hochwertigen Code zu schreiben, überhaupt keine Chance, sich zu entwickeln. Der von einem Bedingten Mitarbeiter geschriebene Code wird von niemandem überprüft. Der einzige Grund, warum er lernt, normal zu programmieren, ist die intrinsische Motivation.
Diese intrinsische Motivation steht jedoch im Widerspruch zu den Plänen und Anforderungen für Effizienz und Produktivität. Dieser Widerspruch wird eindeutig nicht zugunsten eines qualitativ hochwertigen Codes gelöst, da sie nicht einmal dem govnokod die Schuld geben. Und für die Nichterfüllung des Plans - wie sonst.
Wie zu sein Ich sehe und biete zwei Möglichkeiten, die kombiniert werden können.
Das erste ist, Ihren Code jemandem innerhalb der Firma zu zeigen. Nicht reaktiv (wenn gefragt / gezwungen), sondern proaktiv (ähm, Alter, schau dir bitte meinen Code an). Die Hauptsache hier ist nicht Zucker Rotz hängen, nicht versuchen, höflichen Code auf Kritik des Codes zu setzen. Wenn der Code Scheiße ist, sagen wir so: Der Code ist Scheiße. Natürlich mit Erklärungen und Empfehlungen, wie man es besser macht.
Aber dieser Weg ist auch so lala. Ihre Anwendbarkeit hängt vom Zeitpunkt des Kontakts ab. Wenn die Arbeit bereits in Produktion gegangen ist und sich herausstellt, dass der Code Scheiße ist, macht es keinen Sinn, ihn zu wiederholen. Genauer gesagt, Gelegenheiten - Metriken werden auch durchhängen. Manager werden die Anforderungen an die Effizienz angreifen und zunichte machen. Und versuche ihnen nicht einmal zu erklären, dass der Govnokod definitiv in Form von Bugs zurückkehren wird - er wird dir seitwärts erscheinen. Man kann sich nur verpflichten, dies nicht mehr zu tun.
Wenn die Arbeit noch nicht übergeben wurde oder gerade erst begonnen hat, kann es durchaus eine praktische Bedeutung haben, den Code (oder sein Projekt, seine Idee) mit Scheiße zu füllen - eine Person wird es normalerweise tun.
Der zweite Weg, der coolste, ist die Open-Source-Entwicklung nach Stunden. Denn was ist das Ziel: Für eine Gruppe von Programmierern, nämlich Programmierern, Ihren Code zu sehen und darüber zu sprechen. Es ist keine Zeit für alle im Unternehmen. Aber Programmierer auf der ganzen Welt haben immer noch nichts zu tun, und wenn Sie etwas Nützliches aus der Sicht der Anwendung schreiben, dann werden sie auf jeden Fall nach innen schauen.
Das Hauptmerkmal ist meiner Meinung nach das Schreiben von Code nach Stunden, da der Widerspruch zwischen der Qualität des Codes und der Geschwindigkeit des Ergebnisses nicht funktioniert. Mindestens ein Jahr schreiben Sie Ihre Entwicklung. Weder die Zeit noch TK, noch das Geld oder der Chef werden Druck auf Sie ausüben. Volle Freiheit und Kreativität.
Nur mit freier Kreativität können Sie verstehen und fühlen, was ein cooler Code ist, die Schönheit von YaP und Technologie erkennen und den Charme von Geschäftsaufgaben spüren. Nun, Sie werden lernen, hochwertigen Code zu schreiben.
Es ist wahr, dass Sie dafür persönliche Zeit aufwenden müssen. Wie in der Tat jede andere Entwicklung. Betrachten Sie dies nicht als Kosten, sondern als Investition in sich.