My Coding Process

        This is the process I use to write my code. It's likely that you have a somewhat different process, but I often find it helpful to learn from others when it comes to their coding process and to take inspiration from it. So I'm presenting mine here. Here are the categories of code that I write most often and how I approach them:

Code to Execute Commands or Supply Data

  1. Look for code that serves a similar or identical purpose. It's very likely that someone has done what you are doing in the past. This person has already struggled with trial and error and will save you an enormous amount of time getting exactly the right calls to make. It's even possible they copied their code from yet another source -- in which case, they have iterated and improved upon it.
  2. When looking to use someone else's code, it's important to spend time breaking it down and understanding exactly what it does. The better you understand it, the more capable you will be when modifying it to fit your own needs. It's very likely that you will need to make modifications to its intent, as well as to its code style and how it fits into the rest of your program.

Connecting Code Within Your Own Program

        While the individual components of code are rarely unique, it becomes exponentially less likely that you will be able to find code that connects two unrelated components. I suggest taking inspiration from adjacent code in your program instead of searching in this case. Look at how other components are wired together and make something similar.

Unique Business Logic

  1. This is the code you need to spend the most time on. You are the person doing the trial and error for the first time in this case. Thus, it's very likely that you will make mistakes when working on this code. That's perfectly normal. There are ways of making this trial and error process safer. I suggest an outside-going-in approach: Write your externally facing components first. If it's possible, treat your code changes like a subsystem within the code with its own entry points and classes.
  2. Avoid piling code onto large existing classes when possible. You may need to modify existing code architecture in order to do this. This is the better outcome as it avoids mixing multiple use cases in the same classes and methods.
  3. Make sure that your data suppliers and connecting code are separate from your business logic to a reasonable extent. The more isolated your business logic, the easier it will be to read and modify.
  4. Call your API using example data with the blank methods and classes and see that all of your wrappers and entry points work before writing your core business logic. This will help isolate your code so that you can work on the core business logic and just the core business logic.
  5. Similarly, you can use test driven development in order to validate your code. When doing this, it's often good to have a very stable entry point or you will need to re-write the test every time you change that entry point.
  6. Finally, write your core business logic. This will likely be written and re-written several times before you find an ideal architecture. Try to fit within the code style that others have set before you, along with giving good documentation and method/variable names in order to make the code as readable as possible. When people are reading this code, it's likely they will have quite a bit more difficulty with it than other components because it is unique. Readability is the path to maintainability.

Comments

Popular posts from this blog

Low Level Design Part 3: Estimates

Low Level Design Part 1: Reading and Gathering Information

Using Kanban Boards to Stay Organized and to Stay Motivated