6
17 Comments

"What do I do with all this code!?"

Fellow developers, asking for your insight. For the product we working on I need to understand how often do you find yourself staring at complicated code, trying to understand how it works.

  • What do you do when you faced with it?

  • Any tools you use to help yourself?

  • Does it happen more often at your work or on your personal pursuits?

Thanks for your help guys
SourceSpy

  1. 2

    One of the easiest ways to understand code is to check the unit/integration tests if you're lucky and the dev actually created them.
    In cases where there are no tests my biggest recommendation is to start adding comments yourself as soon as you identify or clarify what the different pieces do, update the readme file with everything you learn, create a postman collection and add it to the repo.... basically document all you learn. It be super helpful for the next person that checks that code 😉

    Hope that helps

    1. 1

      Thanks, very useful!
      Did you ever see any diagrams/visualizations that help you understand the code? I'm very curious if there are any examples that make code structure and logic clear.

      1. 1

        I've Im trying to understand a big block with multiple microservices, most of the times I end up doing a diagram with pen and paper (actually I have 3 in my desk right now). One of my team mates takes pictures of them with an Ipad, add some notes and shares them in our Confluence, which is also very helpful for the rest of the team.
        At the end of the day, it all comes down to having proper tests and documentation. In our team we've make sure those are part of our acceptance criteria and nothing is finished until everyhing from it is done.

  2. 2

    Just debug and unscramble. By the way, your site not opening after a lot of time.

    1. 1

      Yeah, that's my miserable life as a developer. But there should be a better way!
      And thanks for the site note, works now.

  3. 2

    My previous job as a python backend developer entailed looking at lots of "legacy code". My employer brought on a rotating cast of contractors, who would more or less do their own things before they left. This often put the handful of full time employees in the position of figuring out an entirely new section of the code base, without having access to the original author. I estimate that I spent at least 80% of my time working through old code.

    The first things I did when looking at a new part of the code base was to use git to find out:
    (a) who wrote a section of the code, and
    (b) the date that changes were made

    The thinking behind (a) was that different people have distinct coding styles. If I was cognizant of who had written a piece of code, then hopefully I could recognize recurring patterns that would help me understand their thought process in the future.

    The rationale for (b) was to try and tie the commit dates back to what the team, and specifically that person were working on at the time (I tried to keep notes from our daily standup meetings). Were we under intense time pressure to pump out a new feature, or was it a relatively slow week? This could influence how much the person was focusing on writing for maintainability at the time.

    I also looked for any libraries used that I was not already familiar with, so that I could bookmark the documentation. I used Kite to look up documentation in my editor (Atom), but liked to have the "long form" documentation on hand.

    I usually found myself creating a throw away branch and writing comments for myself explaining what sections of the code did.

    The team used gitbook for documentation, but writing documentation was not enforced by management, so in practice, it was rarely done. I wanted to take time to set up Sphinx to auto generate our api documentation, but could not convince my manager that it was worth the time investment.

    The above applies to my work situation. I could also see it applying somewhat to large open source projects, but it might be easier to get a hold of the original author in that case.

    1. 1

      Immensely useful feedback. Thank you.
      Related question, if you have another minute. If you could magically create visualization of the the code repository (diagrams/charts/...). What type of diagram would you want to see?
      Thanks again!

      1. 2

        I think it would be useful to visualize the extent to which modules of a project are coupled. Even a graph linking method invocations and class instantiations in one file back to the file they were defined in could be potentially helpful.

        It might also be useful to visualize which files contain complex code, using some measure like cyclotomic complexity, and which files depend on these files. I could see that at least pointing developers in the right direction when they are looking for a bug in a large system. It could also be helpful for developers looking to convince non-technical managers that maintenance on a certain section of the codebase is justified.

        1. 1

          Haha, its almost worth to be a whole separate problem to solve - convincing mgmt to spend resources on tech depth and maintenance.
          Great information. Thanks for your help!

          1. 1

            No problem. Best of luck to you!

  4. 2

    I think I started adding code comments to avoid similar situations, but did not yet experience the difference.

    1. 1

      How about somebody else's code? Any big projects you had to learn the structure of?

      1. 1

        My day job is programming, so I worked on various big projects. But working on side projects, and refactoring them taught me a lot.

        1. 1

          Can I ask one more question please. Did you use (or aware of) any useful approaches or tools to help with the task.

          1. 1

            I did not use any tools that helped me in understanding complicated code.
            Now that I'm thinking of this, a part of the process is to understand the requirement, what it does, then start to remove lines or refactor them, until I got a better code structure, at least now. Then try to avoid any ambiguity for the future, by adding comments..

  5. 2

    Look for someone who knows the code.
    IDE helps somewhat, but I'm not aware of any tools

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 49 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments My Top 20 Free Tools That I Use Everyday as an Indie Hacker 14 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments