Conversation

Notices

1. Embed this notice
   Martijn Faassen (faassen@fosstodon.org)'s status on Wednesday, 11-Oct-2023 07:45:41 JST Martijn Faassen

   The architectural trick I use over and over again to help make more production code more maintainable is the "pull it into a library" move. Extract/create functionality as a separate library, with its own API, tests, docs.

   1/2

   #programming #tdd

   • 洪 民憙 (Hong Minhee) repeated this.
   • Embed this notice
     Martijn Faassen (faassen@fosstodon.org)'s status on Wednesday, 11-Oct-2023 07:45:55 JST Martijn Faassen

     in reply to

     Reuse is not the primary goal of creating libraries for your application, (though it helps to pretend it is): separation is.

     A little known fact is that libraries and frameworks are in many ways easier than applications; the main hard part is getting the boundaries and abstractions right. Everything else is easier. In particular, you can do TDD more easily!

     Getting traction with TDD in production code is hard and this I found helps a lot.

     2/2

     #programming #tdd

   • Embed this notice
     Martijn Faassen (faassen@fosstodon.org)'s status on Wednesday, 11-Oct-2023 07:47:10 JST Martijn Faassen

     in reply to

     • Arend van Beelen

     @arendjr
     I think you are talking about the risks of premature organisation. I am indeed not proposing you create empty libraries in advance speculatively; that would be terrible. Or build the framework before you build the application.

     This process needs to be an active integrated part of developing an application. It can happen in all stages but the needs of application needs to drive it.

     One trick in problem solving is that generalizing it can sometimes make it easier to solve.

   • Embed this notice
     Arend van Beelen (arendjr@mstdn.social)'s status on Wednesday, 11-Oct-2023 07:47:17 JST Arend van Beelen

     in reply to

     @faassen I think this advice is highly situationally dependent. I can agree to some extent, but only when the problem domain is well-known and well-understood.

     As you say, getting the abstractions right is harder. But abstractions are already a hard problem, especially when a product is in its early stages. Making that problem even harder outweighs all the benefits in many situations IMO. Not only have you made it harder, you’ve also increased the cost when getting it wrong.

     洪 民憙 (Hong Minhee) repeated this.