Home › Programming › 6 ways to be a better programmer – Episode 2
6 ways to be a better programmer – Episode 2
Continuing with our trilogy, we will now address more 2 ways on how to become a better programmer.
3. Do not be afraid to break things
Everyone who is professional in software development area have come across a precarious base code. Code misspelled invariably is difficult to maintain code and is always a moment of great tension when a new module is added, hoping that "all" continue intact.
But we have to face that poorly written code is like a sick patient, that the treatment will be needed and probably surgical treatment, and as good doctors we can not be afraid of the required surgery. We can not be afraid to break pieces of code in refactoring stage. We must face this time break, as times when the surgeon is required to cut the patient to proceed with the surgery.
Do not be afraid of your code. Who cares if something is broken temporarily while you fix things? Investing time in refactoring is wise, that time will pay many times. A major benefit is that the experience of dealing with a sick system makes you learn how it really should work. Redefine internal interfaces, restructure modules, refactor copy-pasted code, and simplify your project reducing dependencies. Slowly perform the transition from the old structure to the new, testing all along the way. Attempting a big refactoring will cause enough problems to make you consider quitting every effort down the middle.
Be the surgeon who is not afraid to cut the diseased parts to make room for healing. Attitude is contagious and will inspire others to start working on these cleaning principles. Keep a list of "hygiene" tasks. Convince management that although these tasks can not produce visible results, they will reduce costs and accelerate future releases. Never stop worrying about the "health" of the overall code.
4. Take advantage of code analysis tools
The test value is something that is hammered in software developers from the early stages of their journey. In recent years, the increase in unit tests, test-driven development, agile methods reinforced the wave of interest in making the most testing at all stages of the development cycle. However, the test is just one of many tools you can use to improve code quality.
Nearly all programming languages have at least one tool that checks violations of style guides, tips and common mistakes, which often can be difficult to catch. More sophisticated tools such Splint for C or pylint for Python, are configurable, which means you can choose which errors and warnings that the tool emits through a configuration file from the command line or in your IDE.
If all else fails and you find yourself looking for simple errors or violations of standards that are not covered by your compiler or IDE, you can always roll your own static checker. This is not as difficult as it may seem. Most languages, particularly the dynamic exposes its syntax trees as part of their standard library. It is worth knowing the dusty corners of the standard libraries that are used by the development team of language that you are using.
So do not let the test to the end of their quest for quality and make the most out analysis tools.
