I have a website that I haven’t touched in 14 years and it still makes money. Build it right the first time.
Never touched it? A website? What about updating frameworks for security issues?
Can’t relate
This is so true.
Even if you do design clean modular code and document it, you’re getting a question a year from now about how it works, or someone just duct tapes on top of it.
I’ve even experienced this in the 3D printing community, where I design a highly parametric model and put lots of effort into making all of the major dimensions and qualities parameterized and dynamically adjustable, with lots of bounds checking and value clamping, with all the parameters at the top of my scad file with comments explaining what each variable does.
And then someone comes along to remix my model, says I don’t want to install openscad, and just scales the entire output stl to change the dimensions, squashing all the features of the model in the process (instead of having the size gracefully adjust with all the features moving around to account), and leaving anybody starting from their work with a hard to remix mesh with no parameters.
In my experience, this often doesn’t happen. So many developers are either inexperienced or cowboys, and there’s nothing inherently wrong with either. But at places where projects are small and numerous, teams often end up with nothing but a combination of the two.
As one of our office’s engineering “fixers”, I’ve taken over maintenance of several such projects. They usually have shattered remnants of code taken from other projects, open source libraries, internal libraries, stack overflow, and so on. Whole source files copied into the project, modified in ways that introduce impressive new failure cases while failing to add new functionality, and used in ways that completely ignore the features natively implemented in that code while those same features are bodged in as barely-working piles of if statements, balanced on a knife’s edge to avoid triggering the failure modes added by the project’s modifications of the copied code. I’m usually able to purge 20-30k lines of code from such projects in the first month, simultaneously closing multiple outstanding issues the PM had been led to believe were intractable.
That probably sounds like arrogance and/or shitting on everybody else’s work but it’s just reality at many workplaces due to a pace driven by unreasonable expectations from management. I just happen to be the person here that ends up sifting through the wreckage when a project reaches the inevitable osteoporosis phase, because of a natural disposition for reverse engineering. It would be great to escape for this and other reasons, as far as I can tell, most places aren’t that different.
This can work for junior devs who aren’t stuck in their ways. Unfortunately there are too many “senior” devs who are happy making crap. It’s hard to fight them constantly to do things properly (e.g. write actual commit messages rather than just “Fix #836”) so using tools like linters where possible is definitely a big improvement.
Or business decides all specs and design decisions that were made last quarter were actually garbage and yes we do want to be able to manually override every step of the carefully designed state machine. We’d like to be able to manually change all calculated sales data, but also the data needs to remain in a consistent state at all times. Oh and while you’re there, we decided the commission calculations will use a different system from now on. We expect it to be online by the end of the week, thanks.
The ‘document’ part also seems to be insanely hit-or-miss from my amateur experience. Self-documenting design/code is… well, not. Auto-generated documentation is also usually just as bad IMO. Producing good documentation really is a skill in and of itself.
Also small personal opinion: If your abstraction layers or algorithms are based off a technical concept, you should probably attribute that concept and provide links to further research, to eliminate future ambiguity or in case your reader lacks that background. Future you will probably thank you and anyone like me who immediately gets lost in jargon soup will also be thankful.
public class AbstractBeanVisitorStrategyFactoryBuilderIteratorAdapterProviderObserverGeneratorDecorator {
// boilerplate goes here
}
============ Top 5: =============== HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor: 97
AbstractAnnotationConfigDispatcherServletInitializer: 52
AbstractInterruptibleBatchPreparedStatementSetter: 49
AbstractInterceptorDrivenBeanDefinitionDecorator: 48
GenericInterfaceDrivenDependencyInjectionAspect: 47
============ Factories: ===============
DefaultListableBeanFactory$DependencyObjectFactory
ObjectFactoryCreatingFactoryBean
SimpleBeanFactoryAwareAspectInstanceFactory
SingletonBeanFactoryLocator$BeanFactoryGroup
ConnectionFactoryUtils$ResourceFactory
DefaultListableBeanFactory$DependencyProviderFactory
ObjectFactoryCreatingFactoryBean$TargetBeanObjectFactory
JndiObjectFactoryBean$JndiObjectProxyFactory
DefaultListableBeanFactory$SerializedBeanFactoryReference
AbstractEntityManagerFactoryBean$SerializedEntityManagerFactoryBeanReference
BeanFactoryAspectInstanceFactory
SingletonBeanFactoryLocator$CountingBeanFactoryReference
TransactionAwarePersistenceManagerFactoryProxy$PersistenceManagerFactoryInvocationHandler
AbstractEntityManagerFactoryBean$ManagedEntityManagerFactoryInvocationHandler
Okay, here we go. I’m going to spit out some bullshit and home someone corrects me if I’m wrong. I’ve looked for some explanations and this is what I’ve gotten.
Are you ready?
The Factory Pattern.
My understanding is that the purpose is a function to return any of several types of objects, but a specific type, not just an interface or whatever they might all inherit from.
I think most languages now have something like a “dynamic” keyword to solve this issue by allowing determination of the type only at runtime. (To be used with extreme caution.)
But most of the time I see the Factory pattern, it’s used unnecessarily and can only return one specific type. Why they would use a Factory pattern here and not just a plain old constructor confounds me.
Am I off base?
Factory pattern can return a mock type for testing or a production type, as needed, which makes it possible to unit test the code that uses the produced object.
This quick guide explains it well. Then it improves on it by explaining dependency injection.
You avoided writing spaghetti code.
Congratulations! Now maintain this piece of shit lasagna that takes place over multiple layers of abstraction and repositories.
So many developers don’t seem to understand the point of modularization and add lots of abstraction just for abstraction’s sake. It’s hella frustrating to take over a project like that.
We have those parts of code someone wrote years ago that is heavily abstracted for no reason at all other than that the developer thought it might be good. It’s just endless clicking on methods just to find no code at all and then you have to deep dive to figure out where stuff is actually computed.
Make it just one simple method call? Nah, it should be divided into 10 different abstract classes because whatever reason.
It’s also the most buggy part of the code because no one currently in the team dares to touch it.
And it can be in any language, but typically comes from someone who started with Java.
