Warum braucht Unternehmen guten Code?

Im Bereich der Softwareentwicklung gibt es häufig Thesen wie „ Niemand kümmert sich um Ihren Code “ (Übersetzung - „ Ihr Code interessiert niemanden “), „Code ist nur ein Werkzeug“ und Situationen völliger Missverständnisse seitens des Unternehmens, warum wir uns Zeit nehmen sollten und Geld für eine Art "Refactoring" des Codes, der bereits funktioniert.

Ich möchte Ihnen sagen, wozu die „Betonung von Merkmalen“ führen kann, anstatt sich um die Qualität des Codes zu kümmern, und warum nicht nur Programmierer guten Code benötigen.

Unterstützung

Die Hauptthese, ohne die der aktuelle Artikel grundsätzlich bedeutungslos wäre:

Was in der Programmierwelt seit Jahrzehnten passiert, um fortgeschrittenere Sprachen, Paradigmen und Ansätze zu entwickeln, für die sie verschiedene Vorlagen unterscheiden und sich um das Code-Design kümmern, sind in der Tat zwei Dinge - die Geschwindigkeit der Entwicklung zu erhöhen und die Unterstützung der Codebasis zu erleichtern (welche im Wesentlichen die Geschwindigkeit der Entwicklung neuer Funktionen).
Und das sind die Dinge, die das Geschäft braucht.

Man kann natürlich argumentieren, dass sie selbst die Methoden benötigen, die die Effizienz der Arbeit der Programmierer erhöhen, um ihre Arbeit teurer zu verkaufen und mehr pro Zeiteinheit leisten zu können, aber weil die Situation, in der Programmierer sofort ein großes abgeschlossenes Projekt bestellen, ohne dass weitere Unterstützung erforderlich ist, sehr groß ist Es ist selten und in der Regel wird die Funktionalität schrittweise bestellt. Zu Beginn des Projekts werden Sie die schädlichen Auswirkungen eines schlechten Designs nicht spüren. Es ist eher eine Investition in die Zukunft.

Es gibt ein Bild aus Martin Fowlers Blog zu diesem Thema, das die Geschwindigkeit der Einführung neuer Funktionen in das Projekt in Abhängigkeit von seiner Existenzzeit (d. H. Wie groß es ist) zeigt.



Die horizontale Achse ist die Projektlebensdauer, die vertikale Achse ist die Aggregatfunktionalität.

Die rote Linie zeigt die Entwicklungsgeschwindigkeit eines Projekts mit einem guten Design, und die blaue Linie zeigt ein Projekt, das ohne Einschränkungen in Form von Anforderungen an die Qualität des Codes geschrieben wurde.

Wenn Sie also der Meinung sind, dass Ihre Anwendung zum Scheitern verurteilt ist und sich nicht entwickeln wird oder sich ausschließlich auf ein bevorstehendes Ereignis vorbereitet, müssen Sie nicht über das Design des Systems nachdenken. In der gegenteiligen Situation zahlt sich ein gutes Design wahrscheinlich aus und zahlt sich oft aus.

Manchmal kann man die Meinung hören, dass man zu Beginn eines Projekts nicht über die Qualität des Codes nachdenken und ihn nach einer erfolgreichen Präsentation für Kunden / Investoren erneut schreiben muss. In den allermeisten Fällen ist dies jedoch ein Fehler beim Starten von Projekten und der einfachste Weg, um über Jahre hinweg technische Schulden zu verdienen.

Code ist kein Werkzeug, Code ist ein Endprodukt

Ein Softwareunternehmen verwendet keinen Code als Werkzeug. Dies ist das Hauptprodukt des Unternehmens. Es ist der endgültige Code des Programms, der die Qualität, Geschwindigkeit und Einhaltung der Anforderungen an die Funktionalität bestimmt. Es kann nicht einfach genommen und vollständig ersetzt werden, ohne vorübergehende und materielle Verluste zu verursachen, wie dies bei Computer- / IDE- / Entwicklungsmethoden der Fall sein könnte, bei denen es sich im Wesentlichen um Werkzeuge zur Erstellung eines Produkts handelt.

Über "Fokus auf Leistung"

In dem Artikel, auf den ich mich bezog, wurde der folgende Gedanke geäußert: Sie müssen mit dem Kunden / Projektmanager auf der Ebene der Projektbereitschaft kommunizieren, und das folgende Beispiel war das Gegenteil:

Stellen Sie sich vor, der Designer erzählt Ihnen von den Ebenen, die er in Photoshop verwendet hat, wie viele Objekte er dort hat, welche Verläufe auf welchen Pinseln verwendet werden und welche coolen Animationsskripte er geschrieben hat. Es interessiert dich nicht. Interessieren Sie sich, ob es bereits möglich ist, Bilder aufzunehmen.

Also. Es gibt einen Unterschied, aufgrund dessen es nicht einfach mit der Unterstützung eines Softwareprodukts auf die Situation projiziert werden kann: Alle diese Ebenen und Pinsel in Photoshop werden unmittelbar nach dem Ergebnis der Arbeit (Bilder) für niemanden unnötig und sind dennoch ein Werkzeug, um das Ergebnis zu erzielen , nicht das Endprodukt.

Daher kann sich der Kunde bei der Erstellung der Anforderungen für die endgültigen Bilder keine Gedanken darüber machen, was in dem Prozess verwendet wird. Wenn der Kunde (Unternehmen) im Fall von Software nur Funktionen von der Anwendung verlangt, läuft er Gefahr, genau das zu erhalten, was er wollte - neue Funktionen, aber es stand außer Frage, dass diese gewartet und weiterentwickelt werden müssten.

