Live data from Hacker News

On navigating a large codebase

blog.royalsloth.eu

111–120 of 139 posts

Re: On navigating a large codebase

#111
post #80

Earlier quoted context omitted.

That's basically been my job the last five years. As soon as I joined the company (a scrappy startup of 30 people), I started refactoring large portions of mission critical code prioritized mostly by how terrified other coworkers were of touching it. In the beginning, folk were rather skeptical, but now that the company has grown by an order of magnitude, my earlier work has apparently become a topic of folklore in o…

> If I break something, it usually means it wasn't built strong enough to begin with. I've broken a lot of stuff over the years... Based on my experience, this statement scares me :) Not to pass any judgment on your impact or abilities, however the types of devs that have been the most challenging for me to work with are those with this attitude that aren't quite as good as they think they are. It can be incredibly t…

Certainly you want a refactoring effort to improve reliability and maintainability rather than harm them. I am a strong proponent of writing an "architecture document" before touching code to do anything but patch a straight forward bug, and soliciting feedback on it long before code review. This is precisely what develops that holistic view you mention. One of the first things I tackled in this codebase was to introduce abstractions to enable unit testing of code that was previously considered not unit testable. As the team has grown, we've developed processes to ensure that everyone explicitly considers risks and how to mitigate them whenever they make a code change.

I also agree with you that it's best to be pragmatic when it comes to developing software for a business. Code that's ugly but works is perfectly fine. When it no longer works one day, patching it to keep the lights on is the right course of action. When the same ugly code breaks over and over, though, it's time to solve the root of the problem. Sometimes there's inherent risk in doing that, and things break; it's necessary to do it for the long term good, though.

I try to write code that doesn't need to be touched again, but is pleasant enough to dive back into should you inevitably need to extend or debug it. I also try to reuse existing code and improve it as needed rather than create what I call "parallel codebases". I try to mentor my coworkers to do the same. If achieved, then it's a huge productivity multiplier.

I think I'm pretty easy to work with. I am confident in my abilities as a software engineer, but I'm also relatively modest. I try to respect work that was done before me and carry the good parts forward if it ends up needing refactoring. I prefer to let less experienced coworkers tackle problems similar to problems I've solved in the past while providing mentorship, so that they can learn similar lessons. I've avoided management because I know I'm bad at it, but I try to support management however best I can. I also throw the occasional team homemade pizza party when there aren't pandemics. Notably, I also tend to be able to work with the stereotypical difficult-to-work-with devs that you mention. My coworkers generally seem to say nice things about me to my face and behind my back, and upper management seems to reflect their appreciation financially. Honestly my biggest interpersonal problem at work right now is that newer employees seem to hesitate reaching out to me for fear of wasting my time. Therefore I try to make it known that I spend as much time staring at the wall as possible during work hours.

Re: On navigating a large codebase

#112

Well, that's a surprise for sure. I wrote this article a few months ago and it gained no traction. Today I woke up and boom, front page.

I really connected with the writing. Thank you for taking that time.

There is a lot in my current context the writing resonates with. Nice to find that others have been on this path too, and that we benefit from a lot of the same techniques.

Thanks for putting this out there as an invitation to draw people together.

Re: On navigating a large codebase

#113

Earlier quoted context omitted.

That's basically been my job the last five years. As soon as I joined the company (a scrappy startup of 30 people), I started refactoring large portions of mission critical code prioritized mostly by how terrified other coworkers were of touching it. In the beginning, folk were rather skeptical, but now that the company has grown by an order of magnitude, my earlier work has apparently become a topic of folklore in o…

Is this Jeff Dean ?.

Lol, maybe the crappier Arduino version. My name is Jeff though.

Re: On navigating a large codebase

#114
post #68

Earlier quoted context omitted.

> good code is self-documenting I still believe this to be more or less true. The important part there is that you have to write good code though.

