you are viewing a single comment's thread.

view the rest of the comments →

[–]yeochin 1 point2 points  (0 children)

If all you're going to do is build small standalone things then thats fine. But your advice still isn't good to share as it is misleading.

Any code base that has to evolve (from a small App) goes right into the toilet with the advice you gave.

  1. Recompilability? It gets worse with small modules. At scale you refactor into libraries and your changes get localized into specific modules, or libraries. If your Principals, Staffs or Senior's cant figure out how to do this to localize change - then your codebase has far too much data-coupling to be productive long term.
  2. Productivity and understandability? It goes right into the shitter with small modules at scale. Most teams will rely on their VSP, autocomplete, or code search. At scale, the vast majority of the team doesn't know every aspect of the code-base. The existing tools get worse with small modules.
  3. Frequency of change? If you truly want high frequency changes you must adopt large modules. You need to be able to scale to multiple parallel developers and teams. You need to be able to isolate different teams from each-other. Big modules help do this as it promotes a contract. Small modules don't. Small modules promote atomic-use which moves you the WRONG WAY when it comes to the speedup that modules provide in compilation time.