So erstellen Sie Observability für Forge-Anwendungen

Softwareentwicklungsteams sind dafür bekannt, eine Vielzahl agiler Methoden, Ansätze und Tools einzusetzen, um Kunden einen Mehrwert zu bieten. Je nach den Bedürfnissen des Teams und der am Produkt Beteiligten ist es üblich, dass Teams eine Kombination von Softwareentwicklungsmethoden einsetzen und nutzen.

Die meisten Entwicklungsteams kombinieren Methoden und Frameworks, um ihren eigenen einzigartigen Ansatz für die Produktentwicklung zu entwickeln. Sie werden feststellen, dass sich viele Prinzipien von einer Methode zur nächsten überschneiden. Der Schlüssel liegt darin, ein System auszuwählen und als Team daran zu arbeiten, diesen Ansatz zu verfeinern und zu verbessern, damit Sie weiterhin Verschwendung reduzieren, die Effizienz maximieren und die Zusammenarbeit optimieren können.

In diesem Beitrag werden wir die folgenden acht Softwareentwicklungsprozesse skizzieren und vergleichen:

1. Methodik der agilen Softwareentwicklung

2. Wasserfall-Methodik

3. Funktionsorientierte Entwicklung (FDD)

4. Methodik der schlanken Softwareentwicklung

5. Methodik der Scrum-Softwareentwicklung

6. Extreme Programmierung (XP)

7. Schnelle Anwendungsentwicklung (RAD)

8. DevOps-Bereitstellungsmethodik

1. Methodik der agilen Softwareentwicklung

Agil ist der gebräuchlichste Begriff zur Beschreibung von Entwicklungsmethoden. Er wird häufig als Überbegriff für Methoden verwendet, die agil sind. Dabei handelt es sich um einen iterativen Prozess, der Verschwendung reduziert und die Effizienz maximiert.

Die meisten Softwareentwicklungsmethoden sind agil und legen im Gegensatz zum traditionellen Projektmanagement einen starken Schwerpunkt auf Iteration, Zusammenarbeit und Effizienz. Es ist, als würde man Jazz mit klassischer Musik vergleichen. 🎷

Traditionelle, lineare Managementmethoden, wie die Wasserfallmethode, auf die wir weiter unten eingehen werden, sind wie klassische Musik, die von einem Dirigenten geleitet wird, der einen festen Plan hat, wie die Musik gespielt werden sollte. Der agile Prozess ähnelt dagegen eher dem Jazz, der durch Zusammenarbeit, Experimente und Iteration zwischen den Bandmitgliedern zustande kommt. Er ist anpassungsfähig und entwickelt sich mit neuen Ideen, Situationen und Richtungen weiter.

2. Die Wasserfall-Methodik

Das Wasserfall-Ansatz ist eine traditionelle Methode, die in der Softwareentwicklung nicht mehr sehr verbreitet ist. Viele Jahre lang war das Wasserfallmodell die führende Methode, aber sein starrer Ansatz konnte den dynamischen Anforderungen der Softwareentwicklung nicht gerecht werden.

Es ist üblicher, dass die Wasserfallmethode eher für das Projektmanagement als für die Produktentwicklung verwendet wird. Zu Beginn eines Projekts sammeln Projektmanager alle notwendigen Informationen und verwenden sie, um im Vorfeld einen fundierten Aktionsplan zu erstellen. Normalerweise ist dieser Plan ein linearer, schrittweiser Prozess, bei dem eine Aufgabe in die nächste übergeht, was ihr den Namen „Wasserfall“ gibt.

Der Ansatz ist planorientiert und starr, sodass wenig Spielraum für Anpassungen bleibt. Es ist mehr oder weniger das Gegenteil von agil und legt Wert darauf, sich an den Plan zu halten, anstatt sich an neue Umstände anzupassen.

3. Funktionsorientierte Entwicklung (FDD)

Feature-getriebene Entwicklung wird auch als ältere Methode angesehen. Obwohl sie einige agile Prinzipien verwendet, wird sie als der Vorgänger der heutigen agilen und schlanken Methoden angesehen.