So, the advice is bad, as most people (including myself, no doubt), will write mediocre code, just by the shape of the distribution (assuming it's normally distributed, which is a strong assumption, but without data it's probably reasonable). Advice that relies on people caring about their craft/having the skills to do the work well doesn't scale, so it's bad advice where those things aren't true.

You come a long way with avoiding direct calls in "if" clauses and similar, using descriptive variable names, and not trying to be clever for the sake of being clever.

For example, instead of

    if (order.version > 1) ...
assign it to a descriptive variable

    bool orderHasChanged = (order.version > 1);
    
    if (orderHasChanged) ...
IMO this makes it much faster to read and understand, because it says something about the intent. It can also be easier to spot bugs.

It's a bit more to write, but I find it makes a big difference when coming back to the code later on, and typing is usually not the limiting factor when writing code.

Re: On navigating a large codebase

#115

This is one of the big reasons I prefer static typing. When looking at some unfamiliar code in an unfamiliar codebase, I can reason about the code much faster when I can see what functions return, and quickly go check their types out if the type is unknown. This makes me much more productive. I helped maintain a 250kLOC Python program. I came in when it already at over 200kLOC. I spent so much time , every time, just…

250kLOC Python sounds scary. But that would easily be 1mLOC+ lines in Java ...

I'd much rather have a million lines of Java. And I'm not a huge fan of Java.

It can be a bit tedious going down the AbstractWidgetInterfaceFactoryFactory rabbit holes, but at least I have a fighting chance.

Re: On navigating a large codebase

#116
post #41

Earlier quoted context omitted.

If you read/scan 10 lines a second, you still need over 24 hours non-stop to read a 1M+ code base. I doubt a random file ordering is helpful! Especially if you lose code navigation features like "go to definition".

You'd be surprised. Suppose I want to "go to definition" for a class named Saver. /^class Saver\> 19 times out of 20, this works. It's also instant; my vim will likely get me there faster than your IDE's go to definition functionality. (Looking at you, pycharm!) Here's my flow. >>> import tensorflow as tf >>> tf.train.Saver >>> from tensorflow.python.training import saver >>> saver Then I open /usr/local/lib/python3.…

How do you handle finding occurrences of a specific variable with the same name as another one? Simple text search has the power equivalence of a dull butter knife.

Re: On navigating a large codebase

#117
post #96

Earlier quoted context omitted.

i do something similar but with tags and without the merging. vim's tag navigation is very powerful. split a window with the target tag and see side by side the class and its descendant for example. i use `venv`s for every project inside the project folder so uctags also generates tags for all libraries installed and i can "drill all the way up" to classes and definitions. it's also possible to have the system librar…

i use `venv`s for every project inside the project folder so uctags also generates tags for all libraries installed and i can "drill all the way up" to classes and definitions. it's also possible to have the system libraries show up in the tag database, it's just a matter of telling uctags which path's, files to include/exclude or alternatively use another tag file for that, vim can use multiple tag files. Oh? Yours…

I use pycharm and as long as I set the virtualenv I'm using as the Project Interpreter in Preferences it lets me "drill down" to the library code as well

Re: On navigating a large codebase

#119
post #34

The article describes pretty much what I’m facing at my job. We have a monolithic Ruby on Rails application with lines of code in the millions. Still we general mantra is that comments are not allowed and I can only agree with the author that this makes non standard parts of the code extremely hard to comprehend. I would definitely love to work once on an application that size with a few comments here and there. In m…

How to you write your commit messages? For us in most projects there's a git hook that forces you to put the jira ticket number in the commit message (and the branch). So if you have to know why a change was made you at least a context of what the task was, which helps.

Re: On navigating a large codebase

#120

Earlier quoted context omitted.

250kLOC Python sounds scary. But that would easily be 1mLOC+ lines in Java ...

I'd much rather have a million lines of Java. And I'm not a huge fan of Java. It can be a bit tedious going down the AbstractWidgetInterfaceFactoryFactory rabbit holes, but at least I have a fighting chance.

To each his own...
Post reply on HN