Timeline for DRY principle vs decoupling (business from GUI)
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 15, 2022 at 12:08 | comment | added | Ced | @Flater Thanks for the opinionated (and backed up) response, sometimes you need that when you have to make choices that seem hard to make. I agree with everything you said and it comforts me it my decisions. | |
| Jul 14, 2022 at 11:42 | comment | added | Flater | @Ced: That being said, everything can be considered on a case by case basis. But be very, very, VERY careful of the honey trap, because it will look more enticing than it is. No matter how often the sailor tells you that he really wants to steer the boat towards the sirens, do you really trust his judgment? | |
| Jul 14, 2022 at 11:40 | comment | added | Flater | @Ced: Why was I hired? By upper management, who had a third customer in a row back out of a project that ran for over twice the projected time and still did not even come close to their deliverables because developers kept needing to redesign the entire stack because the code was anything but change-friendly, even for minor changes; and some plain bugs took months to solve due to piles upon piles of undebuggable bad practice code. When I arrived, the project was at the "just a few more bugs and its done" stage. Two years later, it was still "just a few more bugs and it's done". | |
| Jul 14, 2022 at 11:36 | comment | added | Flater | @Ced: It is, by a wide margin, better to create a layer too much than it is to create a layer too little. Repetition is trivial. Having to separate existing code into separate layers and interfaces is pure hell. Secondly, avoiding necessary layers is a honey trap. People get lured in by the quick deliverables at the start of the project, and by the maintenance phase of the project they realize that they painted themselves into a corner they can't get out of without major rewrites, which will never be approved since the expectation of quick deliverables has been set. | |
| Jul 14, 2022 at 8:26 | comment | added | Ced | Why did they hire you in the first place then ? I reached this question to know if I was overengineering too, and to some extent I think there is a case to be made for it too. It's just that decoupling goes hand in hand with more repetition. So I don't think you can blindly say, there is too much coupling here, it's on a case by case basis no ? | |
| Feb 15, 2021 at 0:59 | comment | added | Mike Robinson | "Wow, Flater ... I feel much better now." I thought that I was the only consultant left who had ... :-) | |
| Feb 15, 2021 at 0:27 | vote | accept | George Z. | ||
| Feb 15, 2021 at 0:27 | comment | added | George Z. |
If so, I mock VehicleService and VehicleExportService for the presenter and yes, tests run. But then I thought, well, what If I create the VehicleXService in the future?I will have to come back to all presenter tests and fulfill the VehicleXService (constructor) dependency. So I ended up with "hey, that does not sound right. Perhaps I should make the whole GUI an autonomous module and just adapt everything under a package (or module). Then, "nothing" in GUI will have to change". But since it felt weird copy pasting properties It made me suspicious. Thank you for your time.
|
|
| Feb 15, 2021 at 0:27 | comment | added | George Z. | I was kindly aware that my question (and the answers I would get) is opinion based. However, as an (almost) graduate student opinions can help me too. Because I can't be sure that I have analyzed all scenarios in my mind and not miss something. The reason I asked this question is the tests in my GUI (I can't live without testing my GUI, it will give me nightmares). I was thinking to go with the business models (overzealous DRY as u said). | |
| Feb 14, 2021 at 23:07 | history | edited | Flater | CC BY-SA 4.0 |
added 16 characters in body
|
| Feb 14, 2021 at 23:01 | history | edited | Flater | CC BY-SA 4.0 |
added 12 characters in body
|
| Feb 14, 2021 at 22:54 | history | answered | Flater | CC BY-SA 4.0 |