Wie der Name schon sagt, konzentriert sich dieser Prozess auf die häufige Implementierung von Funktionen, die vom Kunden geschätzt werden. Es ist ein iterativer Prozess, bei dem alle Augen darauf gerichtet sind, den Endbenutzern greifbare Ergebnisse zu liefern. Der Prozess ist adaptiv und verbessert sich auf der Grundlage neuer Daten und Ergebnisse, die regelmäßig gesammelt werden, um Softwareentwicklern zu helfen, Fehler zu erkennen und darauf zu reagieren.

Diese Art von fokussierter agiler Methodik kann für einige Teams funktionieren, die einen stark strukturierten Ansatz und klare Ergebnisse wünschen und gleichzeitig einen gewissen Spielraum für Iterationen lassen.

4. Methodik der schlanken Softwareentwicklung

Schlanke Softwareentwicklung basiert auf den Prinzipien der schlanken Fertigung. Im Kern zielt Lean Development darauf ab, die Effizienz zu verbessern, indem Verschwendung vermieden wird. Durch die Reduzierung von Aufgaben und Aktivitäten, die keinen echten Mehrwert bieten, können die Teammitglieder mit optimaler Effizienz arbeiten.

Das fünf Lean-Prinzipien Stellen Sie einen Arbeitsablauf bereit, den Teams verwenden, um Verschwendung zu identifizieren und Prozesse zu verfeinern. Lean ist auch ein Leitgedanke, der Menschen helfen kann, effizienter, produktiver und effektiver zu arbeiten.

Die Philosophien und Prinzipien von Lean können auf agile und andere Softwareentwicklungsmethoden angewendet werden. Die Lean-Entwicklung bietet eine klare Anwendung für die Skalierung agiler Praktiken in großen oder wachsenden Organisationen.

5. Methodik der Scrum-Softwareentwicklung

Gedränge ist ein System, das regelmäßig von Softwareentwicklungsteams verwendet wird. Wie viele Softwareentwicklungsmethoden ist Scrum agil und konzentriert sich auf einen wertorientierten Ansatz. Der Scrum-Prozess basiert auf Empirismus, der Theorie, dass Wissen aus praktischer Erfahrung und beobachtbaren Fakten stammt.

Ein Scrum findet über einen voreingestellten Zeitraum statt, der als Sprint bezeichnet wird. Normalerweise liegt der Zeitrahmen zwischen zwei und vier Wochen und das Scrum befindet sich zu Beginn des Sprints. Das Ziel jedes Sprints ist es, eine unvollständige, aber fortschrittliche Version eines Produkts herauszugeben, die den Stakeholdern zur Verfügung gestellt werden kann, sodass Feedback sofort in den nächsten Sprint integriert werden kann.

Das Spezifische Ziele jedes Sprints werden bestimmt durch Produkteigentümer wer ordnet und priorisiert Backlog-Elemente (die Artefakte, die fertiggestellt werden müssen). Der Sprint-Prozess wiederholt sich immer wieder, wobei das Entwicklungsteam auf der Grundlage von Erfolgen, Misserfolgen und dem Feedback der Stakeholder Anpassungen vornimmt und iteriert.

Lernen mehr über Scrum — die komplette Programmplanungslösung für Jira.

6. Extreme Programmierung (XP)

Extremes Programmieren, auch XP genannt, ist eine Methode, die auf der Verbesserung der Softwarequalität und Reaktionsfähigkeit basiert. Es handelt sich um einen agilen Ansatz, der sich auf der Grundlage der Kundenanforderungen weiterentwickelt. Das ultimative Ziel ist die Erzielung qualitativ hochwertiger Ergebnisse. Qualität beschränkt sich nicht nur auf das Endprodukt — sie bezieht sich auf jeden Aspekt der Arbeit und gewährleistet Entwicklern, Programmierern und Managern ein großartiges Arbeitserlebnis.

Die Entscheidungsfindung beim Extremprogrammieren basiert auf fünf Werten: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Die Besonderheiten von XP können nicht für alle Situationen gelten, aber das allgemeine Framework kann unabhängig vom Kontext einen Mehrwert bieten.

7. Schnelle Anwendungsentwicklung (RAD)

Schnelle Anwendungsentwicklung (RAD), manchmal auch Rapid Application Building (RAB) genannt, ist eine agile Methode, die darauf abzielt, qualitativ hochwertige Ergebnisse mit einer kostengünstigen Investition zu erzielen. Der Prozess priorisiert das schnelle Prototyping und häufige Iterationen.

