If patterns were programmers
Never thought, what if the OOP patterns are projected onto the work of programmers? Singleton -developers
Developer with bus-factor = 1. Typically, one of the "old-timers" of the project, which had a hand in many components and only he knows how these parts work together. Almost “not sawed out” from the project, or without it, everything starts to “work somehow wrong”. On any question “how does it work” always answers “yes it’s easier for me to cut it myself” and it cuts it.
Registry- developer
As well as singleton, this is an old-timer developer, however, unlike him, he does not know the implementation details, but knows that the component basically exists. Often, it serves as a "living reference" and can advise on any question about the code where to see how this is done.
Factory-developer
Developer in a web studio. The input often receives several parameters, such as a finished layout and a couple of pictures, and the output is a business card website or another online store. As a rule, over time, it seeks to reduce the number of input parameters in order to increase the speed of work, or even automate the process.
Adapter -developer
A developer who understands well the language of both managers and developers. An irreplaceable participant in planning and evaluating tasks. It is able to “digest” the phrase “Make Yourself Hurt” into more or less understandable causal relationships between entities that can be implemented by other developers.
Proxy Developer
The same adapter developer, only without introducing “additional utility”. He meets with managers, starts tickets from their words, which he then stupidly reassigns to other developers. At the same time, he is trying in every possible way to demonstrate his indispensability in this process to both parties.
Observer- developer
Regularly monitors all master brunch commits and makes them review even if this is not in his area of responsibility. If he doesn’t like something in the review, he loves to run events on refactoring and revision tasks.
(Single-) Strategy Developer
When joining any new project or task, he tries to implement everything according to an algorithm developed in advance on other projects. Even if for this you need to draw on dependencies from other components, as a rule, justifying it with the fact that "so right, I did so many times and it worked."
Facade- developer The
responsible representative of the team, as a rule, is a team leader. It can always take on all organizational issues related to the work of the whole team.
LazyInitialization -developer Starts
to implement a task only when someone asks for its status. Strongly does not recognize the work on the issue tracker through the backlog.
Null-object developer
A developer who reinsures absent team members if managers have questions about any functionality. I’m always ready to help you figure it out, even if you don’t know anything in the subject area.
God-object- developer
The only developer on the project from the very beginning. The degree of god-ovost grows as the project lacks a version control system, documentation and the growth of the “zoo”.
Visitor- developer
Has a general idea of how to write code correctly, and tries to convey it to other developers in their components. It can creep into your code, change indents and hyphens, add DOC comments, and even rename “classes” and methods “correctly” and on this will consider its mission accomplished.
ChainOfResponsibility-developer
Before zapilit task, begins to methodically fill up with questions of everyone who, in his opinion, can help him with it, starting from team lead, ending with a colleague sitting next to him. As soon as the “next in the chain” begins to say “Yes, I'm sick of it, take it and figure it out myself,” he switches to the next one and so on until someone writes everything down to the details or the colleagues run out.
I wish you more good colleagues-patterns in your work.