You can't really. Especially in JavaScript world where velocity is everything. You'd spend at least ~1 year if it is really large and hit all kinds of hacks in the form of callbacks within callbacks within callbacks that are tuned in a way that (mostly) works. I'd recommend you to run away, seriously.
Ask HN: How to be productive with big existing code base
161–170 of 187 posts
Re: Ask HN: How to be productive with big existing code base
#162It depends. Number one, find out if the codebase is bad or just big. This will take a few months, so I try to keep my mouth shut for a while. If it's really that bad, build a world in a teacup. Try to make one small new area of code that's nice and slowly work existing code into it whenever you get the excuse. It's very unlikely they'll allow you to rewrite or even make substantial changes to existing code. If it was…
> Once you have typescript up and going, pull in some add-ons to make Node work with async code.
Maybe I am confused about the intent of your comment, but NodeJS works with Async code all by itself so long as you use a recent version, such as v.10+.
Callbacks are indeed hell, but you can avoid them by using Promises, Events, and Async/Await all without having to "pull in some add-ons". Furthermore if you use an event queue like Kafka or RabbitMQ and avoid shared global state it's possible to scale NodeJS horizontally quite nicely.
My comment here doesn't seek to denigrate TypeScript, nor defend NodeJS's limitations for building large systems with large teams, but to highlight that asynchronous code execution is quite a good fit for NodeJS when managed well. It is true that using observer patterns like RxJS can improve that even further, but they aren't required to achieve sanity.
Re: Ask HN: How to be productive with big existing code base
#163My #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…
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…
Ok, but seriously I am genuinely curious, what is the reason for the fence in the picture? I see fences like this when I am out in the mountains camping or hiking. Is it to prevent some type of animal from roaming down the roads?
Re: Ask HN: How to be productive with big existing code base
#164Some 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.
Thx for the hint... edit done :-)
Re: Ask HN: How to be productive with big existing code base
#165Earlier 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…
Ok, but seriously I am genuinely curious, what is the reason for the fence in the picture? I see fences like this when I am out in the mountains camping or hiking. Is it to prevent some type of animal from roaming down the roads?
Every fence might be different! Clicking on the picture gives a description of that particular one's history. When I see fences/gates on forest service roads or access roads I presume one reason for them is to limit access. Roads require maintenance, having fewer vehicles driving over one means less maintenance. During winter season a fence could also be there to limit access for the purpose of reducing the need for search & rescue or towing services...
Re: Ask HN: How to be productive with big existing code base
#166Never try to refactor everything. Sometimes logic may look like it was implemented incorrectly, but from my experience it may have been written like this on purpose. Business logic can be really twisted. Also remember about scout rule: "Leave Things BETTER than you found them.". It will help you to slowly, yet steadly improve the codebase.
> Never try to refactor everything
That's certainly true when you have a working product that just needs incremental work.
When you inherit something that doesn't work, then you really do need to refactor "everything." Most likely, problems arise from incorrect low level assumptions or design decisions.
What do I mean by quoting "everything?" This is the kind of refactoring that feels like you're refactoring everything, but in reality, you're still keeping higher-level assumptions and design decisions.
In this case, if you don't refactor away the mistakes that lead to something that doesn't work, then you'll never have something that works.
(BTW, I know this from personal experience, I had to refactor a shipping product shortly after starting the job because the shipping product did not work. Now I'm the lead architect on the product.)
Re: Ask HN: How to be productive with big existing code base
#167Unit tests / automated tests are critical.
If you're lucky, you will have a suite of unit tests and automated tests with high code coverage. Rely heavily on these tests as you refactor and debug.
If you don't have working tests, consider writing them before making any major change.
Re: Ask HN: How to be productive with big existing code base
#168Read a lot of code!
Spend time reading code in the codebase even if it doesn’t seem to make sense, even if you don’t think you’ll need to know that part of the code. Keep reading until it starts to make sense.
My trick has always been to just read. I even avoid tools that automatically navigate the code because I like to just read it until I know where things are.
Re: Ask HN: How to be productive with big existing code base
#169Earlier 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
It's worth mentioning that what both of these are talking about are rewrites using a new project in a all or nothing stake. Iterative rewrites are not subject to these caveats.
Re: Ask HN: How to be productive with big existing code base
#170This book is pretty great:
https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...