Ask HN: What book will make me a better big project programmer?
16 comments
I hope someone has better advice for you, but in my experience (30+ years programming, 25+ professionally programming) I could not imagine a book that could teach that. I need to have a ‘seen it all before’ feeling and that is usually the case. There is also just really really bad code (100k+ old php, millions of lines of ‘optimized for performance’ Java) which I thrive on not because I saw the structure before, but I saw a lot of code rot and I am efficient in managing/altering it; it is a common reason for people to hire me to consult; they inherited a codebase that makes the team burn out and ask me to come, analyse and explain to the team what to fix to make it less crap.
What did you do before this? Because Java projects are usually overarchitected but so are many OO projects in other languages. Many times it started with a clean design pattern (which was already often a bad idea but it fit) and then got a million things bolted on over time.
Again; hope someone has better advice but it sounds like you got some bad code there and that might or might not be repearable. 100k is not so much, especially in Java, but way too much for a rewrite so personally I would disappear for a week with the codebase to see what can be done and then suggest doing it or, if it turns out really bad and there is no funding/understanding for fixing it, look for another job.
What did you do before this? Because Java projects are usually overarchitected but so are many OO projects in other languages. Many times it started with a clean design pattern (which was already often a bad idea but it fit) and then got a million things bolted on over time.
Again; hope someone has better advice but it sounds like you got some bad code there and that might or might not be repearable. 100k is not so much, especially in Java, but way too much for a rewrite so personally I would disappear for a week with the codebase to see what can be done and then suggest doing it or, if it turns out really bad and there is no funding/understanding for fixing it, look for another job.
Martin Fowler’s website is a cornucopia of patterns that are conducive to gradually improving the architecture of large, sprawling codebases. Take
the strangler pattern, for instance: https://www.martinfowler.com/bliki/StranglerApplication.html
Any useful suggestions necessarily will have to remain at a pretty high altitude, though, simply because no two large applications are completely alike.
Other than that there are a few general principles and guidelines you might want to follow:
- the Boy Scout Rule: When you’re working on a particular piece of code and you see something weird or overly complex try to clean up the code. Start small while doing so. Don’t try to refactor everything at once.
- Before refactoring or otherwise introducing significant changes try to write unit tests that ensure the previous, expected behaviour still is present when you’re done with your refactoring.
- Having inherited a Java codebase (i.e. one written in a strongly rather than weakly typed language) probably will prove to be a boon further down the line. If you break something many errors will show up immediately during compilation and not just once the application is in production.
- This allows you to refactor relentlessly and make full use of the refactoring features of an advanced IDE such as IntelliJ IDEA.
Speaking of tools: You’ll want the best tools available to help you with this daunting task, i.e.
- state-of-the-art CI / CD
- IntelliJ IDEA Ultimate licences for every developer (or whichever IDE you prefer, just don’t try to be cheap at the expense of productivity)
- an automated code quality checking and code exploration tool such as SonarQube.
Any useful suggestions necessarily will have to remain at a pretty high altitude, though, simply because no two large applications are completely alike.
Other than that there are a few general principles and guidelines you might want to follow:
- the Boy Scout Rule: When you’re working on a particular piece of code and you see something weird or overly complex try to clean up the code. Start small while doing so. Don’t try to refactor everything at once.
- Before refactoring or otherwise introducing significant changes try to write unit tests that ensure the previous, expected behaviour still is present when you’re done with your refactoring.
- Having inherited a Java codebase (i.e. one written in a strongly rather than weakly typed language) probably will prove to be a boon further down the line. If you break something many errors will show up immediately during compilation and not just once the application is in production.
- This allows you to refactor relentlessly and make full use of the refactoring features of an advanced IDE such as IntelliJ IDEA.
Speaking of tools: You’ll want the best tools available to help you with this daunting task, i.e.
- state-of-the-art CI / CD
- IntelliJ IDEA Ultimate licences for every developer (or whichever IDE you prefer, just don’t try to be cheap at the expense of productivity)
- an automated code quality checking and code exploration tool such as SonarQube.
Algorithms and datastructures form the tactics of software development. your question is related to its strategy. Before you can master it, you first need to learn the concepts that are involved there. Don't buy books on methodologies, they are snake oil (I would love to be proven wrong by HN).
The one book that stood out for me was this one:
Component Software: Beyond Object-Oriented Programming (Clemens Szyperski) https://www.amazon.com/Component-Software-Beyond-Object-Orie...
It's not a guide on how to do it, but it explains the ecosystem and forces in play (like why good components get rewritten, while bad ones persist). Once you understand these things you will have a better compass.
Component Software: Beyond Object-Oriented Programming (Clemens Szyperski) https://www.amazon.com/Component-Software-Beyond-Object-Orie...
It's not a guide on how to do it, but it explains the ecosystem and forces in play (like why good components get rewritten, while bad ones persist). Once you understand these things you will have a better compass.
Effective Java by Joshua Bloch is probably the best book for starting to work with a large codebase, supplemented with course notes from any software engineering intro course like https://www.cs.cmu.edu/~charlie/courses/17-214/2018-spring/i... if new to Java. SEI CERT has some recommendations too you can adapt to whatever version you're using at work https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Or...
I second Effective Java. It's an advenced/master level guide to write good java code. Some of the subjects are outdated as it is so engraved in Java that probably a tool does it for you(eg. dependency injection) but really helps to get the big picture if you are an experienced developer but new to java.
To work with legacy code I recommend Working with Legacy Code by Martin Fowler. Lots of good ideas for handling messy codebase are described there.
To work with legacy code I recommend Working with Legacy Code by Martin Fowler. Lots of good ideas for handling messy codebase are described there.
Learn to use the debugger and read code commit history. And talk with your team-mates. In the last few months, as a student working part-time (< 20hrs/week), I am on a PHP codebase with over 5 million LOC and 15 years of work, and I was pretty good with dealing around it within a month. There are lots of dependencies like you mentioned and at least three different "eras" of code frameworks and hardly any documentation. I had not touched PHP in any capacity before this for at least 3 years. I admit PHP is easier to read and reason than Java when afresh but those three things made me really fast to be productive and making independent production-ready features.
Hm never thought about reading commit history. I’ll try it.
“Software Systems Architecture” by Rozanski
Basically, it’s not about the code. It’s about the form following the function. That is, first, deeply understand the context and purpose of the software, and the structure will follow.
I also recommend “Domain Driven Design” by Evans. But, a warning - it’s dry. There are a lot of “DDD in Java” code examples out there.
You could go back amd re-read “Code Complete”, and other early Microsoft Press books. Though, some are probably dated.
The Robert Martin books can be also useful, at least in thinking about how to maintain low coupling, high cohesion.
Oh, and “Working with Legacy Code”
Unfortunately, none are specifically Java related. How to structure systems is an art that requires practice. So, maybe start off with some small toy projects, just to get warmed up.
Basically, it’s not about the code. It’s about the form following the function. That is, first, deeply understand the context and purpose of the software, and the structure will follow.
I also recommend “Domain Driven Design” by Evans. But, a warning - it’s dry. There are a lot of “DDD in Java” code examples out there.
You could go back amd re-read “Code Complete”, and other early Microsoft Press books. Though, some are probably dated.
The Robert Martin books can be also useful, at least in thinking about how to maintain low coupling, high cohesion.
Oh, and “Working with Legacy Code”
Unfortunately, none are specifically Java related. How to structure systems is an art that requires practice. So, maybe start off with some small toy projects, just to get warmed up.
The Pragmatic Programmer might be useful from an angle of what not to do, and has a good amount of wisdom with regards to refactoring. It's also quite pleasant to read, less technical, more on general patterns to learn from.
I'm reading Refactoring JavaScript by Evan Burchard. While you are focusing on a "java" codebase, this book has general tips and suggestions that are languange independent. It's quite good about going through various code patterns and how to refactor them.
Well, why not the original Refactoring, as it's more OOP-oriented, and actually has Java examples. Fowler's website, as has been mentioned already, has a lot of his refactoring-type material online. https://refactoring.com/catalog/
Write unit tests as you go. Use a tool to print the dependency class graph: http://www.dependency-analyzer.org
Read the code itself first
Yeah, that’s my main priority, but I like to read outside of work hours.
I have 10 years of experience, but I’m new to Java. Which book should I start with that will help me make the code better for everyone?