Programs should be Small
mkhadikov.com
Programs should be Small
1–10 of 75 posts
Re: Programs should be Small
#2he's talking about adding a lot of "moving parts"...
Re: Programs should be Small
#3This is probably another way of saying Service Oriented Architectures (SOA) works best for the enterprise. They probably already know that we should have all functionality in coarse, self-contained services.
But often the plumbing required in the form of web services becomes really painful to leverage. For instance they require creating complex WSDLs and workarounds to prevent timeouts.
Re: Programs should be Small
#4A good program is 500 lines or less.
Re: Programs should be Small
#5SOA is somewhat different to the "microservice" design it seems this author is proposing. I summarised what I could find on this - ideas from James Lewis at Thoughtworks, Dan North at DRW, and Fred George at Forward - in a recent CITCON session: http://www.citconf.com/wiki/index.php?title=Continuous_rewri...
Re: Programs should be Small
#6The problem is that software has a tendency to become complex. The proposed solution is to break up the software into smaller programs.
There are certainly advantages to having smaller components. It allows you to rewrite components in a different language should you want to, for example. But there are disadvantages to: smaller components means dealing with failure at a much finer granularity.
In my opinion, the reason large programs become complicated is that there has been no emphasis on simplicity. Breaking components into smaller pieces forces you to adopt robust interfaces, but there are better ways of creating simpler programs.
My personal approach is to reason about parts of a program in terms of what they mean rather than what they do. I also have a strict rule that says, "don't change the meaning of a component, create a new one". This methodology works for me.
Re: Programs should be Small
#7Microservices are not necessarily bad, but one should also be aware of the drawback of such an approach. If there is a very tight coupling between two modules, you will often find yourself having to keep making changes between 2 different modules. The typical process goes like this:
1. While working on module 1, you realize you need something from module 2
2. Open module 2, add new feature and publish changes
3. Go back to module 1, test new feature and resume work
This process is fine once both modules 1 and 2 have matured but painful to deal with while the APIs are still taking shape. Hence it makes sense to keep a good abstraction between potential components and spin them off as an individual service only when they're stable enough.
Re: Programs should be Small
#8A good program is 500 lines or less.
I type at least 60,000 characters before inserting a line break.
I joke, but I've seen some php before that was at least 600 chars before line breaks, I have no idea how they wrote it like that.
Re: Programs should be Small
#9This is probably another way of saying Service Oriented Architectures (SOA) works best for the enterprise. They probably already know that we should have all functionality in coarse, self-contained services. But often the plumbing required in the form of web services becomes really painful to leverage. For instance they require creating complex WSDLs and workarounds to prevent timeouts.
SOA is great, people in Java EE world use it wrong.
Instead of making small isolated services they do one single gigantic WAR file.
Instead of using right tool to do the job everything is written in Java.
Instead of having services with implemented business logic they do services that convert one DTO to another.
That sucks...
Re: Programs should be Small
#10A good program is 500 lines or less.
Wow, it seems rather arbitrary. Can you elaborate?