4 ms·
Do people find Martin Fowler and his peers' work to be good in real world? I'm a system/application architect who spent years coding. I used to read books by Ma
by aynyc 7y ago
Do people find Martin Fowler and his peers' work to be good in real world? I'm a system/application architect who spent years coding. I used to read books by Martin Fowler and others religiously. But now, I realize most of the books and talks are really just fluff pieces because the examples worked in perfect condition, where as my experience is from the battle field.
As far as getting good at designing big and complex application, I'll give what I know.
1. Everything complex came from a small system. So make sure your small application works first. Twitter/Google/Facebook didn't get to what they have now on day 1. They failed a lot to get here.
2. Designing monolithic system is a lot easier than micro services.
3. Read a lot of codes and how different component interact with each other. For Python, projects such as Scrapy, Flask and Django are good example to start.
- auspex 7y agoI find the concepts he makes you think about are helpful. Think through the big problems and make sure you keep them in mind as your are coding the subsystems. Make sure any code you write could be used by another system in case you need to break it apart later. Make things pluggable though interfaces. No global references.
- BlargMcLarg 7y agoHonestly, I found most books are written more as a basis for people who need something to hold onto and can't do it on their own (yet), and for people to understand the ridiculous enterprise systems. Most of the time, I see good developers take longer to come up with various structures and deciding which one to go for than the time they'd spend fixing these things afterwards. On the other hand, inexperienced devs will trip up no matter what. That's why they are inexperienced, give them a chance and some time. Realistically, good systems are built by good devs who understand you need to continuously maintain and evolve the system according to your needs, and keep an eye on relatively simple things like method structures while doing so. Its easier to refactor when all your methods name themselves, are bite-sized in what they do and you provide a sandbox for other people to work in, or a blackbox for them to work with. And clear errors. Don't be that guy who hides the stack trace and doesn't keep track of the state of the app. Please don't.
- rochak 7y agoThanks! Iteratively improving and adding features seems the most natural way how a software matures or ‘becomes complex’. I guess I just have to start building something small and learn how to add features that require learning a new concept.
- aynyc 7y agoYour first step should be avoid complexity. Reject features (big or small) that don't add value to the system. And if you must add feature, try to make it as specific as possible. Generic features tend to get abused. I personally don't like it, but other do love it.
- rochak 7y agoI agree. Too much generic features end up becoming abstract and make it difficult to find what the original purpose was.
- godshatter 7y agoI would add to this that you shouldn't be afraid to refactor when you hit a wall where you can't add the feature you want to add because of the way the other features structured your code. Better to take the time to modify the basic structure a bit to make it work than to try to kludge something together to sort of make it work. You'll find that doing it right allows other features to be added that you haven't thought of yet. If you somehow force it to sort of work, you'll end up doing that for a lot of other features, too.
- rochak 7y agoNow that I look back, that is how I have approached developing systems and it certainly makes a lot of sense.
- gentleman11 7y agoI learned about Phoenix servers and some other topics from Fowler and it was valuable for me. I can’t speak to his bigger works