I have worked as a professional software developer for 22 years, in the US, in Norway, in Cyprus, and remotely for companies all over the world - In addition, I've worked as a consultant due to my experience as an architect and advisor. I have never seen anything not resembling garbage.
I have worked on software that was installed in some of the largest hospitals in the world. I have worked on software licensed by all major banks in (unnamed) country in EU. I have worked on software used by hundreds of thousands of traders on a daily basis. I have worked on software used by some of the largest streaming service providers in the world. I can guarantee you with 100% certainty that it's all garbage, and for the same reasons too. Overcomplicated, over engineered, astronaut architecture, created by a bunch of autistics, capable of describing DDD and SOLID until normal people "cracks", and simply leaves the room from cognitive overload, resulting in a complexity resembling some creature from John's Revelations, with configuration files (Pulsar?) with tens of thousands of lines of YAML code, to create a "bare bones" (basic) installation.
I swear to (unnamed deity) if somebody suggests DDD, SOLID, or Micro Service architecture for me once more, based upon message brokers, event sourcing, sagas and CQRS, I'll end up having to go to prison for manslaughter ... :/
My favourite system was a partner administration system using Guids as "authentication tokens", automatically injecting these as GET QUERY parameters upon invocations to the backend. The Guids was the primary key for the user records in the database BTW. That thing was built in a frontend framework that was literally abandoned by its (only) developer 15 years earlier, scattered with jQuery all over the place, 15 years after jQuery was arguably obsolete may I add. It was creating 15 different "queues" in Solace, required 4 weeks of configuration to simply get it up running, and consisted of a monster codebase, with 25+ "micro services" dependencies, to simply get a single 200 OK HTTP response from its backend. I practically begged my manager to do the big rewrite. His response was "it works". The system has since been replaced and tossed in the garbage as far as I know ...
The above system was using Durandal as an "MVC framework" to "increase code quality". One of my views had 6,000 LOC. One single JavaScript file. I was going mental over having "project team lead" responsibilities over the thing, and suffered a 2 year long non-stop headache because of "all the attempts to increase code quality" ... :/
If you see things "differently", then either I'm the one with "a problem", or maybe something else is wrong here ...
My condolences. Perhaps I'm more lucky or just working in the industry little bit longer (about 35 years), but I saw projects which didn't look like ones you're describing. By the way, I share your skepsis regarding microservices (you can find many related articles in my blog).
The vast majority of the projects I was working on are enterprise ones. Obviously, they are not available publicly. Nevertheless, my current project is open source, and you can take a look here. It's definitely far from perfect, but it not even close to the tragedy mentioned above in a comment I've replied to.
Of course, there are also my personal projects, but they are too small to serve as an example.
You are obviously highly skilled, and know what you're doing, but you're also (kind of) proving the point with things such as this - Where we're 9 folders in, having a class name consisting of 5 words and 30+ characters. But as I started out with, you're highly skilled, and I don't mean to put you down as a person, but you're still arguably proving the initial statement of my article ... :/
The number of words in the class name does not matter, it's a "mechanical" metric, just like LOC. The purpose of the name is to provide as much of the business context as necessary, and this particular name does exactly that. You might notice that it does not contain any design pattern names or any other useless stuff. The importance of preserving business context I've already stressed.
Good point. However, if it was written in a functional context its name would be a single verb, such as "Create", "Run", "Transfer", etc ...
The whole point with my OP was how FP results in more readable code. More readable code translates to more maintainable code. More maintainable code again, results in less costs and less technical debt ...
If there's only one person maintaining the code, of course the above is irrelevant. The problem doesn't become a problem before somebody else needs to understand the code ...
Yet again, I want to emphasise I don't intend to pick on you in particular - You're obviously highly skilled, and a pride to your employer ...
If you take a look into my blog, you'll discover that I'm a big proponent of FP. I also believe that there is no point to confront OOP and FP. In fact, they perfectly fine complement each other and quite often trying to achieve same goal, just using slightly different (complementary) views on same things.
The class which you've pointed, actually demonstrates this approach in action: the class serves as a holder of the "context" (hashing algorithm) and its methods basically nothing else than partially applied functions in FP. This class utilizes OOP to achieve additional goals:
Preserve more business context, in particular, knowledge that that all 3 methods are logically related and should be consistently configured (partially applied in FP terms)
Allows to maintain 1 thing (class) instead of 3 (functions)
Makes use of different algorithms convenient and less error-prone.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have worked as a professional software developer for 22 years, in the US, in Norway, in Cyprus, and remotely for companies all over the world - In addition, I've worked as a consultant due to my experience as an architect and advisor. I have never seen anything not resembling garbage.
I have worked on software that was installed in some of the largest hospitals in the world. I have worked on software licensed by all major banks in (unnamed) country in EU. I have worked on software used by hundreds of thousands of traders on a daily basis. I have worked on software used by some of the largest streaming service providers in the world. I can guarantee you with 100% certainty that it's all garbage, and for the same reasons too. Overcomplicated, over engineered, astronaut architecture, created by a bunch of autistics, capable of describing DDD and SOLID until normal people "cracks", and simply leaves the room from cognitive overload, resulting in a complexity resembling some creature from John's Revelations, with configuration files (Pulsar?) with tens of thousands of lines of YAML code, to create a "bare bones" (basic) installation.
I swear to (unnamed deity) if somebody suggests DDD, SOLID, or Micro Service architecture for me once more, based upon message brokers, event sourcing, sagas and CQRS, I'll end up having to go to prison for manslaughter ... :/
My favourite system was a partner administration system using Guids as "authentication tokens", automatically injecting these as GET QUERY parameters upon invocations to the backend. The Guids was the primary key for the user records in the database BTW. That thing was built in a frontend framework that was literally abandoned by its (only) developer 15 years earlier, scattered with jQuery all over the place, 15 years after jQuery was arguably obsolete may I add. It was creating 15 different "queues" in Solace, required 4 weeks of configuration to simply get it up running, and consisted of a monster codebase, with 25+ "micro services" dependencies, to simply get a single 200 OK HTTP response from its backend. I practically begged my manager to do the big rewrite. His response was "it works". The system has since been replaced and tossed in the garbage as far as I know ...
The above system was using Durandal as an "MVC framework" to "increase code quality". One of my views had 6,000 LOC. One single JavaScript file. I was going mental over having "project team lead" responsibilities over the thing, and suffered a 2 year long non-stop headache because of "all the attempts to increase code quality" ... :/
If you see things "differently", then either I'm the one with "a problem", or maybe something else is wrong here ...
Just sayin' ... :/
My condolences. Perhaps I'm more lucky or just working in the industry little bit longer (about 35 years), but I saw projects which didn't look like ones you're describing. By the way, I share your skepsis regarding microservices (you can find many related articles in my blog).
Could you, please, show a project which you like or you think it's nearly fine?
The vast majority of the projects I was working on are enterprise ones. Obviously, they are not available publicly. Nevertheless, my current project is open source, and you can take a look here. It's definitely far from perfect, but it not even close to the tragedy mentioned above in a comment I've replied to.
Of course, there are also my personal projects, but they are too small to serve as an example.
You are obviously highly skilled, and know what you're doing, but you're also (kind of) proving the point with things such as this - Where we're 9 folders in, having a class name consisting of 5 words and 30+ characters. But as I started out with, you're highly skilled, and I don't mean to put you down as a person, but you're still arguably proving the initial statement of my article ... :/
The number of words in the class name does not matter, it's a "mechanical" metric, just like LOC. The purpose of the name is to provide as much of the business context as necessary, and this particular name does exactly that. You might notice that it does not contain any design pattern names or any other useless stuff. The importance of preserving business context I've already stressed.
Good point. However, if it was written in a functional context its name would be a single verb, such as "Create", "Run", "Transfer", etc ...
The whole point with my OP was how FP results in more readable code. More readable code translates to more maintainable code. More maintainable code again, results in less costs and less technical debt ...
If there's only one person maintaining the code, of course the above is irrelevant. The problem doesn't become a problem before somebody else needs to understand the code ...
Yet again, I want to emphasise I don't intend to pick on you in particular - You're obviously highly skilled, and a pride to your employer ...
If you take a look into my blog, you'll discover that I'm a big proponent of FP. I also believe that there is no point to confront OOP and FP. In fact, they perfectly fine complement each other and quite often trying to achieve same goal, just using slightly different (complementary) views on same things.
The class which you've pointed, actually demonstrates this approach in action: the class serves as a holder of the "context" (hashing algorithm) and its methods basically nothing else than partially applied functions in FP. This class utilizes OOP to achieve additional goals: