Software engineering books to read and reread
quentin.delcourt.be
quentin.delcourt.be
Domain Driven Design is also a dangerous paradigm to apply everywhere. In fact I suspect that the majority of the time it's a mistake. Specifically the act of hard coding business concepts (products and processes) as first class citizens (classes, services) into your software. This makes your business inflexible and requires engineering effort to iterate on your business processes. It's a poison, and the deeper you build it into your architecture, the deeper the poison seeps, locking you into stale business concepts.
Domain Driven Design should be analyzed much more critically than it is, especially given how much time engineers waste slogging through the ramblings of Evan's clouded mind. I highly recommend https://dev.to/cheetah100/domain-driven-disaster-147i for further reading.
“Copyright is intended to protect the original expression of an idea in the form of a creative work, but not the idea itself.”
Learning Domain-Driven Design, by Vlad Khononov
It’s 340 pages and has good reviews on Amazon etc, but I’d be especially interested in feedback from anyone within a good understanding of the topic who’s read the O’Reilly book.
You're winter project is constructing a 3000 word amazon review on the book that will amass 500 likes across the next 20 years. you can look back on it when you retire and smile.
If you can't iterate on the specification of business at the speed business itself needs to change, that's a problem, but it's a process problem, not something inherent in specifying business process in code.
Does anyone have any experience or info on how to bring our Business logic out from domain classes and structures, into configuration?
Any examples or sample code?
You end up trying to debug/understand logic that slips through your hands like wisps of smoke.
It’s a trade off, just realize you are building a system that’s harder to reason about and add more observability and/or an ability to interact with the live system.
When you create software to support a business, you automatically support business processes. The better you try to support those processes, the better the user experience and the more "tied" the software becomes to those processes.
Often, when you create the software and analyse the needs, it is also a learning experience for the business because they are forced to think about the business processes they have and about the business processes they want to move to.
If, in that business context, certain needs or flows change, it is natural that it requires changes on the code, but those changes should rarely be so dramatic that you have to rewrite big parts of the application. When that happens, there must have been a serious flaw with the analysis and design, or the code was simply bad.
And yes, for certain things, there is a bit of a balance in whether it should be configuration or code. But from the analysis, for most things it will be very black-and-white on whether it should be configuration or code.
> Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain.
I don't understand this comment. Amazon S3 on its own would be very bad to support the business processes of a video provider. And software to support a video provider business would be very bad as a general blob storage solution.
Obviously there is a difference between a general "product" that you want to make usable for a target audience as big as possible and a customised solution to support a business in the best way possible. But both are also different domains. So, yeah, if you create something for a certain domain, it will be an issue if you want to use it for a completely different domain.
Besides, JavaScript: The Good Parts remains one of the best programming books I've read (direly in need of a new edition).
[1] book: http://www.dataorienteddesign.com/dodbook/dodmain.html / more: https://github.com/dbartolini/data-oriented-design
My opinion is that at this point you wouldn't read JavaScript: The Good Parts to become more effective with the language (the books original intent).
Modern JavaScript is substantially different from what's illustrated in that book both in terms of language design and popular style. The ecosystem built around the web has moved on as well. Very few programmers spend their day manually manipulating the DOM anymore - almost always there's a library in between doing that.
The reason I _would_ recommend JavaScript: The Good Parts to someone is that it's one of the best examples of a well written technical book that I'm aware of. It's at once clear, deep, and concise. It's an easy read that assumes very little in terms of the reader's prior knowledge.
So many technical books are frankly very poorly written but Crockford, whatever you think of him, is exceptionally gifted at illustrating technical topics in a way that is easy to understand.
"Crockford’s JavaScript: The Good Parts2 was a wake-up call in 2008, but much of its message has been internalized in subsequent changes to the language."
And the Rhino book is too large for what I need to accomplish.
People come to DP thinking they are going to understand the structure and maintenance of 'good code'. None of that is in that book. In fact given how we have demolished a couple of patterns that are laid out in that book (notably, Singletons as harmful), less than none of that is in that book.
I started telling people they should read Refactoring instead. And if they wanted a second recommendation for something to read after Refactoring, that they should read Refactoring a second time.
Many(most?) 'design patterns' are just standard ways of coming up with abstractions that your language does not provide. It's no wonder that particular book became popular at around the same time a particular programming language saw large adoption.
I strongly recommend => Refactoring Guru https://refactoring.guru/design-patterns/python It's a lot of patterns with _short_ clear descriptions, and lots of diagrams! Recommended even if you're not doing Python. An excellent investment, and a bunch of it is free.
https://www.zdnet.com/article/erich-gamma-a-pattern-of-succe...
On its face that implies that Gamma was a kid, and so the work is purely academic, but he's around 8 years too old to have been starting a PhD in '91 without any prior industry experience. It's still mostly his work (otherwise it's not his PhD) with the other 'authors' consulting and copy editing.
By seeing best practices emerge from eternal structures of mathematics, often we are able to derive situations when best practices do not work too.
This book is good: https://bartoszmilewski.com/2014/10/28/category-theory-for-p...
Relevant quote from the preface:
> Changes in hardware and the growing complexity of software are forcing us to rethink the foundations of programming. Just like the builders of Europe’s great gothic cathedrals we’ve been honing our craft to the limits of material and structure. There is an unfinished gothic cathedral in Beauvais, France, that stands witness to this deeply human struggle with limitations. It was intended to beat all previous records of height and lightness, but it suffered a series of collapses. Ad hoc measures like iron rods and wooden supports keep it from disintegrating, but obviously a lot of things went wrong. From a modern perspective, it’s a miracle that so many gothic structures had been successfully completed without the help of modern material science, computer modelling, finite element analysis, and general math and physics. I hope future generations will be as admiring of the programming skills we’ve been displaying in building complex operating systems, web servers, and the internet infrastructure. And, frankly, they should, because we’ve done all this based on very flimsy theoretical foundations. We have to fix those foundations if we want to move forward.
1. Structure and interpretation of computer programs
2. Software architecture the hard parts
3. Designing data intensive applications
Even if what you say about IDEs is true (which I don't think it is), it's still instructional to know the "why" of a refactor, and when to apply it. Perhaps it's too basic for you personally, but there's much wisdom Fowler is passing on to the world here.
It is slightly out of date by now, which carries the risk people reading it and interpreting its advice "literally" (which by definition will take your code back by 15 years). But the main message of the book is as relevant today as then, and a great way to think about writing code and how to approach large complex codebases that need to be tamed.