4 ms·

- avoid code sharing wherever possible. It creates an implicit dependency. (If you have a common library or util file, you've done it wrong. try again.) Can yo

- avoid code sharing wherever possible. It creates an implicit dependency. (If you have a common library or util file, you've done it wrong. try again.) Can you clarify on this a bit? Isn't part of the point of classes and libraries to encapsulate common functionality so that it doesn't need to be separately maintained in multiple places? You listed an ORM as an example, what is a better solution to managing database interaction across an application?

bliti 11y ago
Code sharing is not the same as using the same library in different places. That is managed by a proper dependencies manager and not as issue. The problem is when people take code from the codebase and spread it all over. In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself.
- MaulingMonkey 11y ago
  > Code sharing is not the same as using the same library in different places. Sounds like you're using a different definition than AdrianRossouw. > In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself. That sounds like an issue with the wrapper, not so much the code sharing per se. That said, I've seen issues with... "overly shared" code. The example that comes to mind was some UI code on a game - we had various menus, and they all tried to share a huge chunk of programmatic UI layout & control flow logic. However, as so many menus were unique and special snowflakes with their own unique designs and layouts (even justifiably!), this meant the shared code ended up with a lot of special cases. Worse, trying to "fix" the layout to work right in one place usually broke it in another. QA eventually caught almost everything, but it was hell to fix and debug. I would've very gladly eaten a 5x total size increase to the relevant code, full of copy & paste duplication, rife with bugs that were fixed in 7 places but missed in 3 others, just to detangle those menus from each other.
  - bliti 11y ago
    I've seen what you described too. It's crazy. The wrapper I mentioned was about making code sharing easier. Never taking into account that Django already provided a fairly clean interface to work with. These guys were wrapping Django ORM query code with funciones that took an infinite amount of parameters through Python's kwargs parameter. Nuts.
  - Xixi 11y ago
    I've had to deal with this exact same problem of unrelated UIs sharing UI layout & control flow logic, messily packaged deep in 8 layers of inheritance... A nightmare. It was a GWT + GXT codebase. The worst is that I did partake into creating the mess in the first place. Now when it comes to UIs I favor decoupling at the expense of a little code duplication. Because two otherwise unrelated menus happen to share the same layout/structure/flow at a given time, doesn't mean this structure needs to be abstracted away: the code is likely to diverge later anyway as the unrelated views evolve. Abstracting away composable patterns for GUIs is hard. Especially for me given that I mostly write backend code...

bliti 11y ago

Code sharing is not the same as using the same library in different places. That is managed by a proper dependencies manager and not as issue. The problem is when people take code from the codebase and spread it all over. In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself.

MaulingMonkey 11y ago
> Code sharing is not the same as using the same library in different places. Sounds like you're using a different definition than AdrianRossouw. > In one pretty awful scenario, I saw two programmers create a wrapper around the ORM then try and use that all over the place. That made testing awfully difficult because the wrapper was full of errors itself. That sounds like an issue with the wrapper, not so much the code sharing per se. That said, I've seen issues with... "overly shared" code. The example that comes to mind was some UI code on a game - we had various menus, and they all tried to share a huge chunk of programmatic UI layout & control flow logic. However, as so many menus were unique and special snowflakes with their own unique designs and layouts (even justifiably!), this meant the shared code ended up with a lot of special cases. Worse, trying to "fix" the layout to work right in one place usually broke it in another. QA eventually caught almost everything, but it was hell to fix and debug. I would've very gladly eaten a 5x total size increase to the relevant code, full of copy & paste duplication, rife with bugs that were fixed in 7 places but missed in 3 others, just to detangle those menus from each other.
- bliti 11y ago
  I've seen what you described too. It's crazy. The wrapper I mentioned was about making code sharing easier. Never taking into account that Django already provided a fairly clean interface to work with. These guys were wrapping Django ORM query code with funciones that took an infinite amount of parameters through Python's kwargs parameter. Nuts.
- Xixi 11y ago
  I've had to deal with this exact same problem of unrelated UIs sharing UI layout & control flow logic, messily packaged deep in 8 layers of inheritance... A nightmare. It was a GWT + GXT codebase. The worst is that I did partake into creating the mess in the first place. Now when it comes to UIs I favor decoupling at the expense of a little code duplication. Because two otherwise unrelated menus happen to share the same layout/structure/flow at a given time, doesn't mean this structure needs to be abstracted away: the code is likely to diverge later anyway as the unrelated views evolve. Abstracting away composable patterns for GUIs is hard. Especially for me given that I mostly write backend code...