Leider ist dies ein ziemlich häufiges Problem beim Outsourcing, wenn ein Unternehmen nur die Zeit seiner Entwickler verkauft und Kunden die Qualität des Systems und die zur Lösung seiner Probleme erforderliche Zeit nicht objektiv bewerten können. Wenn die Kosten für die Änderung des Codes exponentiell steigen, kommt dies nur dem Unternehmen selbst gegenüber dem Outsourcer zugute - mehr Arbeitsstunden können monetarisiert werden, und das Unternehmen, das das Produkt bestellt, ist bereits am Haken -, um das sperrige und unpraktische System neu zu schreiben, da es enorme Investitionen erfordert und die Bereitstellung neuer Funktionen stoppt das kann nicht erlaubt werden.

Code - der Arbeitsplatz des Programmierers

Während der gesamten Zeit, in der der Artikel in Entwurfskopien verfasst war, dachte ich viel darüber nach, ob dieser Artikel darin enthalten sein sollte, aber nach ein wenig Beobachtung der Prioritäten von Kandidaten, die Arbeit suchen, wurde mir klar, dass dieser Moment wirklich wichtig ist.

Code ist etwas, mit dem ein Programmierer jeden Tag arbeiten muss, sein kreatives Produkt, was er erstellt, aber nicht nur eines, sondern in einem Team und oft nicht von Grund auf neu. Er muss den bereits vorhandenen Teil des Projekts akzeptieren und ihn auf der Grundlage der zuvor geschriebenen Funktionalität entwickeln. Ein Mitarbeiter wird höchstwahrscheinlich unangenehm sein, in einem Produkt zu arbeiten, das schlecht erstellt wurde.
Meiner Meinung nach arbeitet in erster Linie das Team an dem Projekt zusammen. Die Qualität des resultierenden Produkts hängt direkt davon ab, wie die Teamarbeit aufgebaut ist, von den internen Regeln und den darin festgelegten Anforderungen.

An zweiter Stelle steht die Technologie. Ein gedankenlos ausgewähltes oder ererbtes unbequemes Framework, veraltete und qualitativ minderwertige Tools, Bibliotheken, die mit all ihren Krücken und Fehlern, die Sie in Kauf nehmen müssen, an den Projektort genagelt sind, und der Mangel an Personen mit ausreichenden Kompetenzen und Zeit, um ältere Ansätze zu beseitigen, können leicht neue Potenziale abschrecken Arbeiter. Zusätzlich zu den oben genannten Gründen ist dies auch eine geringere Anzahl von Perspektiven und Möglichkeiten für die Entwicklung von Programmierern, da anstelle des Studiums moderner und effektivster Werkzeuge Requisiten entwickelt werden müssen, um Lösungen aus aktuellen Gründen an aktuelle Probleme anzupassen.

Warum ist das alles?

Leider können die Anforderungen für reale Anwendungen selten zu 100% gebildet werden und müssen während der Entwicklung nicht überarbeitet werden. Darüber hinaus ist die Situation fast unmöglich, wenn das Projekt nach dem Start nicht an neue Anforderungen angepasst werden muss. Das Geschäft expandiert, entwickelt sich, erfordert Funktionen, die zuvor nicht besprochen wurden, und betritt neue Märkte.

Es ist fast unmöglich, eine Architektur zu bauen, die unter solchen Bedingungen ideal und bis ins kleinste Detail durchdacht ist, und oft besteht keine Notwendigkeit, da ihre Kosten in diesem Fall für die Anfangsphase des Projekts unangemessen hoch sind.

Sicherlich sollte das Schreiben von gutem Code keine Kopfschmerzen für diejenigen sein, die Software bei Programmierern bestellen, und es ist unwahrscheinlich, dass jeder, der sie nicht schreiben kann, sie überprüfen kann.

Dennoch muss ein Unternehmen, das ein Softwareprodukt entwickelt, wenn es es qualitativ herstellen möchte, verstehen, dass ein so wichtiger Teil des Produkts wie sein Quellcode seinen Erfolg direkt beeinflusst, und Dinge wie die Umgestaltung des Quellcodes und die Anpassung der Architektur an die neuen Anforderungen sollten dies auch tun ein Budget sein, sollte Programmierer Zeit zugewiesen werden. Wenn sich jemand für die Qualität des Produkts interessiert, natürlich.

Die IT-Branche entwickelt sich jedoch, Produkte, Unternehmen und Tools entwickeln sich, Benutzer werden selektiver, der Wettbewerb nimmt zu und es besteht die Hoffnung, dass die Zukunft weiterhin mit qualitativ hochwertigen Produkten verbunden sein wird.

Fazit

Tatsächlich ist das Thema des Artikels natürlich sehr kontrovers.

Die obige Grafik beantwortet nicht die Frage, zu welchem ​​Zeitpunkt sich das Design des Systems auszahlt.

Technische Schulden dafür und Schulden, die es Ihnen ermöglichen, jetzt etwas mehr Zeit zu haben und sie später mit Zinsen zurückzugeben. Das Hauptproblem ist äußerst einfach und ähnelt stark einem ähnlichen Phänomen in der Wirtschaft. Es ist die Unfähigkeit, Schulden abzuzahlen, und die Unfähigkeit, zukünftige Einnahmen genau abzuschätzen.

Die Qualität des Codes ist ebenfalls sehr subjektiv und leider praktisch nicht formalisiert, da sonst die Programmierer bereits durch Roboter ersetzt werden könnten.

In jedem Fall ist es das Wichtigste, kompetente Kompromisse zu erzielen und den Mittelweg zu finden, der es uns ermöglicht, das Projekt bei der Verfolgung der Funktionalität nicht in der technischen Verschuldung zu ertränken und den Wettbewerbern keine interessante Nische zu überlassen, indem wir Systemdesign statt Funktionalität betreiben.