Die schnelle Anwendungsentwicklung beginnt mit der Definition der Projektanforderungen. Von dort aus entwerfen und bauen die Teams unvollkommene Prototypen, um sie den Stakeholdern so schnell wie möglich zur Verfügung zu stellen. Prototyping und Bau wiederholen sich immer wieder in Iterationen, bis ein Produkt vollständig ist und die Kundenanforderungen erfüllt.

Dies ist ideal für kleinere Projekte mit einem klar definierten Ziel. Der Prozess hilft Entwicklern, auf der Grundlage häufiger Rückmeldungen von Interessengruppen schnelle Anpassungen vorzunehmen. Es geht darum, schnelle Prototypen zu erstellen, die den Benutzern so schnell wie möglich konstruktives Feedback geben können. Dieses Feedback fließt in das Benutzerdesign ein, sodass Entwicklungsentscheidungen auf den direkten Gedanken und Bedenken derjenigen basieren, die das Produkt verwenden werden.

8. DevOps-Bereitstellungsmethodik

Das DevOps-Bereitstellungsmethodik ist eine Kombination aus Dev (Softwareentwicklung) und Ops (Information Technology Operations). Zusammen entwickeln sie eine Reihe von Verfahren zur Verbesserung der Kommunikation und Zusammenarbeit zwischen den Abteilungen, die für die Entwicklung eines Produkts verantwortlich sind.

Es handelt sich um eine kontinuierliche Kommunikationsschleife zwischen Produktentwicklern und Betriebsteams (IT-Betrieb). Wie so viele agile Prozesse ist es auf kontinuierliches Feedback angewiesen, um Teams dabei zu helfen, Zeit zu sparen, die Kundenzufriedenheit zu erhöhen, die Markteinführungsgeschwindigkeit zu verbessern und Risiken zu reduzieren.

Die Schritte der DevOps-Bereitstellung wiederholen sich mit dem Ziel, die Kundenzufriedenheit mit neuen Features, Funktionen und Verbesserungen zu erhöhen. Diese Methode weist jedoch einige Nachteile auf. Einige Kunden möchten keine kontinuierlichen Updates für ihre Systeme, sobald sie mit einem Endprodukt zufrieden sind.

Softwareentwicklung leicht gemacht

Die meisten Softwareentwicklungsteams verwenden eine Kombination aus Methoden und Frameworks, die zu ihrer Teamgröße, Teamdynamik und Art der zu erledigenden Arbeit passen. Der Schlüssel liegt darin, eine agile Methode zu verwenden und zusammenzuarbeiten, um Ihre Systeme kontinuierlich zu verbessern, während Sie lernen und wachsen.

Easy Agile hat es sich zur Aufgabe gemacht, Teams dabei zu helfen, besser mit Agile zusammenzuarbeiten. Wir entwerfen agile Apps für Jira mit einfacher, kollaborativer und flexibler Funktionalität. Von der Agilität des Teams mit Einfacher agiler Teamrhythmus, zu skalierter Agilität mit Einfache agile Programme, unsere Apps können Ihren agilen Teams helfen, Ihre Kunden besser zu beliefern.

Buchen Sie eine 1:1 -Demo um mehr über unsere Jira-Toolsuite zu erfahren, oder kontaktiere unser Team wenn Sie weitere Fragen haben. Wir bieten eine kostenlose 30-Tage-Testversion an, damit Sie unsere Produkte ausprobieren können, bevor Sie eine Verpflichtung eingehen.

Ein häufiges Missverständnis bei agilen Softwareentwicklungsmethoden ist, dass sie keinem formalen Prozess folgen. Jedes Team macht einfach sein eigenes Ding mit wenig oder gar keiner Planung, und irgendwie klappt alles. Nun, wir hassen es, Ihre Seifenblase platzen zu lassen, aber Softwareentwicklung funktioniert so nicht, agil oder nicht. 🤯

Genau wie bei traditionellen Wasserfallprojekten folgt agile Projekte einem agilen Softwareentwicklungszyklus (SDLC). Aus der Prozessperspektive besteht der Hauptunterschied in einem linearen Ansatz mit Wasserfall und einem iterativen Ansatz mit Agilität. We are something later into into there.

Lassen Sie uns zunächst erläutern, wie ein agiles SDLC mit agilen Prinzipien im Einklang steht. Dann werden wir sowohl in Scrum- als auch in Kanban-Umgebungen über agile SDLC sprechen.

How the cycle of agile softwaredevelopment agile principles supports

Das Agiles Manifest nennt vier Grundwerte, die zur Verbesserung der Softwareentwicklungsprozesse beitragen. Sie sind:

Individuals and Interactions about Processes and Tools
Funktionende Software über eine umfassende Dokumentation
Zusammenarbeit mit Kunden over Contracts
Reagieren Sie auf Veränderungen anstatt einem Plan zu folgen.

Das sind großartige Werte! Heben Sie jetzt Ihre Hand, wenn Sie sich an den nächsten Satz erinnern. Irgendjemand?? Lass uns dein Gedächtnis auffrischen: „Das heißt, obwohl die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr ein. “

Allzu oft sind neue agile Softwareentwicklungsteams so begeistert davon, „agil zu werden“, dass sie vergessen, den gesamten Inhalt des Agilen Manifests vollständig zu verstehen. Wir verstehen es — es ist schwer, sich an alle 68 Wörter zu erinnern, wenn man begeistert ist. 🤓

Schauen wir uns das noch einmal an: The article on the right page have a value. Das klingt nicht so, als ob Sie alle Dokumentationen, Prozesse und Tools entfernen sollten. Sie benötigen tatsächlich einige dieser Dinge, um effizient als Team zu arbeiten. The least must to take any art of contract, when they want develop software for a external stakeholder and paid.

Wir würden Ihnen gerne genau sagen, wie viele Prozesse und wie viel Dokumentation und Planung Sie benötigen, aber das können wir nicht. Ein Teil der Agilität besteht darin, die Dinge im Laufe der Zeit anhand Ihrer Teamumgebung und der Bedürfnisse der Kunden zu erkennen. If your agile team ready, start you to check the processes, tools and project documentation and that your team needs to efficient and effective to work.

Wir schauen uns nun einige Lebenszyklusmodelle für agile Softwareentwicklung an.

Das Scrum SDLC model

Erinnerst du dich, dass wir bereits darüber gesprochen haben, dass Wasserfall linear und agil iterativ ist? Scrum ist das perfekte agile Framework, um den Unterschied hervorzuheben.

The traditional water fall model of the product development requires several steps before you going to a final product. Waterfall projects meet the definition of ready, when the complete project is completed and in the hands of users or stakeholders. Es ist linear — ein gerader Weg von Anfang bis Ende.

The agile method of Scrum is dagegen iterativ and adaptiv. Scrum-Teams teilen die Ergebnisse in kleineren Teilen mit kürzeren Zeitrahmen, die als Sprints bezeichnet werden. Es ist das Ziel, bei jeder Iteration während des gesamten Produktentwicklungsprozesses Teile der funktionierenden Software bereitzustellen.

Anstatt eines einzelnen Sprints, wie oben gezeigt, sieht ein vollständiger Scrum-Lebenszyklus eher so aus:

Für jede Iteration plant, entwickelt, überprüft und implementiert das Team Updates der Produktfunktionen. If the involved agreement tests and you see the functional product, they may questions by new priority or requirements. This feedback is added the product backlog, sodass the Product Owner with other functions and work priorisiert wird. Dann beginnt der Prozess erneut.

Da sich die Software ständig weiterentwickelt, wiederholt sich dieser Prozess, bis das Produkt entweder einen Wartungsgrad erreicht hat oder das Ende seiner Nutzungsdauer erreicht und außer Betrieb genommen wird.

Inparticular in Scrum is planning a great part of the SDLC. The Sprint Planning bringt das Team zusammen, um die Arbeit auf der Grundlage der vom Product Owner definierten Sprintziele zu priorisieren. The daily standup provides the team the possible to coordinating his activities for the day. The Sprint-Review ermöglicht es dem Product Owner und anderen Stakeholdern, die während des Sprints Ergebnisse zu überprüfen und zu besprechen. Und schließlich bietet die Sprint-Retrospektive dem Team die Gelegenheit, über den Prozess, die Teamdynamik und mögliche Verbesserungen für die Zukunft nachzudenken.

