4 ms·

One of the nightmares I've experienced time and time again in large mature codebases is incomplete abstractions. Some developer gets a great idea of how to abst

by kevsim 6y ago

One of the nightmares I've experienced time and time again in large mature codebases is incomplete abstractions. Some developer gets a great idea of how to abstract something away, defines the plumbing needed for said abstraction, and sets to work going through the codebase bit by bit, moving code over to this new abstraction. But then, they leave. Or they change projects or they just lose their enthusiasm for this major refactor. And you're left with a half baked abstraction in the code. Then another developer comes along, and another, and another and before two long you've got a spaghetti mess of incomprehensible "abstractions". I was told by a friend once that the iOS app for Facebook has a whole bunch of implementations encapsulating what a "form" is in the app. Many developers came and went with their own ideas of what that abstraction should look like, but none became the one abstraction to rule them all.

cooperadymas 6y ago
I run into this scenario particularly in large React code bases. Multiple developers building their own half baked abstractions on top of a framework with its own continually shifting abstractions. Lack of uniting engineering leadership and not enough time to devote to code discipline - it's a real joy.
- kevsim 6y ago
  Oh yeah! Nothing like a bunch of old poorly thought out "render props" style high level components getting mushed together with a bunch of new poorly thought out custom React hooks :-)
- searchableguy 6y ago
  My problem with react is that there are so many ways to do the same things that reusability and refactoring becomes harder than it should be. I usually found 3-4 ways of styling in a medium codebase on github. I find varying degrees of state management - some built with context and hooks, some imported and traditional mobx/redux. I haven't found many significant opportunities to reuse code without refactoring a lot or doing micro files of 7 lines of code and separating logical components. I now think of react as a library to build your own frameworks. It aligns perfectly with the javascript ecosystem mentality.
  - randompwd 6y ago
    Just started looking at Spring Boot (w/Kotlin). Never try it. A bazillion ways to do basic web service & web things and every google search returns different methods. Nightmare.
    - vips7L 6y ago
      Did you look at https://spring.io/guides https://spring.io/guides ? Building a REST service is one of the examples. https://spring.io/guides/tutorials/rest/ https://spring.io/guides/tutorials/rest/
kqr 6y ago
This is something I've struggled a bit with professionally recently. I've been leading initiatives to modernise legacy applications (both in terms of code and user experience, measurably so). This cannot be done all at once -- the applications are large and used in production and need to be maintained. So the only option seems to be to commit to the legacy (in many ways measurably bad) implementation, or start upgrading/rewriting it a little bit at a time. Of course, the latter is good. Except it leads to the situation you describe with multiple ongoing half-finished abstractions. There are better ways to do it: not do all the plumbing first, and then the actual business logic, and instead do thin vertical slices at a time. But it still feels... wrong.

by kevsim 6y ago

cooperadymas 6y ago

I run into this scenario particularly in large React code bases. Multiple developers building their own half baked abstractions on top of a framework with its own continually shifting abstractions. Lack of uniting engineering leadership and not enough time to devote to code discipline - it's a real joy.

kevsim 6y ago
Oh yeah! Nothing like a bunch of old poorly thought out "render props" style high level components getting mushed together with a bunch of new poorly thought out custom React hooks :-)
searchableguy 6y ago
My problem with react is that there are so many ways to do the same things that reusability and refactoring becomes harder than it should be. I usually found 3-4 ways of styling in a medium codebase on github. I find varying degrees of state management - some built with context and hooks, some imported and traditional mobx/redux. I haven't found many significant opportunities to reuse code without refactoring a lot or doing micro files of 7 lines of code and separating logical components. I now think of react as a library to build your own frameworks. It aligns perfectly with the javascript ecosystem mentality.
- randompwd 6y ago
  Just started looking at Spring Boot (w/Kotlin). Never try it. A bazillion ways to do basic web service & web things and every google search returns different methods. Nightmare.
  - vips7L 6y ago
    Did you look at https://spring.io/guides https://spring.io/guides ? Building a REST service is one of the examples. https://spring.io/guides/tutorials/rest/ https://spring.io/guides/tutorials/rest/

kqr 6y ago

This is something I've struggled a bit with professionally recently. I've been leading initiatives to modernise legacy applications (both in terms of code and user experience, measurably so). This cannot be done all at once -- the applications are large and used in production and need to be maintained. So the only option seems to be to commit to the legacy (in many ways measurably bad) implementation, or start upgrading/rewriting it a little bit at a time. Of course, the latter is good. Except it leads to the situation you describe with multiple ongoing half-finished abstractions. There are better ways to do it: not do all the plumbing first, and then the actual business logic, and instead do thin vertical slices at a time. But it still feels... wrong.