Learn to use grep well.
Ask HN: How to be productive with big existing code base
151–160 of 187 posts
Re: Ask HN: How to be productive with big existing code base
#152Do they have good test coverage? That's key. If they don't, start with that.
God no, I've seen two code bases where this happened and each time the tests were rubbish because they didn't understand the domain.
Plus the clients both rubbished those developers because they didn't get anything done, so that's a surefire way to get a bad rep as a freelancer.
Re: Ask HN: How to be productive with big existing code base
#153My #1 rule for existing codebases: Just because you wouldn't have done it the way they did doesn't mean they did it wrong. I think it's developer nature to look at a huge pile of code that someone else wrote and immediately think: "This is a pile of crap. I can do better, so the first thing to do is rewrite all of this, my way (which just so happens to be _The Right Way_)." Figure out what you're trying to do, and wh…
It's developer nature to look at any code and think that -- especially your own! Or if you prefer the abstraction, perhaps to consider that "myself 3 months ago" is a different person than "myself today".
Every time I've gazed upon a new legacy codebase and said "This looks like junk", the system architect responded "Yes -- that's why you're here!"
Re: Ask HN: How to be productive with big existing code base
#154Earlier quoted context omitted.
I don't see how that's a counterpoint. Chesterton doesn't say "don't change it, that's how it is and shall be." He's saying, "Question why it's present before you attempt to change it." Looking around, there were no obvious livestock or other reasons for the fence. But perhaps they're only there six months out of the year. Ok, make the fence a gate, and not a fence, so it can be opened more easily. Maybe it's no long…
Usually there is nobody to ask though, and if you're refactoring a mess then the code won't give you a clear answer. The only way to find out if the was a reason the fence is there is to remove it and see what goes wrong which is what you were going to do anyway.
Actually, the right place to ask is the unit tests or integration tests. Though there seems to be an inverse relationship between the code that needs refactoring and the prevalence of proper tests.
Re: Ask HN: How to be productive with big existing code base
#155Some of my rules for a big legacy code base:
- don't plan or do a full rewrite - it'll almost never work
- learn and use tools to automate the build system and quality assurance (jenkins, sonarqube, docker, git, etc.)
- take the time to improve your skills and the skills of your team (coding dojos, experiments)
- write automated tests (unit, integration, acceptance) for existing code where ever possible - write at least unit tests and integration tests for new code
- do refactoring and first focus on cross cutting concerns (APIs, translations, caching, logging, database, etc.)
- migrate things to well tested isolated APIs (e.g. use REST / Graphql APIs with new endpoints in the frontend and try not to use untested code for these APIs)
- don't be too backwards compatible (move fast and break things)
Hope it helps ;)
Re: Ask HN: How to be productive with big existing code base
#156Earlier quoted context omitted.
Nice! I'm working on internal tooling for us that does a lot of the same things - gonna buy the book, thanks for that, weird I've never heard about it. For now I'm measuring: churn, complexity, linting, test coverage, test quality and am going to add a dependency graph. It seems to me that churn, complexity and dependencies are the biggest indicators of a hotspot. Got any tips for possible problems I'll encounter alo…
Cool - thanks! While the measures a simple in theory, there are some practical challenges; git repositories tend to be messy. So part of the practical challenge is to clean the input data (e.g. filter out auto-generated content, checked in third party libraries). Another challenge is that version-control data is quite file centric, while many actionable insights are on a higher architectural level. In CodeScene we so…
I'm already onto data cleanup, tbh I'm focusing on Android repos for now. But great idea, now that I think of it as an architect I'd mostly like the option to group a few classes/packages or let's call them "modules" together and then visually see which pieces are too dependent on outside sources and which are the hotspots/connections/dependencies inside that group.
There goes my weekend...
Re: Ask HN: How to be productive with big existing code base
#157Earlier quoted context omitted.
There's a term for this, Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence > let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly w…
With statically typed languages, you can do guaranteed safe, automated refactors. I’ll do those mercilessly without tests. I would be very wary of refactoring dynamically typed language.
I've broken code in Java because I inlined a private method as part of a refactor. I found out later that some other code was accessing it through reflection. Fortunately that other code was an old test, instead of production code, so when it started failing on the test automation servers I found out about it and could update the test to not do that. Then I did what I do frequently anyway, regardless of dynamic or static typing, which is to use ag[0] and increase my confidence there weren't any other surprise references. Of course there's always the possibility of some sadist splitting the method name into two strings and concatenating them later, ag's no guarantee either.
If you've ever done a partial build system you can also break downstream dependencies you didn't know about from even compiling, and not know about it until you try to integrate. (I've done this too, fortunately the integration happens as a gate to checking into the main code branch.) If you at least keep the source of everything locally, even if you don't build it, ag can help again.
My only point here is that static typing isn't enough if you're prone to fear-driven development; you have no guarantees, just things that increase confidence. Static type proofs are but one way to increase confidence. I'm happy Fowler decided to use JS for his second edition, since this particular line of FUD when it comes to there being some impedance mismatch between dynamic languages and refactoring is unmerited. The first auto refactor tools were made for Smalltalk, a dynamic language, after all.
To me the two keys to safely (at high confidence) doing any refactor are to first know what you're doing (and what a tool is doing if you're using one, I'm all for pushing for better tools) and second to do it in small bits with a tight feedback loop. As part of the loop after you make a change you use whatever methods (compiling for static type proofs, running tests, manually testing (REPLs help this a lot), sometimes just pure reason) to become sufficiently confident that you didn't break anything. Sometimes you still break things, as part of a refactor or just as part of regular development -- every bug filed is one that got past all of your reason, your compiler, and your tests, but don't let that fear drive you.
[0] https://github.com/ggreer/the_silver_searcher There are other tools too. Regardless of language, writing "grepable" code promotes a lot of nice qualities, not just easing refactoring.
Re: Ask HN: How to be productive with big existing code base
#158I’d say the most important thing is to learn the domain and the business you are working with. Never assume the code is doing things the right way for the business. Get to know your client really well and try to understand what they need to software to do. Keep them in the loop as much as possible.
This should be the best course of action before diving into technical aspect. Look for any updated business documentations. If there aren't any, ask the users of systems to find use cases and replicate them in dev system. Try to document the business flow and emulate any hidden behaviors. Last, open the codebase and matching business process with code, and comment everything possible.
Then you can begin fixing or refactoring with use cases / test cases in hand. If time isn't possible for that, try to shift the responsibility to the one giving you task (pm).
Re: Ask HN: How to be productive with big existing code base
#159Some of my rules for a big legacy code base: - don't plan or do a full rewrite - it'll almost never work - learn and use tools to automate the build system and quality assurance (jenkins, sonarqube, docker, git, etc.) - take the time to improve your skills and the skills of your team (coding dojos, experiments) - write automated tests (unit, integration, acceptance) for existing code where ever possible - write at le…
These text boxes are not great...even on my 4k monitor I have to click the scroller at the bottom to see 1/2 of your longest bullet points; must be even worse on mobile. Better to just write it in plain text instead of a box.
Re: Ask HN: How to be productive with big existing code base
#160Earlier quoted context omitted.
I'd also add here that hindsight is 20/20. You don't really know what you're creating until it's created. Do it again a second time when you know exactly what you're getting at the end, alongside the challenges you'll face in the process of such, and you'd be able to do it faster, cleaner, and just overall better.
Intuitively, I often feel the same. Joel Spolsky argues against that: https://www.joelonsoftware.com/2000/04/06/things-you-should-... The Mythical Man-Month as well: https://en.wikipedia.org/wiki/Second-system_effect
[deleted]