Reibungslose Sprint-Planung mit

Einfache Agile User Story Maps

Testing now

Verfeinerung des Backlogs is also a art of planning, that should be completed before a sprint planning ession or on end of a sprint. When the verfeinerung can be review the teams the ability specific functions or Ideas for development methods to meet the Acceptance criteria. Sie können auch die Verfügbarkeit von Ressourcen bei der Planung berücksichtigen. Sie könnten beispielsweise erwägen, zusätzliche Komponententests erstellen, um den Aufwand eines Testers zu reduzieren, der während der nächsten Sprints im Urlaub sein wird.

The difference between the planning in Scrum and Waterfall is darin, how much work you want planning. Wasserfallpflanze zu Beginn des gesamten Projekts. The Scrum planning does during the complete product development, from beginning to the end.

Die agile Kanban-Methode

Ein Kanban-Framework hat einen etwas anderen agilen Prozess. Workelemente sind nicht unbedingt miteinander verwandt oder voneinander abhängig. Einzelne Teammitglieder können asynchron arbeiten, um neuen Code in die Produktion einzubringen, sobald er fertig ist. Kanban ist jedoch immer noch iterativ, da die Arbeitselemente in einem Backlog priorisiert werden, und dann werden sie entwickelt, überprüft und zur Produktion gebracht.

Basierend auf dem Feedback der Endbenutzer werden dem Board neue Backlog-Elemente hinzugefügt. The priority of work elements is regular checked and adjusted that they is perfect to the agile value, to react on veränderungen.

Ein großer Unterschied mit Kanban Bedeutet, dass jede Spalte im Kanban-Board nur eine begrenzte Anzahl von Arbeitselementen enthalten kann (WIP-Grenzwerte), anstatt sie auf der Grundlage von Storypoints und Teamgeschwindigkeit zur Arbeit zu verpflichten. This helps Teams, konzentriert zu bleiben, in ihrem Prozess zu erkennen, zu erfahren, wo Automation hilfreich sein könnte, und allgemein zu verstehen, wo ihr Prozess funktioniert und wo er wenig Hilfe benötigt.

Bei Kanban liegt der Fokus mehr auf dem kontinuierlichen Arbeitsfluss in jeder Phase. The WIP border values helps teams to identify specific phases, they behind the work process, that they detect the cause, they detect and last the efficiency work.

Jedes Kanban-Team kann die Spalten auf seinem Board nach seinen Bedürfnissen auswählen. Das Ziel von Kanban ist es, die Geschwindigkeit zu verbessern, indem die Arbeit auf dem Board voranschreitet. A precise monitoring and measurement of movement of work elements is for kanban teams of significant meaning.

Working with the agile software development cycle

Egal, ob Sie in einem ausgerüsteten Unternehmen oder einem Startup-Team arbeiten, eine angemessene Menge an Dokumentation, Tools und Prozessen in agilen Softwareentwicklungsmethoden ist von Wert. Actual helps the facility a agile software development cycle your team, efficient to work.

TIPP! Auf der Suche nach mehr Teamzusammenstellung? Probiere es aus Einfaches agiles Programm

Think you, on the Agile Manifest and The back access Die 12 Prinzipien hinter dem Agilen Manifest wenn du nicht weiterkommst. This values and principles applies not only for the what you build, but also for the work type your team. The key concept behind agile Frameworks contains in, they to check and adapt — both the software as also also the art and way how you work as team.

Use so much process and documentation, how you need, but not more. Schauen Sie sich an, was Sie heute haben, und identifizieren Sie wichtige Punkte, ohne dass das Team Ihrer Meinung nach nicht funktionieren kann. Fügen Sie dann Schritte hinzu oder entfernen Sie sie, wenn Sie herausfinden, wie Ihr Team am besten in einem agilen Framework arbeiten kann.

Bei Easy Agile are here, to help them, the best from your agile Practices, and help them to help them to develop a powerful, agile team. 💪 If you want more learn, look you see our weitere Blogartikel zu agilen Themen.

