Oh boy, I remember when I started getting familiar with Software Engineering patterns and y'know these patterns have names assigned to them and try to desperately to memorize them because some day it will come in handy! I'm a true software developer if I can apply these patterns. Yeah yeah, etc etc. What I didn't know was that people would co opt these terms to mean or do something else entirely. Abuse is what this is.
Factory Pattern
The easiest and most memorable pattern in Software Engineering forever.
Unbelievable when I encountered code that was CRUD (literally and figuratively!) code named as *Factory. WTF is going on here, OK, let me Google this and see what this is supposed to do by convention. Oh, right it just builds objects that can be used elsewhere.
Maybe, just maybe, you could get away with READ and CREATE, but update and delete?! Update and Delete are unforgivable and unforgettable.
There is general agreement from some of the newcomers (<1 years) that the suffix made no sense since it did business logic, but because the suffix was being used already just monkey see, monkey do. I can't survive in that kinda environment for long.
Just no, don't mangle this term EVER! We know what factories do. Just use the term -Crud or -Service or -er, -tor like a Coordinator, whatever it is supposed to be.
Abstract Pattern
or the lack of. It was discouraged to use abstract classes outside of libraries for some reason that I can't remember. This is bull****. Abstract classes are useful any and everywhere just like interfaces are.
Don't let people tell you what to do without justification such as security, compliance and or code incompatibility.
Shared Code Pattern a.k.a Reduce, Reuse, Recycle
Reusing code makes sense, so why not share this code everywhere without packaging them up. Let's rebuild the code 100x over and over wasting precious time and energy and convince ourselves this is the greatest way to find bugs during the build/deploy process.
GOOGLE does it?! Oh, how do they do it? "They have some really good tools" Hmm, I wonder how or why they built those tools. I wonder if those tools cache and reuse artifacts. Hmm...
Every part of rebuilding a library every time a build is is initiated is not reduce, reuse or recycle of anything! If you see this pattern then run!
You are working with very much subpar engineering. Very amateur level. Package managers were created for this pattern. Build once and share to many places.
Guidelines Pattern
It is interesting to see that many workplaces have guidelines for code and people doing code reviews take it to be a Rubric, so they stall the feature development process by invoking guideline no. x or if something was in a gray area then a new guideline is needed.
Oh god, if a new guideline is needed every time something is in a gray area. 1. Run 2. They are not actually guidelines. 3. Disguised Bureaucrats
Rules, laws, guidelines and etc. are only meant to guide in good spirit, not as something to invoke in every case unless you are a Court or Govt Agency.
Standards Pattern
Standards is probably one of the more overused and abused words in Software Engineering. Company standard, programming language standard, network standard and etc. Maybe it makes things sound more important so whoever sees it should follow it.
Imagine having two villages and wanting a way to trade between them. What's the first thing they gonna do? Build a road? Come up with "standards" on how to build the road before they build it? What should the standard be if one doesn't know what it will transport? ARGH, we need a standard before we make progress.
I'll tell you what I would do? I'd walk the distance with my cargo even if I have to do it multiple times a day. If some technology comes along that allows me to do it more efficiently then I'll switch and use that. Fuck your road and fuck your standards. I want to TRADE and if you cannot facilitate that quickly then you are a obstacle in the road.
Yes, do not block people because we want to come up with a "standard" first. Anyone can switch to a "standard" later if the standard was made in good faith discussions with everyone who is doing things however they wanted to.
Generic Application/Library Name Pattern
I've seen this pattern pushed by people before. "Why not just call the application what it is?" You application serves Users, so call it "User service" or that application generates x, so call it x service
What brings this up? "I just want to be able to look at the name and know what it is." Sounds reasonable doesn't it?
I want to create a service that processes user information to do auditing and security checks. What should I call it? "User Security Processor" "User Audit and Safety Processor" and etc. bull shit generic names. Let's call it "User Security Processor." 3 months down the road, security team want to implement their own audit and security checks on users. Oh, a "User Security Processor" already exists, so let's piggyback off of that or if it doesn't already do what we want then choose another name.
Wow, so much work just for a name that is descriptive. It would have been simpler to call it whatever you wanted and have a description that said exactly what it does. Searchable descriptions are far more informative than a name that is descriptive. It is funny that people make fun of enterprise software class names, yet here we are doing the exactly same thing with Application Names. Whatever enterprise or professional means right?!
Come up with a way to set application and library descriptions and search through them.
Don't Mangle Patterns
If you mangle patterns then shitty culture will come. Retention rates will be seen as a problem. Referrals will not come in and etc. Worst part of it is that it becomes your reality, so you don't even see the totality of it. People will point out the problems, but nothing will come of it unless they are empowered to do so.
I have a sense of what seems right in the context based on past experience.