Add another layer to your #Business literacy. We at Serebral360° would love to know if the Forbes – Entrepreneurs article was helpful, leave a comment, like and share. Let’s dive in and discuss the information and put it to use to grow your business. #BusinessStrategy #ContentMarketing #WebDevelopment #BrandStrategy
Info@serebral360.com 762.333.1807 www.serebral360.com
Grap a copy of our NEW Business Stratgety Books #FFSS VOL1 and #FFSS VOL2
My digital design company was recently tasked with reverse engineering an existing product. The idea was to rewrite and stabilize a large application that had no specifications. Since most of the technical architecture was bad and the code was unusable, this was a big challenge (dare I say a headache?) and a long process.
As engineers, we often do not get the privilege of starting new projects from scratch or working with a clean codebase. We are forced to optimize and make sense of someone else’s messy code. We inherit legacy code with no one around that likes it enough to claim it.
When I find myself in this type of situation, reading through messy code or reverse engineering projects, I always require myself and my team to do these four things. I hope that what I’ve learned might help you through a similar challenge.
1. Create user stories while you’re using the app.
The first thing I like to do is make sure I know what a user might execute or why they are using a specific part of the application. User stories clarify software roles, reasoning and capabilities. I usually forget what a product can do, so I typically start by logging in and grabbing a cup of joe and a notation device. I find that writing down the application’s functions in the form of a user story will help you remember the “how” and “why.” This is especially helpful when you need to flip through your notes and rewrite it as software.
2. Leave no room for guessing.
The second thing I like to do is understand all of the codebase in full. This includes the code itself, the architecture flow, the project structure, all testing environments, runtime processes, build processes and more. The only way to fix, update or optimize any algorithm and/or specific class is to know its purpose top to bottom. In my opinion, if you intend to delete something then you should know when and why it will break. This is the most time-consuming part of understanding things, but it’s also where you will learn the most.
3. Evaluate the project as a whole.
Take a step back and write down what specific code is totally unusable. What parts need optimizing, and what can be left alone? Most importantly, how long will it take to start making valuable repository commits?
4. Explain it to a peer.
As nuclear physicist Ernest Rutherford once said, it should be possible to explain the laws of physics to a barmaid. I often encourage my engineers to parallel program. This isn’t because they’re not smart or equipped to handle a project, of course. When they explain the program to someone unfamiliar, they are forced to draw conclusions and explain what they know. Sometimes there will be holes another engineer can challenge, and other times it will help with overall evaluation. Just like every artist’s painting is unique, so too is every engineer’s code.
It can be very difficult to understand someone else’s art — that’s the challenge in this process. The key is not to get too far ahead of yourself, otherwise you’ll probably feel overwhelmed. If you can remember to do these four things, you can take it in stride.
March 14, 2019 at 08:04AM
Forbes – Entrepreneurs