If you help with the Jira tool by Atlassian, we have einige tolle Apps damit du es versuchst. Unser Simple Agile Programs for the Jira App can support your planning activities by skalable direction and visualization of dependencies.

Testing now

Oder warum Sie Beispielvariablen aussagekräftige Namen geben sollten

Frustriert beugte ich mich über meinen Schreibtisch und unterdrückte den Drang zu schreien, um das rhythmische Klackern meiner Kollegen nicht zu stören. Ich war den ganzen Morgen über ein besonders fieses Problem beim unendlichen erneuten Rendern von React frustriert, das ich einfach nicht zum Laufen bringen konnte. Der Drang zu schreien kam, als ich mich, mein eigener Werkzeugkasten erschöpft, an Google wandte.

Sie sehen, es sah so aus, als wäre jemand anderes auf dasselbe Problem gestoßen und hätte beschlossen, eine Lösung für Wohlstand (und Internetpoints) aufzuzeichnen. Ich suchte eifrig auf der Seite nach dem Beispielcode, der mir den Morgen retten würde. Als ich ihn fand, wurde mein Blick auf den gefürchteten FooBarbaz gelenkt und ich wusste, dass mein Morgen noch viel schlimmer werden würde, bevor er besser wurde.

Ich liebe die Geschichte des Programmierens und die kleinen Ostereier, die andere Entwickler weitergegeben haben (mein persönlicher Favorit - Ich bin eine Teekanne). Diese tragen dazu bei, dass diese Arbeit mit Computern viel unterhaltsamer und menschlicher ist. Ich verstehe, dass die Verwendung von FooBarbaz bei der Benennung von Beispielfunktionen und Variablen eine lange und geschichtsträchtige Tradition hat, die mindestens bis in die Tech Model Railroad Club am MIT, um 1960. Ich erkenne an, dass die Verwendung von FooBarbaz in erster Linie nicht dazu dient, von dem, was gezeigt wird, ablenken zu lassen. Ich denke auch, dass wir so gut wie aufhören sollten, sie zu benutzen.

Ich bin immer wieder beeindruckt von der Menge an Informationen, die meine Entwicklerkollegen im Internet für mich weggelassen haben. So viele Menschen in diesem Bereich scheinen ein angeborenes Bedürfnis zu haben, anderen zu helfen, was dazu führt, dass sie unzählige Stunden investieren, um Stack Overflow und Blogs mit nützlichen Informationen zu füllen. Ich kann mir nur vorstellen, dass die Leute, die ihre Zeit und Mühe in dieses Ziel investieren, hoffen, dass ihre Bemühungen so vielen Menschen wie möglich helfen werden. fooBarbaz steht dem im Weg.

Lassen Sie mich für eine Sekunde meinen Entwicklerhut abnehmen und meinen kürzlich weggeworfenen, leicht unförmigen und angeschlagenen Psychologen-Hut aufsetzen. Das Verweben komplexer Fakten zu Geschichten ist eine bewährte Technik, die das Lernen erleichtert. Hier in Australien wurde die Technik wird seit Zehntausenden von Jahren von den Aborigines und den Torres Strait Islandern genutzt um ihnen zu helfen, sich wichtige und komplexe Informationen wie die Standorte von Wasserlöchern in weiten Teilen der unwirtlichen Wüste zu merken. Unser Gehirn besteht aus Netzwerken miteinander verbundener Neuronen. Es ist also wahrscheinlicher, dass wir an dem Gelernten festhalten, wenn wir in der Lage sind, neue Informationen in unsere aktuelle Wissensbasis zu integrieren. Der moderne Begriff dafür lautet assoziatives Lernen.

Darüber hinaus war es, wie Sie sich sicher aus der Schule erinnern werden, das Lernen interessant zu halten gezeigt ein starker Motivator zu sein, der das Lernen anregt.

Wenn wir uns all diese Zeit und Mühe nehmen, um mit unseren Entwicklerkollegen zu kommunizieren, können und sollten wir den Vorteil des assoziativen Lernens und der intrinsischen Motivation nutzen, um sicherzustellen, dass die Informationen, die wir veröffentlichen, für so viele Menschen wie möglich nützlich wie möglich sind. Deshalb glaube ich, dass wir bei der Erstellung von Beispielcode genauso viel über sinnvolle Benennungen nachdenken sollten wie in unseren eigenen Codebasen.

