2 ms·
I think this distinction is harmful. Your application code should include areas that function as "library code." We do this at work with an explicit UI librar
by wry_discontent 6y ago
I think this distinction is harmful. Your application code should include areas that function as "library code." We do this at work with an explicit UI library that we package separately, but there's no reason it needs to be packaged separately, just create directories that represent some library-esque element of your application and heavily test it and write docs for it, like you would a library.
- dragontamer 6y agoThe distinction is helpful from an organizational perspective. From a manager's point of view, they need to know where the money is going. If ProjectA is the "support" for LibraryA (and the managers don't know about it), it will look like ProjectA is costing more and behind-schedule. But if you explicitly split into ProjectA + LibraryA, the managers can see where the money is going, and better allocate funds matching the business's priorities. Financially: the goal of LibraryA is to outlive ProjectA. There's no financial incentive for ProjectA to think long-term. (And if ProjectA is thinking long-term, then STOP THINKING LONGTERM!! A huge amount of code is short-term glue logic with bad specifications). Aligning your technical goals with your soft-managerial goals is key to survival.
- kjeetgill 6y agoI'm not sure what you're finding harmful when it sounds to me like you're agreeing. Your "library code" (or library-esq elements) is the code that you find needs to be tested more heavily, because it is library code? I don't thing whether it's packaged separately was key to that, but it can help.