Wenn Sie in der Softwareentwicklung tätig sind, tauchen ständig neue Techniken, Sprachen und Konzepte auf. Wir alle verspüren hin und wieder diese quälenden Zweifel: „Kann ich mit den Veränderungen Schritt halten und wettbewerbsfähig bleiben?“ Nimm dir einen Moment Zeit und fasse eine Zeile aus meinem Lieblingsfilm Casablanca zusammen: „Die grundlegenden Dinge gelten, wie die Zeit vergeht.“
Alle paar Wochen besuchen wir einige der Lieblingsbeiträge unserer Leser aus der gesamten Geschichte der Website. Dieses Tutorial wurde erstmals im April 2012 veröffentlicht.
Was für die Liebe gilt, gilt auch für den Code.
Was für die Liebe gilt, gilt auch für den Code. Die grundlegenden Dinge werden immer gelten. Wenn Sie ein Verständnis für die zugrunde liegenden Ideen der Softwareentwicklung haben, werden Sie sich schnell auf neue Techniken einstellen. In diesem Tutorial werden wir drei Grundprinzipien diskutieren und sie mit vielen weiteren mischen. Sie bieten eine leistungsstarke Möglichkeit, die Komplexität von Software zu verwalten. Ich werde einige meiner persönlichen Meinungen und Gedanken teilen, die sich hoffentlich als nützlich erweisen werden, wenn es darum geht, sie auf Code und reale Projekte anzuwenden.
Prinzip – Wiederhole dich nicht
Eine grundlegende Strategie zur Reduzierung der Komplexität auf überschaubare Einheiten besteht darin, ein System in Teile zu teilen.
Dieses Prinzip ist so wichtig zu verstehen, dass ich es nicht zweimal schreiben werde! Es wird allgemein mit dem Akronym DRY bezeichnet und kam in dem Buch The Pragmatic Programmer von Andy Hunt und Dave Thomas vor, aber das Konzept selbst ist seit langem bekannt. Es bezieht sich auf die kleinsten Teile Ihrer Software.
Wenn Sie ein großes Softwareprojekt erstellen, werden Sie normalerweise von der Gesamtkomplexität überwältigt sein. Menschen sind nicht gut darin, Komplexität zu managen; Sie sind gut darin, kreative Lösungen für Probleme eines bestimmten Umfangs zu finden. Eine grundlegende Strategie zur Reduzierung der Komplexität auf verwaltbare Einheiten besteht darin, ein System in handlichere Teile zu unterteilen. Zunächst möchten Sie Ihr System möglicherweise in Komponenten unterteilen, wobei jede Komponente ein eigenes Subsystem darstellt, das alles enthält, was zum Ausführen einer bestimmten Funktionalität erforderlich ist.
Wenn Sie beispielsweise ein Content-Management-System erstellen, ist der Teil, der für die Benutzerverwaltung verantwortlich ist, eine Komponente. Diese Komponente kann in weitere Unterkomponenten wie die Rollenverwaltung unterteilt werden und mit anderen Komponenten wie der Sicherheitskomponente kommunizieren.
Wenn Sie Systeme in Komponenten und darüber hinaus Komponenten in Unterkomponenten unterteilen, erreichen Sie eine Ebene, auf der die Komplexität auf eine einzige Verantwortung reduziert wird. Diese Verantwortlichkeiten können in einer Klasse implementiert werden (wir gehen davon aus, dass wir eine objektorientierte Anwendung erstellen). Klassen
enthalten Methoden und Eigenschaften. Methoden implementieren Algorithmen. Algorithmen und – je nachdem, wie obsessiv wir werden wollen – Unterteile von
Algorithmen berechnen oder enthalten die kleinsten Teile, die Ihre Geschäftslogik aufbauen.
Das DRY-Prinzip besagt, dass diese kleinen Wissensstücke in Ihrem gesamten System nur genau einmal vorkommen dürfen.
Sie müssen eine einzige Darstellung enthalten.
Jedes Wissen muss eine einzige, eindeutige, autoritative Repräsentation innerhalb eines Systems haben.
Beachten Sie den Unterschied zwischen dem Wissen und seiner Darstellung. Wenn wir die Datenbankverbindung in unserem CMS implementieren, haben wir ein Code-Snippet, das den Datenbanktreiber initialisiert, die Anmeldeinformationen übergibt und einen Verweis auf die Verbindung in einer Variablen speichert. Das Code-Snippet ist Teil des Wissens, es geht darum, wie etwas erreicht wird. Die Variable mit dem Verweis auf die Verbindung ist die Repräsentation dieses Wissens – und dies kann von anderen Parteien verwendet werden. Wenn sich die Datenbankanmeldeinformationen ändern, müssen wir das Snippet ändern – nicht seine Darstellung.
In einer perfekten Anwendung kapselt jedes kleine Stück Geschäftslogik sein Wissen in einer Repräsentation, nämlich einer Variablen oder einer Klasseneigenschaft.
Diese Variable selbst ist in einer Klasse gekapselt, die als Repräsentation einer Verantwortung beschrieben werden kann. Die Klasse ist in einer Komponente gekapselt, die als Darstellung der Funktionalität beschrieben werden kann.
Dies kann so lange fortgesetzt werden, bis wir die oberste Ebene unseres Softwareprojekts erreichen – also einen Stapel von Darstellungen mit zunehmender Komplexität. Diese Art, die Komplexität von Software zu betrachten, wird als modulare Architektur bezeichnet und ist ein wichtiger Teil davon.
Trockenheit erreichen
DRY ist eine Philosophie, die Logik in Repräsentationen verpackt.
Es gibt viele Möglichkeiten, dies zu erreichen. Hunt und Thomas schlugen (unter anderem) Codegeneratoren und Datentransformation vor. Aber im Wesentlichen ist es eine Philosophie, die Logik in Darstellungen verpackt.
Da jeder Teil Ihrer Anwendung als Repräsentation angesehen werden kann, macht jeder Teil bestimmte Fragmente Ihrer zugrunde liegenden Logik verfügbar: Die Benutzerverwaltung macht den Zugriff für registrierte Benutzer des CMS verfügbar, die Benutzerklasse repräsentiert einen einzelnen Benutzer und macht seine Eigenschaften (wie den Benutzernamen) verfügbar. Es ruft die Eigenschaften über die Darstellung der Datenbank ab.
TROCKENE und modulare Architektur erfordert eine gute Planung. Um eine repräsentative Hierarchie von unten nach oben zu erreichen, teilen Sie Ihre Anwendung in eine Hierarchie logisch getrennter kleinerer Teile und lassen Sie sie miteinander kommunizieren. Wenn Sie größere Projekte verwalten müssen, ist es eine gute Idee, sie in Komponenten zu organisieren und innerhalb der Komponenten zu verwenden. Versuchen Sie, die folgenden Regeln anzuwenden:
- Erstellen Sie eine visuelle Hierarchie Ihrer Softwareanwendung und ordnen Sie ihr die Hauptkomponenten zu. Komplexe Projekte erfordern möglicherweise eine dedizierte Karte für jede Komponente.
- Wenn Sie zu einer Ebene verbundener Verantwortlichkeiten gelangen, möchten Sie möglicherweise zu UML-Diagrammen (oder ähnlichem) wechseln.
- Bevor Sie einen Codeabschnitt schreiben, benennen Sie dessen Hierarchie in Ihrem Softwareprojekt. Definieren Sie, was es darstellt, und stellen Sie sicher, dass Sie seine Rolle in der umgebenden Komponente kennen.
- Definieren Sie, was die Darstellung anderen Parteien zugänglich machen soll (z. B. Funktionen zum Ausführen von SQL in einem Datenbanktreiber) und was sie verbergen soll (z. B. die Datenbankanmeldeinformationen).
- Stellen Sie sicher, dass Darstellungen nicht von Darstellungen einer anderen Komplexitätsstufe abhängen (wie eine Komponente, die von einer Klasse in einer anderen Komponente abhängt).
Der Datenbanktreiber ist ein vereinfachtes Beispiel, da in der realen Welt viel mehr Ebenen beteiligt sind (z. B. eine bestimmte Datenbankabstraktionsschicht) und Sie viel mehr tun können, um Logik zu kapseln – insbesondere das Eintauchen in Entwurfsmuster. Aber selbst wenn Sie gerade erst mit dem Codieren begonnen haben, sollten Sie eines beachten:
Wenn Sie feststellen, dass Sie Code schreiben, der etwas ähnelt oder dem entspricht, was Sie zuvor geschrieben haben, nehmen Sie sich einen Moment Zeit, um darüber nachzudenken, was Sie tun, und wiederholen Sie sich nicht.
In der realen Welt sind Anwendungen, die zu 100% TROCKEN sind, schwer, wenn nicht gar unmöglich zu erreichen. Anwendungen, die in inakzeptablem Maße untrocknet und daher schwer zu warten sind, sind jedoch weit verbreitet. Daher ist es nicht verwunderlich zu erfahren, dass mehr als 50% aller Softwareprojekte fehlschlagen – wenn Sie sich den Code ansehen.
Viele Leute neigen dazu zu denken, dass schlechter Code von schlechten Programmierern produziert wird. Meiner Erfahrung nach ist dies eine Ausnahme. Meistens wird schlechter Code von schlechten Account Managern und einer allgemeinen Fehlkonfiguration des Prozessmanagements in Unternehmen erzeugt.
Schlechter Code wird selten von schlechten Programmierern erzeugt.
Ein Beispiel
Trockenheit wird durch gute Planung erreicht.
Angenommen, Sie werden als technischer Berater von einem Unternehmen eingestellt, das Probleme mit der Codequalität und -wartung hat. Sie überprüfen die Quelle und sehen Hacks und Code-Duplizierung – der Code ist nicht TROCKEN. Dies ist ein Symptom für schlechte Codequalität, es ist nicht der Grund. Wenn Sie sich das Versionskontrollsystem ansehen – auch bekannt als die Geschichte des Codes -, besteht die Möglichkeit, dass Sie Hacks finden, die manchmal in der Nähe von Fristen und Meilensteinen eingeführt wurden. Nehmen Sie sich die Zeit, um zu überprüfen, welche Änderungen vorgenommen werden, und Sie werden wahrscheinlich mit einer Änderung der Anforderungen konfrontiert.
Wie oben erwähnt, wird Trockenheit durch gute Planung erreicht. Erzwungene Änderungen an einem harten Termin zwingen Entwickler, schmutzige Lösungen zu implementieren. Sobald der Code kompromittiert ist, wird das Funktionsprinzip bei weiteren Änderungen wahrscheinlich vollständig geopfert.
Es gibt einen Grund, warum die erfolgreichsten Unternehmen im IT-Business von Menschen mit sehr gutem technischen Verständnis gegründet wurden – oder sogar von Programmierern selbst: Bill Gates, Mark Zuckerberg, Steve Wozniak, Steve Jobs, Larry Page, Sergey Brin und Larry Ellison wissen (oder wussten), welche Anstrengungen nötig sind, um etwas umzusetzen. Im Gegensatz dazu neigen viele Unternehmen dazu, die Anforderungen an das Engineering in die Hände von Account Managern und den konzeptionellen Teil in die Hände von Unternehmensberatern zu legen…menschen, die noch nie etwas umgesetzt haben.
Daher funktionieren viele technische Konzepte nur in Powerpoint, Photoshop und auf 27″-Widescreen-Displays. Dies mag in den Tagen mehr oder weniger statischer Websites ein erfolgreicher Ansatz gewesen sein, aber heutzutage nicht mehr – mit interaktiven Anwendungen auf mehreren Geräten. Da Programmierer die letzten in der Reihe sind, müssen sie Fehler im Konzept schnell beheben. Wenn dies von einem Account Manager begleitet wird, der einem Kunden, der gerne Änderungen in letzter Minute vornimmt, nicht standhalten kann, werden Pläne in den Müll geworfen und etwas Schnelles und Schmutziges umgesetzt. Der Code wird ungetrocknet.
Dieses Beispiel ist ein bisschen extrem (trotzdem habe ich solche Szenarien erlebt), aber es zeigt, dass DRY ein theoretisches Konzept ist, das von verschiedenen Parteien in der realen Welt in Frage gestellt wird. Wenn Sie in einem Unternehmen arbeiten, das Sie dazu zwingt, auf diese Weise zu arbeiten, können Sie einige Änderungen am Prozess vorschlagen (z. B. die Einführung von technischem Fachwissen in einer früheren Phase technischer Projekte).
Wenn Sie einen Hands-off-Ansatz haben, lesen Sie weiter! Das You ain’t gonna need it Prinzip wird zur Rettung kommen.
Prinzip – Halte es einfach Dumm
Die einfachste Erklärung ist tendenziell die richtige.
Im späten 19.Jahrhundert bemühten sich Physiker zu erklären, wie Schwerkraft, Magnetismus und Optik zusammenwirken, wenn es um große Entfernungen geht – wie die Entfernungen in unserem Sonnensystem. Daher wurde ein Medium namens Äther postuliert. Es wurde gesagt, dass Licht durch dieses Medium reist, und dass es für Effekte verantwortlich ist, die nicht anders erklärt werden könnten. Im Laufe der Jahre wurde die Theorie um Annahmen erweitert, die das Ätherpostulat an die Ergebnisse von Experimenten anpassten. Einige Annahmen waren willkürlich, andere führten zu anderen Problemen, und die ganze Theorie war ziemlich komplex.Ein Angestellter des Schweizerischen Patentamts, Albert Einstein, schlug vor, die ganze Äthertheorie loszuwerden, als er eine einfache, aber revolutionäre Idee einführte: Die ganze Seltsamkeit beim Rechnen mit großen Entfernungen würde verschwinden, wenn wir akzeptieren würden, dass die Zeit keine Konstante ist; es ist relativ. Diese Art des Out-of-the-Box-Denkens, um zu der einfachsten Erklärung mit den wenigsten Annahmen zu kommen, um zwischen konkurrierenden Szenarien zu wählen, wird als Ockhams’Rasiermesser bezeichnet.
In vielen Bereichen gibt es ähnliche Konzepte. In der Softwareentwicklung (und anderen) bezeichnen wir es als KISS. Es gibt viele Varianten für dieses Akronym, aber alle bedeuten, dass Sie nach dem einfachsten Weg streben sollten, etwas zu tun.
HTTP
Das Hypertext Transfer Protocol wird allgemein als perfektes Beispiel für eine einfache Lösung angesehen: entwickelt, um Hypertext-basierte Dokumente zu übertragen, ist es heutzutage das Rückgrat hochgradig interaktiver und desktop-ähnlicher Anwendungen. Vielleicht müssen wir Lösungen für Einschränkungen im Protokoll finden, und vielleicht müssen wir es eines Tages ersetzen. Der Status quo ist jedoch: Basierend auf einigen Anforderungsmethoden (wie GET und POST), Statuscodes und Klartextargumenten hat sich HTTP als flexibel und robust erwiesen. Deshalb wurde HTTP von Webentwicklern immer wieder an seine Grenzen gebracht – und steht immer noch.
Wir halten diesen Ansatz für selbstverständlich, aber die Geschichte der Softwareentwicklung und Standardisierung ist voll von übermäßig komplexen und unausgegorenen Lösungen. Es gibt sogar ein spezielles erfundenes Wort dafür: Bloatware. Software wie diese wird auch als DOD, dead on arrival, beschrieben. Ich habe eine Theorie, die meiner Theorie des trockenen Codes sehr ähnlich ist, wenn es um Bloatware geht… Der Erfolg des Internets kann jedoch als Erfolg einfacher, aber effizienter Lösungen beschrieben werden.
Was ist also erforderlich, um zu einer möglichst einfachen Lösung zu gelangen? Es kommt auf Wartbarkeit und Verständlichkeit in der Softwareentwicklung an. KISS setzt daher in der Phase des Requirements Engineerings ein. Wenn Sie darüber nachdenken, wie Sie die Anforderungen eines Kunden in implementierbare Komponenten umwandeln können, versuchen Sie, die folgenden Teile zu identifizieren:
- Funktionalität, die ein unangemessenes Verhältnis zwischen Nutzen und Aufwand aufweist.
- Funktionalität, die stark von anderen Funktionen abhängig ist.
- Funktionalität, die wahrscheinlich an Komplexität zunehmen wird.
Am konzeptionellen Prozess sind viele Personen beteiligt, die nicht über das technische Know-how verfügen, um eine zuverlässige Kosten-Nutzen-Analyse durchzuführen
Ich habe einmal an einem Projekt gearbeitet, bei dem der Kunde Excel-Tabellen in seine Crew-Management-Software importieren wollte. Das war ein klares Match. Excel ist eine proprietäre Software mit einem komplexen Dokumentformat. Das Format ist komplex, weil es reich an Funktionen ist: Sie können Diagramme und andere Dinge hinzufügen – Funktionen, die vom Client nicht benötigt wurden. Er interessierte sich nur für die Zahlen. Daher würde die Implementierung des Excel-Imports die Implementierung vieler unnötiger Funktionen erfordern. Darüber hinaus gibt es mehrere Versionen von Excel-Versionen, und Microsoft feuert jedes Jahr eine weitere Version ab. Dies wäre schwer aufrechtzuerhalten gewesen und in Zukunft mit zusätzlichen Kosten verbunden.
Am Ende haben wir einen kommagetrennten Wertimport implementiert. Dies geschah mit ein paar Zeilen Code. Der Overhead der Daten war sehr gering (vergleichen Sie ein Excel-Blatt mit dem CSV-Äquivalent) und die Lösung war wartbar und zukunftssicher. Excel war sowieso bereit, CSV zu exportieren (sowie andere Programme, die der Client möglicherweise in Zukunft verwenden möchte). Da die Lösung auch günstig war, war es eine gute Anwendung des KISS-Prinzips.
Um es zusammenzufassen: Versuchen Sie, über den Tellerrand hinauszudenken, wenn Ihnen eine Aufgabe kompliziert erscheint. Wenn Ihnen jemand seine Anforderungen erklärt und Sie denken, dass die Implementierung schwierig und komplex sein wird, haben Sie unter fast allen Umständen Recht. Während einige Dinge genau das sind – schwer zu implementieren – sind überkomplizierte Lösungen durchaus üblich. Dies ist der Fall, weil viele Menschen in den konzeptionellen Prozess involviert sind, die nicht über das technische Know-how verfügen, um eine zuverlässige Kosten-Nutzen-Analyse durchzuführen. Daher sehen sie das Problem nicht. Überprüfen Sie die Anforderungen noch einmal, ob sie wirklich auf das Wesentliche reduziert sind, das der Kunde benötigt. Nehmen Sie sich Zeit, um kritische Punkte zu diskutieren und zu erklären, warum andere Lösungen besser geeignet sind.
Prinzip – Du „Wirst es nicht brauchen
Beim Codieren geht es darum, Dinge zu bauen.
Als Google+ startete, war Mark Zuckerberg – Gründer von Facebook – einer der ersten, der ein Konto im sozialen Netzwerk erstellte, das sein eigenes abbauen wollte. Er fügte dem Abschnitt Über mich nur eine Zeile hinzu: „Ich baue Dinge.“. Ich denke ehrlich, dass dies ein brillanter Satz ist, weil er die reine Essenz des Codierens in wenigen einfachen Worten beschreibt. Warum hast du dich entschieden, Programmierer zu werden? Begeisterung für technische Lösungen? Die Schönheit der Effizienz? Was auch immer Ihre Antwort ist, es kann nicht sein „building the 1.000.001. Unternehmenswebsite mit Standardfunktionalität“. Die meisten von uns verdienen jedoch auf diese Weise Geld. Egal wo Sie arbeiten, Sie werden wahrscheinlich ab und zu mit langweiligen und sich wiederholenden Aufgaben konfrontiert.
80% der für ein Softwareprojekt aufgewendeten Zeit wird in 20% der Funktionalität investiert.
Das You ain’t gonna need it Prinzip (YAGNI) beschäftigt sich mit diesen Aufgaben. Es bedeutet im Grunde: Wenn es nicht im Konzept ist, ist es nicht im Code. Beispielsweise ist es üblich, den Datenbankzugriff in einer Ebene zu abstrahieren, die die Unterschiede zwischen verschiedenen Treibern wie MySQL, PostgreSQL und Oracle behandelt. Wenn Sie an einer Unternehmenswebsite arbeiten, die auf einem LAMP-Stack auf einem gemeinsam genutzten Host gehostet wird, wie wahrscheinlich ist es, dass die Datenbank geändert wird? Denken Sie daran, dass das Konzept unter Berücksichtigung des Budgets geschrieben wurde.
Wenn es kein Budget für die Datenbankabstraktion gibt, gibt es keine Datenbankabstraktion. Wenn das unwahrscheinliche Ereignis einer Datenbankänderung eintritt, ist es eine natürliche Sache, die Änderungsanforderung in Rechnung zu stellen.
Sie haben vielleicht den Unterschied zwischen You ain’t gonna need it und DRY-driven modular architectures bemerkt: Letzteres reduziert die Komplexität, indem es ein Projekt in überschaubare Komponenten aufteilt, während ersteres die Komplexität reduziert, indem es die Anzahl der Komponenten reduziert. YAGNI ähnelt dem KISS-Prinzip, da es nach einer einfachen Lösung strebt. KISS strebt jedoch nach einer einfachen Lösung, indem versucht wird, etwas so einfach wie möglich zu implementieren; YAGNI strebt nach Einfachheit, indem es es überhaupt nicht implementiert! Theodore Sturgeon, ein amerikanischer Science-Fiction-Autor, erklärte das Gesetz: „neunzig Prozent von allem ist Mist“. Dies ist ein sehr radikaler Ansatz und in realen Projekten nicht allzu hilfreich. Denken Sie jedoch daran, dass „Mist“ sehr zeitaufwändig sein kann. Eine gute Faustregel lautet: Rund 80% der Zeit, die für ein Softwareprojekt aufgewendet wird, wird in 20% der Funktionalität investiert. Denken Sie an Ihre eigenen Projekte! Jedes Mal, wenn ich das tue, bin ich überrascht von der Genauigkeit der 80:20-Regel.
Wenn Sie in einem Unternehmen arbeiten, das für enge Fristen und ungenaue Konzepte berüchtigt ist, ist dies eine leistungsstarke Strategie. Sie werden nicht für die Implementierung einer Datenbankabstraktionsschicht belohnt. Es besteht die Möglichkeit, dass Ihr Chef nicht einmal weiß, was eine Datenbankabstraktionsschicht ist.
Während dieses Konzept einfach klingen mag, kann es schwierig sein, die notwendigen von den unnötigen Teilen zu unterscheiden. Wenn Sie beispielsweise mit einer Bibliothek oder einem Framework vertraut sind, das Datenbankabstraktion verwendet, sparen Sie beim Dumping nicht viel Zeit. Das Schlüsselkonzept ist eine andere Sichtweise auf Software: wir sind darin geschult, zukunftssichere und wartbare Software zu schreiben. Das bedeutet, dass wir darin geschult sind, vorausschauend zu denken. Welche Änderungen können in Zukunft auftreten? Dies ist entscheidend für größere Projekte, aber Overhead für kleinere. Denken Sie nicht in die Zukunft! Wenn eine kleine Unternehmenswebsite grundlegende Änderungen vornimmt, müssen sie möglicherweise von vorne beginnen. Dies ist im Vergleich zum Gesamtbudget kein signifikantes Problem.
Ein Projekt planen
Wenn Sie Ihre To-Do-Liste für ein Projekt vorbereiten, sollten Sie die folgenden Gedanken berücksichtigen:
- Erreichen Sie eine geringere Komplexität, indem Sie den Abstraktionsgrad reduzieren.
- Funktionalität von Features trennen.
- Gehen Sie von moderaten nicht funktionalen Anforderungen aus.
- Identifizieren Sie zeitraubende Aufgaben und beseitigen Sie sie.
Lassen Sie uns ein wenig ins Detail gehen! Ich habe bereits ein Beispiel für das erste Element in der Liste angegeben: Wickeln Sie keinen Datenbanktreiber um eine Datenbankabstraktionsschicht. Seien Sie misstrauisch gegenüber allem, was Ihrem Software-Stack Komplexität verleiht. Beachten Sie, dass die Abstraktion häufig von Bibliotheken von Drittanbietern bereitgestellt wird. Zum Beispiel – abhängig von Ihrer Programmiersprache – wird eine Persistenzschicht wie Hibernate (Java), Doctrine (PHP) oder Active Record (Ruby) mit Datenbankabstraktion und objektrelationaler Zuordnung geliefert. Jede Bibliothek fügt Komplexität hinzu. Es muss gepflegt werden. Updates, Patches und Sicherheitsupdates müssen angewendet werden.
Wir implementieren jeden Tag Funktionen, weil wir erwarten, dass sie nützlich sind. Daher denken wir voraus und setzen zu viel um. Zum Beispiel möchten viele Kunden eine mobile Website haben. Mobile ist ein Begriff des breiten Verständnisses; Es ist keine Designentscheidung. Es ist ein Anwendungsfall! Menschen, die eine mobile Website verwenden, sind, gut, mobil. Das bedeutet, dass sie möglicherweise auf andere Informationen oder Funktionen zugreifen möchten als ein Benutzer, der die Website entspannt auf seinem Desktop besucht. Stellen Sie sich eine Kinoseite vor: Benutzer im Bus möchten wahrscheinlich auf die Startzeit kommender Filme zugreifen, nicht auf den 50-MB-Trailer.
Schlechte Konzepte können oft durch das Fehlen nicht funktionaler Anforderungen identifiziert werden.
Mit einem angemessenen Budget würden Sie eine dedizierte Analyse der Anforderungen für Mobilgeräte durchführen. Ohne diese Analyse geben Sie einfach die gleichen Informationen wie auf der Desktop-Site an. Dies wird für viele Umstände in Ordnung sein! Da mobile Browser Desktop-Sites sehr geschickt an ihre Anzeige anpassen, besteht ein radikaler YAGNI-Ansatz möglicherweise darin, überhaupt keine mobile Site zu schreiben!
Nicht-funktionale Anforderungen beschreiben nicht das Verhalten einer Software, sie beschreiben zusätzliche Eigenschaften, anhand derer die Qualität einer Software beurteilt werden kann. Da die Beschreibung von Softwarequalität Wissen über Software voraussetzt, können schlechte Konzepte oft durch das Fehlen nicht funktionaler Anforderungen identifiziert werden. Wartbarkeit, Dokumentationsgrad und einfache Integration sind Beispiele für nicht funktionale Anforderungen. Nicht funktionale Anforderungen sollten messbar sein. Daher „Sollte die Seite schnell geladen werden.“ ist zu unkonkret“, sollte die Seite während eines durchschnittlichen Leistungstests in maximal zwei Sekunden geladen werden.“ ist sehr konkret und messbar. Wenn Sie das YAGNI-Prinzip anwenden möchten, gehen Sie von moderaten nicht funktionalen Anforderungen aus, wenn diese nicht im Konzept erwähnt werden (oder wenn sie erwähnt werden, aber nicht konkret sind). Wenn Sie die nicht funktionalen Anforderungen selbst schreiben, seien Sie realistisch: Ein kleines Unternehmen mit 20-50 Seitenbesuchen pro Tag benötigt keine drei Tage Leistungsoptimierung – da die Seite schnell genug geladen werden sollte, da der Server nicht ausgelastet ist. Wenn das Unternehmen die Anzahl der täglichen Besuche erhöhen kann, sollte ein besserer Server oder ein besseres Hosting-Paket nicht zu teuer sein.
Denken Sie zu guter Letzt an die 80:20-Faustregel!
Denken Sie zu guter Letzt an die 80:20-Faustregel! Wir müssen die zeitraubenden Teile identifizieren. Wenn ein Teil absolut notwendig ist, müssen Sie es implementieren. Die Frage sollte sein: Wie werden Sie es implementieren? Muss es das neueste Framework mit einer kleinen Community sein? Müssen Sie zur gerade veröffentlichten Version einer Bibliothek wechseln, wenn die Dokumentation nicht auf dem neuesten Stand ist? Sollten Sie das neue CMS verwenden, wenn nicht alle Erweiterungen verfügbar sind? Wie viel Forschung wird dafür notwendig sein? „So haben wir es immer gemacht.“ ist kein aufregender Ansatz, aber es wird die Arbeit ohne Überraschungen erledigen.
Es ist wichtig zu verstehen, dass all dies nicht bedeutet, dass Sie unterwegs schmutzigen Code mit Hacks schreiben können! Sie schreiben eine leichte Anwendung, keine unordentliche! Sie werden es jedoch nicht brauchen, ist ein praktischer Ansatz. Wenn es dazu führen würde, dass viele Codezeilen ein paar Zeilen Code-Duplikate reduzieren, denke ich persönlich, dass Sie die Bemühungen mit dem Budget in Verbindung bringen können, und eine gewisse Unordnung ist in Ordnung. Es ist eine kleine Anwendung. Daher ist der zusätzliche Wartungsaufwand akzeptabel. Wir sind in der realen Welt.
Kommen wir zurück zum ursprünglichen Gedanken: Wir bauen gerne Dinge. Als Beethoven die Diabelli-Variationen schrieb, war es Auftragsarbeit. Ich glaube nicht, dass er Kompromisse beim Budget gemacht hat. Er ging die Extrameile, weil er keine durchschnittliche Musik schreiben wollte; Er wollte eine perfekte Komposition schreiben.
Ich impliziere sicherlich nicht, dass wir alle Genies sind und dass unsere Brillanz durch jede Codezeile scheinen sollte, aber ich denke gerne an Softwarearchitektur als Kompositionen. Ich bin ein leidenschaftlicher Entwickler, weil ich perfekte Kompositionen bauen möchte, und ich möchte stolz auf die Dinge sein, die ich baue.
Wenn Sie ein erfahrener und geschäftssicherer Entwickler sein möchten, müssen Sie das You ain’t gonna need it-Prinzip beherrschen. Wenn du deine Leidenschaft behalten willst, musst du ab und zu dagegen ankämpfen.
Zusammenfassung
Softwareprinzipien sind eine Art, Software zu betrachten. Für mich sollte ein gutes Prinzip auf einem einfachen Konzept basieren, aber es sollte sich zu einem komplexen Konstrukt von Ideen entwickeln, wenn es mit anderen Techniken und Philosophien konfrontiert wird. Was sind Ihre bevorzugten Softwareprinzipien?