Marijn Haverbekes Beredtes Javascript steht regelmäßig an der Spitze Listen von Büchern, die Sie lesen sollten, wenn Sie Javascript lernen (JS). Es ist kein Zufall, dass er auch ein Meister darin ist, aussagekräftige Namen zu verwenden, um Menschen zu helfen, die Prinzipien der Codierung besser zu verstehen. Wenn er neuen Programmierern den Vergleich von Zeichenketten in JS beibringt, verwendet er das folgende Beispiel:

Marijn nutzt unser vorhandenes Wissen über Springfields Lieblings-Zeichentrickfiguren, um diesem Beispiel zusätzliche Bedeutung und Interesse zu verleihen. Wir wissen, dass Itchy und Scratchy jeweils eine Maus und eine Katze sind und daher definitiv nicht dasselbe sind.

Betrachten Sie dasselbe Beispiel, aber stattdessen mit dem gefürchteten Foo/Bar gerendert:

Für erfahrene Entwickler ist das vielleicht leicht zu analysieren: Sie haben Hunderte von Beispielen wie diesem gelesen und so den Zusammenhang zwischen Foo und Bar gelernt und verinnerlicht. Dies stellt jedoch eine Lernbarriere für neue Entwickler dar, die diese Regel noch nicht verinnerlicht haben, und erhöht stattdessen die mentale Belastung für sie, das Konzept zu verstehen. Es fehlt auch daran, den kleinen Funken von Interesse oder Freude zu erzeugen, um das Interesse der Leser zu wecken und so ihre Motivation zu steigern, das zugrundeliegende Konzept zu verstehen.

Ich sage nicht, dass FooBarbaz absolut keinen Platz hat (obwohl ich denke, dass ihr Nutzen begrenzt ist). Der beste Weg, diese Begriffe zu verwenden, besteht darin, zu betonen, dass alles an einem bestimmten Ort platziert werden kann. Ein Beispiel dafür ist, wenn wir über Argumente und Parameter in JS-Funktionen sprechen. Sie sehen, in Vanilla JS gibt es keine Typüberprüfung. Wenn wir also eine Funktion wie die folgende haben, die einen Parameter akzeptiert und seinen Wert einfach in der Konsole protokolliert, spielt es keine Rolle, welche Art von Argument wir übergeben:

Ich glaube, dass diese Begriffe in diesem Fall am nützlichsten sind, da sie betonen sollen, dass ihr Typ keine Rolle spielt. Ich möchte auch den Vorbehalt hinzufügen, dass die Verwendung dieser Begriffe auf diese Weise nur geeignet ist, wenn Sie Inhalte für erfahrene Entwickler produzieren, die sich ein funktionierendes Verständnis dieser Begriffe erarbeitet haben.

Auch wenn sich das an erfahrene Entwickler richtet, glaube ich immer noch, dass aussagekräftigere Namen in diesem Beispiel besser wären:

Ein anderes Beispiel, bei dem aussagekräftigere Variablennamen nützlich wären, bezieht sich auf metasyntaktische Variablen. Diese Variablen sind häufig im Quellcode zu finden und sollen vor der realen Verwendung geändert oder ersetzt werden. Diese Variablen sind zwar nur Platzhalter, aber ich glaube, dass es auch besser ist, einen Variablennamen zu verwenden, der Ihrem Entwicklerkollegen mehr Kontext bietet, um ihn beim Lesen und Implementieren des Codes in Zukunft zu unterstützen.

Wir arbeiten in einem wunderbaren Beruf mit einer reichen Geschichte, in dem viele Menschen bereit sind, ihre Zeit zu investieren, um ihre Programmiererkollegen auszubilden und zu betreuen. Die Verwendung aussagekräftiger Variablennamen anstelle von fooBarbaz ist eine Möglichkeit, sicherzustellen, dass sich dieser Aufwand lohnt und so vielen Menschen wie möglich hilft. Es senkt die Zugangsbarrieren für den Beruf und trägt zur Schaffung eines vielfältiger und eine freundliche Programmiergemeinschaft.

Also lass den FooBarbaz fallen (aber nicht den Teekanne) und geh raus und entfacht Freude!