"So, basically, I would not start optimizing for theoretical modularity nor performance without actual issues or requirements."
And you are right. Because you don't need it, apparently.
On our side we have requirements for performance and scalability.
With the experience, you know what works and what don't.
So yes when I think about a multi person product I think dozen, hundred, not 3-6. Sure each team/project maybe 1-10 persons, but you may have 20 at the same time.
When a product is successful there, it means it is used wordwide by millions of end users. We need to be able to serve the internet. 10% decrease in performance means several millions euros for the machines, the electricity and so on.
That's the biggest issues of advices, what works, what not. But what are the circonstances ?
For you, all that fuss would make you less productive because you are a small team and there no req. for performance. You don't need modularity because the code base is small. For my company, your methods would work for a prototype, no more.
For a company like airbus or thales that design auto pilots au make lot of embedded devices software, your methods of mine would make absolutely no sense. Each line of code is validated and revalidated. The same product has several implementation running at the same time by different teams and languages so that if one autopilot fail, the other one can be used instead.
For many startups and geeks, using Java and so on would again make no sense. They would do it in haskell or lisp and would go 10 time faster than you, 100 time than my company.
That the whole argument about theses thing. Nothing absolute.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"So, basically, I would not start optimizing for theoretical modularity nor performance without actual issues or requirements."
And you are right. Because you don't need it, apparently.
On our side we have requirements for performance and scalability.
With the experience, you know what works and what don't.
So yes when I think about a multi person product I think dozen, hundred, not 3-6. Sure each team/project maybe 1-10 persons, but you may have 20 at the same time.
When a product is successful there, it means it is used wordwide by millions of end users. We need to be able to serve the internet. 10% decrease in performance means several millions euros for the machines, the electricity and so on.
That's the biggest issues of advices, what works, what not. But what are the circonstances ?
For you, all that fuss would make you less productive because you are a small team and there no req. for performance. You don't need modularity because the code base is small. For my company, your methods would work for a prototype, no more.
For a company like airbus or thales that design auto pilots au make lot of embedded devices software, your methods of mine would make absolutely no sense. Each line of code is validated and revalidated. The same product has several implementation running at the same time by different teams and languages so that if one autopilot fail, the other one can be used instead.
For many startups and geeks, using Java and so on would again make no sense. They would do it in haskell or lisp and would go 10 time faster than you, 100 time than my company.
That the whole argument about theses thing. Nothing absolute.