11–20 of 115 posts
seems the article ends up with what was first done decades ago in PHP - separation of presentation and business logic. Btw i don't understand all this animosity toward PHP, especially given that pretty much all the modern web development is basically PHP-like, in spirit if not in actual implementation.
I'm not necessarily disagreeing. I just don't really get what you mean by that.
I prefer a more focused version of this principle: you should organize your data in a way that makes the design apparent. The code will follow later. This principle still works with the author's example. Most of the refactoring he did boiled down to modeling the data more accurately.
Or inversely: if the data presented are complex and convoluted, you will need mountains of docs to try explain its design.
seems the article ends up with what was first done decades ago in PHP - separation of presentation and business logic. Btw i don't understand all this animosity toward PHP, especially given that pretty much all the modern web development is basically PHP-like, in spirit if not in actual implementation.
Most PHP code is terrible. That's not really PHPs fault - it's capable of producing very nice programs with beautiful behavior.
As a language, it suffers a bit from being older and it was internally very inconsistent for a long time. For a long while, it's package management and practices were way behind the curve. Many people who program in PHP learned it as a first language, hacked together programs in it, and probably used hack together libraries and tooling.
PHP can be used with grace, but most people don't have that experience with it.
> The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s like pixie dust in its ability to make code more readable, loosely coupled, and impervious to bugs. I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requiremen…
Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then not enough abstraction.
Build simple, extend as needed. It's a 'frggin stats page where a developer forgot to remove a call. It could of been written much cleaner initially, but breaking it into a bunch of classes at the initial stage is fruitless abstraction.
> The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s like pixie dust in its ability to make code more readable, loosely coupled, and impervious to bugs. I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requiremen…
In my experience, that's only true code that's relatively well-engineered to begin with. Unfortunately, there are lots of bugs in real-world shipping software that have nothing to do with an unforeseeable environment, but are only the result of unnecessarily complex designs that even the original programmer hadn't completely thought through. So while good design might not eliminate bugs, bad (or no) design can definitely create them.
> The Embedded Design principle, which I briefly introduced in a previous post, states that you should always code in a way that makes the design apparent. It’s like pixie dust in its ability to make code more readable, loosely coupled, and impervious to bugs. I'm all for good software design, but claiming a design process can eliminate bugs is more fantasy than reality. Bugs typically come from unforeseen requiremen…
> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…
> Standard disclaimer: When reading software design advice, always imagine the examples given are 10x longer. Overengineering is bad. But, if you’re not sure whether applying a technique to your code would be overengineering, error on the side of doing it. Abstract early. Please, please, please absolutely disregard this advice. More errors, pain and suffering come from early abstraction and poor understanding then no…
I've been on the wrong end of those abstractions and it can (and often does) end up resulting in a lot of pain for everyone involved.
https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... is pretty relevant.