So erstellen Sie Observability für Forge-Anwendungen

Observability ist ein entscheidender Aspekt bei der Entwicklung und Wartung zuverlässiger Anwendungen, und bei Easy Agile haben wir große Anstrengungen unternommen, um unsere Anwendungen so beobachtbar wie möglich zu machen. In einem kürzlichen Vortrag auf dem Atlas Camp 2025 berichtete Ryan Brown, unser Staff Engineer, über unsere Erfahrungen bei der Umstellung auf Forge und die dabei gewonnenen Erkenntnisse. Hier sind die wichtigsten Höhepunkte seines Vortrags.
Was ist Beobachtbarkeit und warum ist sie wichtig
Bei Observability geht es darum, genügend Daten zu sammeln und zu visualisieren, um den Zustand Ihrer Softwaresysteme zu verstehen und Probleme zu beheben, wenn sie auftreten. Im Gegensatz zur herkömmlichen Überwachung, bei der Sie erfahren, was wann passiert ist, geht Observability noch einen Schritt weiter und erklärt, warum und wie Probleme auftreten.
Für uns bei Easy Agile bedeutet starke Beobachtbarkeit:
- Hat uns geholfen, bessere Entscheidungen über Leistungs- und Infrastrukturanforderungen zu treffen
- Wir haben unseren Kundensupport drastisch verbessert, indem wir Probleme schnell lokalisieren konnten
- Passen wir uns an die Realität moderner, verteilter Anwendungen an
Ryan drückte es in seinem Vortrag so aus: „Als ich damals an Anwendungen gearbeitet habe, liefen wir auf zwei, drei, vielleicht höchstens vier Rechenzentren. Jetzt sprechen wir über Anwendungen, die auf globaler Ebene wachsen und von Menschen auf der ganzen Welt genutzt werden.“
Moderne Anwendungen sind weitaus verteilter als früher, und dicke Frontends werden so komplex wie Backends. Aufgrund dieser Verteilung ist der herkömmliche Ansatz, einige Server manuell zu überprüfen, unzureichend — wir benötigen ausgeklügelte Observability-Lösungen, um zu verstehen, was auf unseren Systemen vor sich geht.
Die drei Säulen der Beobachtbarkeit
Observability basiert auf drei Hauptpfeilern:
Metriken
Dies sind die zahlenbasierten Messungen Ihrer Software — CPU-Auslastung, Anforderungszeiten, Fehleranzahl usw. Aber rohe Zahlen allein sind nicht sehr hilfreich. Der Kontext ist entscheidend — zu wissen, dass Sie fünf Fehler haben, ist etwas ganz anderes als zu wissen, dass Sie innerhalb von zwei Minuten fünf Fehler von einem bestimmten Benutzer auf einem Server haben.
Metriken sind besonders aussagekräftig, wenn es darum geht, Trends im Laufe der Zeit zu identifizieren, sodass Sie genau feststellen können, wann Leistungsprobleme auftraten, oder Änderungen mit dem Systemverhalten korrelieren können.
Logs
Logs sind oft das Erste, womit Ingenieure Erfahrung sammeln, wenn es um Observability geht. Sie bieten detaillierte Aufzeichnungen von Ereignissen und sind der Eckpfeiler, um zu verstehen, was in Ihrem System vor sich geht. Sie liefern mehr Informationen als nur Metriken und erfassen nicht nur, was passiert ist, sondern auch Details zu jedem Ereignis, das eingetreten ist.
Sie sind reicher an Informationen, generieren aber auch mehr Daten. Logs könnten Ihnen beispielsweise sagen, dass ein Fehler aufgetreten ist, weil eine API eine schlechte Antwort zurückgegeben hat — aber das allein sagt Ihnen immer noch nicht, warum die Downstream-API ausgefallen ist.
Spuren
Mithilfe von Traces können Sie nachvollziehen, was auf all Ihren Systemen passiert, die zusammenarbeiten. Sie verfolgen Transaktionen, während sie verschiedene Dienste durchlaufen, und zeigen Ihnen genau, was passiert, wenn ein Benutzer auf eine Schaltfläche klickt oder eine Aktion ausführt.
„Die Rückverfolgung ist überraschend einfach“, erklärte Ryan. „Sie haben lediglich eine eindeutige Kennung für eine Transaktion, die von einem System zum nächsten System gemeinsam genutzt wird.“
Traces sind besonders nützlich, wenn Sie diese Kennung Endbenutzern zur Verfügung stellen können, wenn etwas schief geht. Diese ID kann Ihnen genau zeigen, was bei dieser Transaktion passiert ist, sodass das Rätselraten bei der Fehlerbehebung ein Kinderspiel ist.
Beobachtbarkeit bei Connect und Forge
Unser aktueller Connect-Ansatz
Bei Easy Agile haben wir umfassende Observability für unsere Connect-Apps implementiert.
- Für alle unsere Anwendungen erfasste Metriken, Logs und Traces
- All diese Daten werden an einen Observability-Dienst eines Drittanbieters gesendet, um eine zentrale Ansicht zu erhalten
- Frontend-Komponenten, die auch Observability-Daten an denselben Dienst senden
Dieser Ansatz reduziert die kognitive Belastung unserer Techniker und bietet einen vollständigen Überblick über die Benutzerabläufe und das, was in unseren Systemen passiert. Dafür empfiehlt Ryan, kommerzielle Dienste wie Datadog oder New Relic oder sogar Open-Source-Optionen wie Signoz zu verwenden.
Bedenken hinsichtlich des Übergangs für Forge
Als wir uns Forge zum ersten Mal ansahen, hatten wir mehrere Fragen:
- Wie gut würde Tracing mit dem Kommunikationsmodell von Forge funktionieren?
- Könnten wir unsere eigenen benutzerdefinierten Metriken definieren?
- Wären wir in der Lage, Metriken und Logs sowohl vom Frontend als auch vom Backend zu sammeln?
- Könnten wir bestimmte Benutzertransaktionen zu Supportzwecken identifizieren?
Zum Zeitpunkt unserer Evaluierung waren Forge-Funktionen die primäre verfügbare Rechenoption, was Fragen zur Funktionsweise von Standard-Tracing-Bibliotheken im einzigartigen Kommunikationsmodell von Forge aufwarf.
Experimentieren mit einer einfachen App
Anstatt zu versuchen, eines unserer größeren Produkte zu migrieren, haben wir eine einfache „Sprint Notes“ -App erstellt, um die Beobachtbarkeit auf Forge zu testen. Dadurch konnten wir:
- Iterieren Sie schnell durch verschiedene Forge-Topologien
- Konzentrieren Sie sich beim Experiment auf die Beobachtbarkeit
- Beinhaltet alle notwendigen Komponenten (UI, API, Datenbank)
Wir haben diese App durch mehrere Phasen geführt:
- Verbinde dich auf Forge: Unsere Connect-App über Forge ausführen
- Forge mit Fernbedienungen: Verwenden Sie zwei Ansätze: Aufrufen von Fernbedienungen über Forge-Funktionen und Aufrufen von Fernbedienungen direkt von der Benutzeroberfläche aus
- Forge Native: Die App komplett neu schreiben, um die Forge-Funktionen und den Entitätsspeicher zu verwenden
Wichtigste Ergebnisse
Auf Forge verbinden
Wenn Sie unsere Connect-App über Forge ausführen:
- Unsere gesamte bestehende Beobachtbarkeit funktionierte ohne Änderungen
- Frontend- und Backend-Metriken funktionierten weiterhin wie zuvor
- Die Ablaufverfolgungskennungen wurden korrekt weitergegeben
- Logs und Metriken wurden nicht in der Atlassian Developer Console angezeigt (was sinnvoll ist, da wir keine Forge-Module verwendet haben)
Die Observability-Story für Connect on Forge ist ziemlich einfach — sie funktioniert einfach. Ryan merkte an: „Die gesamte Observability, die wir auf Connect eingerichtet hatten, funktionierte genauso wie zuvor. Es gab keine großen Änderungen oder Probleme mit dem, was wir dort gesehen haben.“
Wir haben sogar mit verschiedenen Methoden experimentiert, um Daten an unseren Observability-Dienst zu senden, einschließlich der Verwendung eines Proxys unter unserer eigenen Domain, und alles funktionierte konsistent, solange die richtigen Content-Security-Header gesetzt waren.
Forge mit Fernbedienungen
Für Forge mit Fernbedienungen haben wir Folgendes gefunden:
- Frontend- und Backend-Observability funktionierten größtenteils
- Wir mussten permissions.external.fetch.client so einstellen, dass Metriken vom Frontend aus gesendet werden können
- Das Hinzufügen dieser Berechtigungen erforderte ein Upgrade der Hauptversion
- Metriken erfassten nicht alle API-Aufrufe, insbesondere Frontend-Aufrufe an Atlas-APIs
- Tracing-Identifikatoren waren Remote-Anrufern nicht zugänglich, wodurch die durchgängige Verfolgung eingeschränkt wurde
„Das ist ein bisschen enttäuschend... wir haben festgestellt, dass Forge bei Anrufen an unsere Fernbedienungen Tracing-Identifikatoren für die Verwendung im Backend generierte, aber leider waren diese Identifikatoren dann nicht dem ausgesetzt, was diese Fernanrufe tätigte“, erklärte Ryan.
Wir konnten zwar Protokolle in der Developer Console sehen und einige Metriken wurden erfasst, aber die Unfähigkeit, Tracing-Identifikatoren an Aufrufer weiterzuleiten, bedeutete, dass wir keine vollständige Rückverfolgbarkeit von der Benutzeroberfläche zur Datenbank erreichen oder Transaktions-IDs den Endbenutzern anzeigen konnten, ohne Problemumgehungen zu implementieren.
Forge-Einheimischer
Mit einem vollständig nativen Forge-Ansatz:
- Benutzerdefinierte Metriken und einfaches Tracing sind möglich, erfordern jedoch einen erheblichen Aufwand.
- Wir mussten eine benutzerdefinierte Handhabung mit Bibliotheken wie OpenTelemetry implementieren
- Die Beobachtbarkeit der Benutzeroberfläche blieb ähnlich wie bei der Remote-Implementierung.
- Wir könnten über undokumentierte Forge-API-Funktionen auf Korrelations-IDs zugreifen
Wir haben es geschafft, einen Machbarkeitsnachweis zu erstellen, der Spuren von Forge-Funktionen zu unserem Observability-Dienst zeigt, obwohl die Implementierung einer vollständigen Datenspeicherverfolgung zusätzliche Arbeit erfordern würde.
Empfehlungen und bewährte Verfahren
Basierend auf unseren Ergebnissen empfehlen wir:
1. Legen Sie Basiswerte für die Beobachtbarkeit fest
Finden Sie heraus, welche Daten Sie wirklich benötigen, anstatt alles zu sammeln. Observability-Dienste werden nach Volumen abgerechnet, sodass das Sammeln unnötiger Daten schnell teuer werden kann.
2. Verwenden Sie OpenTelemetry
Es entspricht der internen Implementierung von Forge und bietet eine gute Standardisierung. Es ist zwar schwieriger zu verwenden als einige sofort einsatzbereite Lösungen, aber die langfristigen Vorteile sind es wert.
3. Ziehen Sie einen Observability-Proxy in Betracht
Dies ermöglicht:
- Authentifizierung für eingehende Metriken
- Zusätzlichen Kontext hinzufügen
- Datenredigierung für sensible Informationen
- Entkopplung Ihrer Implementierung von bestimmten Anbietern
In Kombination mit OpenTelemetry bedeutet dieser Ansatz, dass Ihre Forge-Komponenten nicht wissen müssen, welchen Observability-Dienst Sie verwenden, wodurch Berechtigungsänderungen vermieden werden, wenn Sie den Anbieter wechseln.
4. Plane Genehmigungsaktualisierungen strategisch
Da sie wichtige Versionsupgrades erfordern, sollten Sie sie frühzeitig in Ihre Entwicklung einbeziehen.
5. Weitere wichtige Überlegungen
- Größere Versionsupgrades sind erforderlich, wenn Berechtigungen für Observability hinzugefügt werden
- Die Dokumentation für den Export von Logs und Metriken ist technisch korrekt, kann aber leicht falsch interpretiert werden
- Traces werden in Remote-Implementierungen nicht automatisch an Aufrufer weitergegeben
Abschließende Gedanken
Das Erreichen aller drei Säulen der Beobachtbarkeit auf Forge ist möglich, erfordert jedoch je nach Ihrer Implementierungsstrategie unterschiedliche Ansätze:
- Connect on Forge funktioniert nahtlos mit vorhandener Observability
- Forge mit Fernbedienungen erfordert eine zusätzliche Konfiguration
- Forge Native benötigt mehr benutzerdefinierte Implementierung
Diese Experimente werden für Open Source vorbereitet, also bleiben Sie dran Ryans LinkedIn für Updates.
Related Articles
- Workflow
8 Software Development Methodologies Explained
Software development teams are known for using a wide variety of agile methodologies, approaches, and tools to bring value to customers. Depending on the needs of the team and the product's stakeholders, it’s common for teams to deploy and utilize a combination of software development methodologies.
Most dev teams combine methodologies and frameworks to build their own unique approach to product development. You’ll find there are plenty of overlapping principles from one methodology to the next. The key is choosing a system and working as a team to fine-tune and improve that approach so you can continue to reduce waste, maximize efficiency, and master collaboration.
In this post, we’ll outline and compare the following eight software development processes:
1. Agile software development methodology
2. Waterfall methodology
3. Feature driven development (FDD)
4. Lean software development methodology
5. Scrum software development methodology
6. Extreme programming (XP)
7. Rapid application development (RAD)
8. DevOps deployment methodology
1. Agile software development methodology
Agile is the most common term used to describe development methods. It’s often used as an umbrella term to label any methodology that’s agile in nature, meaning an iterative process that reduces waste and maximizes efficiency.
Most software development methodologies are agile with a strong emphasis on iteration, collaboration, and efficiency, as opposed to traditional project management. It’s like comparing jazz to classical music. 🎷
Traditional, linear management methods, such as the waterfall method we’ll cover below, are like classical music, led by one conductor who has a set plan for how the music should be played. The agile process, on the other hand, is more like jazz, which comes together through collaboration, experimentation, and iteration between band members. It’s adaptive and evolves with new ideas, situations, and directions.
2. The waterfall methodology
The waterfall approach is a traditional methodology that’s not very common in software development anymore. For many years, the waterfall model was the leading methodology, but its rigid approach couldn’t meet the dynamic needs of software development.
It’s more common to see the waterfall method used for project management rather than product development. At the beginning of a project, project managers gather all of the necessary information and use it to make an informed plan of action up front. Usually, this plan is a linear, step-by-step process with one task feeding into the next, giving it the “waterfall” name.
The approach is plan-driven and rigid, leaving little room for adjustments. It’s more or less the opposite of agile, prioritizing sticking to the plan rather than adapting to new circumstances.
3. Feature driven development (FDD)
Feature driven development is also considered an older methodology. Although it uses some agile principles, it’s viewed as the predecessor of today’s agile and lean methodologies.
As the name says, this process focuses on frequently implementing client-valued features. It’s an iterative process with all eyes on delivering tangible results to end users. The process is adaptive, improving based on new data and results that are collected regularly to help software developers identify and react to errors.
This kind of focused agile methodology can work for some teams that want a highly structured approach and clear deliverables while still leaving some freedom for iteration.
4. Lean software development methodology
Lean software development comes from the principles of lean manufacturing. At its core, lean development strives to improve efficiency by eliminating waste. By reducing tasks and activities that don’t add real value, team members can work at optimal efficiency.
The five lean principles provide a workflow that teams use to identify waste and refine processes. Lean is also a guiding mindset that can help people work more efficiently, productively, and effectively.
The philosophies and principles of lean can be applied to agile and other software development methodologies. Lean development provides a clear application for scaling agile practices across large or growing organizations.
5. Scrum software development methodology
Scrum is a system regularly used by software development teams. Like many software development methodologies, Scrum is agile, focusing on a value-driven approach. The Scrum process is based on empiricism, which is the theory that knowledge comes from hands-on experience and observable facts.
One Scrum takes place over a preset amount of time called a sprint. Usually, the time frame is between two to four weeks and the Scrum is at the beginning of the sprint. The goal of each sprint is to yield an imperfect but progressing version of a product to bring to stakeholders so that feedback can be integrated right away into the next sprint.
The specific goals of each sprint are determined by a product owner who orders and prioritizes backlog items (the artifacts that need completion). The sprint process repeats over and over again with the development team adjusting and iterating based on successes, failures, and stakeholder feedback.
Learn more about Scrum — the complete program planning solution for Jira.
6. Extreme programming (XP)
Extreme programming, also called XP, is a methodology based on improving software quality and responsiveness. It’s an agile approach that evolves based on customer requirements; the ultimate goal is producing high-quality results. Quality isn’t just limited to the final product — it applies to every aspect of the work, ensuring a great work experience for developers, programmers, and managers.
Decision-making in extreme programming is based on five values: communication, simplicity, feedback, courage, and respect. The specifics of XP can’t apply to all situations, but the general framework can provide value no matter the context.
7. Rapid application development (RAD)
Rapid application development (RAD), sometimes called rapid application building (RAB), is an agile methodology that aims to produce quality results at a low-cost investment. The process prioritizes rapid prototyping and frequent iteration.
Rapid application development begins with defining the project requirements. From there, teams design and build imperfect prototypes to bring to stakeholders as soon as possible. Prototyping and building repeat over and over through iterations until a product is complete and meets customer requirements.
This is ideal for smaller projects with a well-defined objective. The process helps developers make quick adjustments based on frequent feedback from stakeholders. It’s all about creating quick prototypes that can get in front of users for constructive feedback as soon as possible. This feedback is pulled into the user design so that development decisions are based on the direct thoughts and concerns of those who will use the product.
8. DevOps deployment methodology
The DevOps deployment methodology is a combination of Dev (software development) and Ops (information technology operations). Together, they create a set of practices designed to improve communication and collaboration between the departments responsible for developing a product.
It's an ongoing loop of communication between product developers and Ops teams (IT operations.) Like so many agile processes, it relies on continuous feedback to help teams save time, increase customer satisfaction, improve launch speed, and reduce risks.
The steps of DevOps deployment repeat, aiming to increase customer satisfaction with new features, functionality, and improvements. However, this methodology has some drawbacks. Some customers don’t want continuous updates to their systems once they are satisfied with an end product.
Software development made easy
Most software development teams use a combination of methodologies and frameworks to fit their team size, team dynamics, and the type of work being completed. The key is to use an agile methodology and work together to continually improve your systems as you learn and grow.
Easy Agile is dedicated to helping teams work better together with agile. We design agile apps for Jira with simple, collaborative, and flexible functionality. From team agility with Easy Agile TeamRhythm, to scaled agility with Easy Agile Programs, our apps can help your agile teams deliver better for your customers.
Book a 1:1 demo to learn more about our suite of Jira tools, or contact our team if you have additional questions. We offer a free, 30-day trial, so you can try out our products before making a commitment.
- Workflow
Your Guide To Agile Software Development Life Cycles
A common misunderstanding with agile software development methodologies is that they don't follow a formal process. Each team just does their own thing with little or no planning, and somehow it all works out. Well, we hate to burst your bubble, but software development doesn't work like that, agile or not. 🤯
Just like with traditional waterfall projects, agile projects follow an agile software development life cycle (SDLC). From a process perspective, the primary difference is a linear approach with waterfall and an iterative approach with agile. We'll get into this a little more later.
First, let's walk through how an agile SDLC aligns with agile principles. Then we’ll talk about the agile SDLC in both Scrum and Kanban environments.
How the agile software development life cycle supports agile principles
The Agile Manifesto states four basic values that drive improvement in software development processes. They are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.Those are great values! Now raise your hand if you remember the next sentence. Anyone?? Let us refresh your memory: "That is, while there is value in the items on the right, we value the items on the left more."
Too often, new agile software development teams are so excited to start "doing agile" they forget to fully comprehend the entire contents of the Agile Manifesto. We get it — it's hard to remember all 68 words when you're excited. 🤓
So let's take a look at that again: The items on the right have value. That doesn't sound like you should eliminate all documentation, processes, and tools. You actually need some of those things to function efficiently as a team. At the very least, you’ll need to negotiate some type of contract if you're building software for an external stakeholder and you want to get paid.
We'd love to be able to tell you exactly how many processes and how much documentation and planning you'll need, but we can't. Part of being agile is figuring things out as you go along based on your team environment and customer needs. As your agile team matures, you'll begin to inspect and adapt the processes, tools, and project documentation your team needs to work efficiently and effectively.
Now let’s look at a couple of agile software development life cycle models.
The Scrum SDLC model
Remember earlier we talked about waterfall being linear and agile being iterative? Scrum is the perfect agile framework to highlight the difference.
The traditional waterfall model of product development requires several steps before you arrive at a final product. Waterfall projects meet the Definition of Done only after the entire project is complete and in the hands of the user or stakeholder. It's linear — a straight path from start to finish.
The agile method of Scrum, on the other hand, is iterative and adaptive. Scrum teams break the deliverables into smaller pieces with shorter time frames called sprints. The intent is to deliver slices of working software with each iteration throughout the entire product development process.
Rather than a single sprint, as shown above, a full Scrum life cycle looks more like this:
For each iteration, the team plans, develops, reviews, and deploys updates to the product functionality. As stakeholders perform acceptance testing and see the working product, they may ask for new priorities or requirements. That feedback is added to the product backlog to be prioritized with other features and work by the product owner. Then, the process starts again.
Since software is always evolving, this process repeats until the product has either matured to a maintenance level or has reached the end of its useful life and is retired.
Particularly for Scrum, planning is a huge part of the SDLC. Sprint planning brings the team together to prioritize work based on the sprint goal defined by the Product Owner. The daily standup gives the team a chance to coordinate their activities for the day. The sprint review allows the Product Owner and other stakeholders to inspect and discuss deliverables produced during the sprint. And, finally, the sprint retrospective creates the opportunity for the team to reflect on the process, team dynamics, and potential improvements for future.
Smoother Sprint Planning with
Easy Agile User Story Maps
Backlog refinement is also a type of planning recommended to be completed prior to a sprint planning session or at the end of a sprint. During refinement, teams can discuss the feasibility of specific functionalities or ideas for development methods to meet the acceptance criteria. They can also plan around resource availability. For example, they might consider creating extra unit tests to reduce the efforts of a tester who will be on vacation part of the next sprint.
The difference between planning in Scrum and waterfall is how much work you plan and when. Waterfall plans the entire project at the beginning. Scrum planning happens all through the development of the product, from the beginning to the end.
The Kanban agile methodology
A Kanban framework has a little different agile process. Work items aren't necessarily related to or dependent on each other. Individual team members can work asynchronously to push new code to production as soon as it's ready. Yet, Kanban is still iterative in that work items are prioritized in a backlog, and then they are developed, reviewed, and pushed to production.
New backlog items are added to the board based on the end-user feedback. The prioritization of work items is regularly reviewed and adjusted, aligning perfectly with the agile value of responding to change.
A big difference with Kanban is that instead of committing to work based on story points and team velocity, each column in the Kanban board can only hold a limited number of work items (WIP limits). This helps teams stay focused, identify bottlenecks in their process, learn where automation might be helpful, and generally understand where their process is working and where it needs a little help.
With Kanban, there is more focus on the continuous flow of work through each stage. The WIP limits help teams identify specific stages that are impeding the workflow so they can figure out the cause, fix it, and ultimately become more efficient. .
Each Kanban team can choose the columns on their board to suit their needs. The goal of Kanban is to improve the speed of work progressing through the board. Close monitoring and measuring work item movement is critical to Kanban teams.
Working with the agile software development life cycle
Whether you're working in a mature company or a startup team, there's value in an appropriate amount of documentation, tools, and process in agile software development methods. In fact, establishing an agile software development life cycle will help your team operate efficiently.
TIP! Looking for more team alignment? Try Easy Agile Programs
Remember to refer back to the Agile Manifesto and The 12 Principles Behind the Agile Manifesto if you get stuck. These values and principles don't apply only to what you're building but also to how your team works. The key concept behind agile frameworks is to inspect and adapt — including both the software and how you’re functioning as a team.
Use as much process and documentation as you need, but no more. Look at what you have today and identify key items you don’t think the team can function without. Then add or eliminate steps as you discover the best way for your team to work in an agile framework.
At Easy Agile, we're here to help you get the most out of your agile practices and to help you grow into a high-performance, agile team. 💪 If you want to learn more, check out our other blog articles on agile topics.
If you need help with Atlassian's Jira tool, we've got some great apps for you to try. Our Easy Agile Programs for Jira app can help your planning activities through alignment at scale and visualising dependencies.
- Engineering
Foo Bar Nah
Or why you should give meaningful names to example variables
I bent over my desk in frustration, suppressing the urge to scream so as not to upset the rhythmic clack-clack of my coworkers. I’d been frustrated all morning by a particularly nasty React infinite re-rendering issue that I just couldn’t get working. The urge to scream came when, my own toolbox exhausted, I turned to Google.
You see, it looked like someone else had come across the same issue and had decided to record a solution for prosperity (and internet points). I eagerly scanned the page for the sample code that would save my morning. Finding it, my eyes were drawn to the dreaded fooBarBaz and I knew my morning was about to get a whole lot worse before it got better.
I actually love the history of programming and the little easter eggs fellow developers have passed down (my personal favourite - I am a teapot). These help to make this job interfacing with computers much more fun and human. I can appreciate that the practice of using fooBarBaz in naming example functions and variables has a long and storied tradition dating back at least to the Tech Model Railroad Club at MIT circa 1960. I acknowledge that the use of fooBarBaz is primarily not to introduce any distractions from the point which is being demonstrated. I also think that we should pretty much stop using them.
I am always awed by the amount of information my fellow developers have left out there for me on the internet. So many people in this field seem to have an innate need to help others, leading them to put in countless hours to fill Stack Overflow and blogs with useful information. I can only imagine that the people putting in their time and effort to this end are hoping that their efforts will help as many people as possible. fooBarBaz gets in the way of that.
Let me take off my developer hat for a second and put on my recently discarded, slightly misshapen and battered psychologist one. Interweaving complex facts into stories is a time tested technique which facilitates learning. Here in Australia, the technique has been used for tens of thousands of years by the Aboriginal and Torres Strait Islander peoples to help them to remember important and complex information such as the locations of waterholes across vast tracts of inhospitable desert. Our brains are networks of interconnected neurons so we are more likely to hold on to what we have learned when we are able to integrate new information into our current knowledge base. The modern term for this is associative learning.
Additionally, as I’m sure you’ll remember from school, keeping learning interesting has been demonstrated to be a powerful motivator which energises learning.
When we take all this time and effort to communicate with our fellow developers we can and should harness the advantage of associative learning and intrinsic motivation to make sure that the information we are putting out there is as useful as possible to as many people as possible. To this end I believe that we should give as much thought to meaningful naming when creating example code as we do in our own codebases.
Marijn Haverbeke’s Eloquent Javascript regularly comes at the top of lists of books you should read when learning Javascript (JS). It is no coincidence that he is also a master at using meaningful names to help people to better understand coding principles. When teaching new programmers about string comparison in JS he uses the following example:
Marijn piggybacks off our existing knowledge about Springfield’s favourite cartoon characters to give extra meaning and interest to this example. We know that Itchy and Scratchy are a mouse and cat respectively and so most definitely not the same.
Consider the same example but rendered with the dreaded Foo/Bar instead:
To seasoned developers, this might be easy enough to parse: you’ve read hundreds of examples like this and so have learned the association between Foo and Bar and internalised it. But this creates a barrier for learning for new developers who have not yet internalised this rule and instead increases the mental load for them to understand the concept. It also misses out on creating that little spark of interest or joy to help pique the reader's interest and so increase their motivation to understand the underlying concept.
I am not saying there is absolutely no place for fooBarBaz (although I think their utility is limited). The best way to use these terms is to emphasise that anything could be put in a certain place. An example of this is when we’re talking about arguments and parameters in JS functions. You see, there is no type checking in vanilla JS and so if we have a function like the following that takes a parameter and simply logs its value to the console, it doesn’t matter what type of argument we pass in:
I believe that these terms have the most utility in this case as their purpose is to emphasise that their type doesn’t matter. I would also add the caveat to this that using these terms in this way is only suitable when you are producing content for experienced developers who are going to have built a working understanding of these terms.
Even if this is aimed at experienced developers, I still believe that more meaningful names would be better in this example:
Another example where more meaningful variable names would be useful is in relation to metasyntactic variables. These variables are commonly found in source code and are intended to be modified or substituted before real-world usage. Whilst these variables are only placeholders, I believe that it is also better to use a variable name which offers more context to your developer comrade to assist them when they are reading and implementing the code in future.
We work in a wonderful profession with a rich history, where many people are willing to donate their time to helping to educate and mentor their fellow programmers. Using meaningful variable names in place of fooBarBaz is one way that we can ensure that this effort is worthwhile and helps as many people as possible. It lowers the barriers to entry for the profession, helping to create a more diverse and welcoming programming community.
So ditch the fooBarBaz (but not the Teapot) and go forth and spark joy!