Structure over Function

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(an attempt to finish it)
(try rephrasing, do not know if metaphors work?)
Line 1: Line 1:
-
When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.
+
When learning to program, the function of a piece of code is the most important thing to get right, once you have mastered the syntax of the programming language. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.
So what is missing?
So what is missing?
Line 6: Line 6:
One of the most dominant barriers to evolution is the code's structure.
One of the most dominant barriers to evolution is the code's structure.
-
Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems: its architecture.
+
Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems: its design and architecture.
-
Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote code using badly structured code tends to get degenerate structure as well. Take the Refactoring medicine to improve code structure.
+
Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote, code using badly structured code tends to get degenerate structure as well. Take low cohesion and high coupling or metrics showing structural disorder as symptoms to be remedied.
-
While bad structure can occur at all levels, good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it.
+
Refactoring is the treatment to improve code structure. Test automation and version control provide safety, so that treatment does no harm or can be easily undone.
-
Keep your code well organized. Take low cohesion and high coupling or metrics showing structural disorder as symptoms to be remedied. Refactor mercilessly toward DRY code. Use Patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture.
+
While the need to refactor is almost inevitable, because we learn about better solutions while we program, there are also preventive measures in addition to make refactoring less expensive and burdensome.
 +
 
 +
Bad structure can occur at all levels, good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it. Initially a user might not recognize bad structure, as long as functionality is available, but evolving the system might not happen at a pace the user desired, once structural decay happens in its code.
 +
 
 +
Keep your code well organized. Program deliberately. Refactor mercilessly towards DRY code. Use Patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture towards doing more with less code. Avoid too much up-front genericity and refactor away from laborious specific solutions repeating code.
As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system grows beyond "hello world"'s size.
As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system grows beyond "hello world"'s size.

Revision as of 08:46, 14 August 2009

When learning to program, the function of a piece of code is the most important thing to get right, once you have mastered the syntax of the programming language. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.

So what is missing?

You or others will have to read, understand, use and modify your program code. Evolution and change of code is inevitable. Thus, you need to ensure that your code can evolve while its functionality survives.

One of the most dominant barriers to evolution is the code's structure. Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems: its design and architecture.

Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote, code using badly structured code tends to get degenerate structure as well. Take low cohesion and high coupling or metrics showing structural disorder as symptoms to be remedied.

Refactoring is the treatment to improve code structure. Test automation and version control provide safety, so that treatment does no harm or can be easily undone.

While the need to refactor is almost inevitable, because we learn about better solutions while we program, there are also preventive measures in addition to make refactoring less expensive and burdensome.

Bad structure can occur at all levels, good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it. Initially a user might not recognize bad structure, as long as functionality is available, but evolving the system might not happen at a pace the user desired, once structural decay happens in its code.

Keep your code well organized. Program deliberately. Refactor mercilessly towards DRY code. Use Patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture towards doing more with less code. Avoid too much up-front genericity and refactor away from laborious specific solutions repeating code.

As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system grows beyond "hello world"'s size.

by Peter Sommerlad

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools