Suggested things to do when working in production code

It goes without saying that the way that one writes code for personal projects and industry code is night and day. For personal projects and college projects, one doesn't pay any mind for naming conventions, idioms of language, tabbing and spaces, etc. The idea in most college classes is if it works, then yay. Afterwards, we throw that the project over the wall and forget about it.

But industry code is a different animal. We have to design that code to be workable and more importantly maintainable. If a code works, but isn't maintainable will end up becoming a big albatross around the team's neck and creating a lot of tech debt. One mantra that is heard a lot in software engineering is the most important step of making good software is design.

Making a design that is workable, reusable and flexible isn't always easy but maintaining that design will be easier to do in the long run if you invest time at the beginning when the project is smaller. From my experiences, I have compiled some things on what to do when working in industry level code to make maintaining your code easier.

1. Make sure that you D.R.Y.
Don't copy and paste code, even if it's tempting to do so. If you find yourself do the writing the same function, then it's easier to put common logic into a helper function, and then finding in the different arguments to that function.

2. Use a builder design object with building an object that has a lot of instance variables
Rather than having a lot of constructors for an object, it is much more maintainable and readable to have a builder that will construct the object step by step. It makes the code easier to read to someone that will read over your code. Lastly, it promotes code reuse.

3. Don't hack and slash code
Don't try to hack something together and pass it off as a working product. Make sure you understand the high level concept of what you're trying to build and make it a good, reusable design of it. Remember, this is code that has to be maintained.

4. Y.A.G.N.I.
If the requirement isn't there, then don't build it. If the business doesn't need it, then don't create extra work for yourself.

5. Try not to hard code values, make them constant values with names
It's more self-documenting to give a constant value a name rather than just hard coding the value itself. It stands out what on this value does rather than just some magic number.

6. K.I.S.S.
Since you are not the only audience of your code, you need to write your code so that others can understand your intentions. The easiest way to do that is to keep things simple and succinct. Don't try to be clever and write a complicated algorithm that where only you understand it. In industry, most likely you will not be the only one touching that code.

7. If you have any doubts about how something works, Google it or if its domain-specific, ask someone that is knowledge in that domain
Understanding the pieces that are in place will make you a much more effective developer, rather than the hack and slash coder.

8. If the code already exists, use the existing code. Don't reinvent the wheel.
In industry, we have deadlines and many other things that we have to deal with. Why make your job harder? If there's a library that accomplishes the task that you wish to do, then use that library. Chances are that the library has been throughly tested and used extensively by many developers. Rather than trying to implement your own algorithm that you will have to test yourself, use the tools that are out there. Remember, work smarter not harder.

9. Program to the public interface never to the implementation
The public interface for an application usually changes very little. But its implementation may change 5 times over. One idea of good software development is to have loose coupling. You don't want to have your client code that is using the directly the implementation of the API. If the implementation changes, then you will have to change your client code to match it. Since the public API doesn't change and it being implementation-agnostic, if the implementation changes then your client code shouldn't have to be changed.

Keep Learning!

Anthony Belen
アントニー・ベレン

Introduction

Hello all,

My name is Anthony Belen. I am a upstarting software developer that currently works for PayPal. As a software developer, I specialize in RESTful Web services in Java. I have only been working as a software developer for about 6 months now, but I have learned more in the industry about true software development than learning in a classroom as a Computer Science undergraduate.

I wish to use this blog to share my feelings, best practices and other things that I have seen in the industry that are relevant. I may also share good ways on how to learn new things and pick them up quickly. Lastly as a Japanese Language student, I may dedicate some time to blog about Japanese Learning as well.

I look forward to these journeys as a way to grow myself and mature in terms of software development and as a person.


Peace be with you.


Anthony Belen
アントニー・ベレン