So, I have started blogging. I had been thinking about how and what I would start this off. It occured to me that I should talk about something that I had learned throughout my life but never knew the name of until college. Even after that, I wasn't sure ow to describe the methods I take when designing systems. Encyclopædia Britannica defines the Axoimatic Method:
in logic, a procedure by which an entire system (e.g., a science) is generated in accordance with specified rules by logical deduction from certain basic propositions (axioms or postulates), which in turn are constructed from a few terms taken as primitive
Simply put, we have it as a "system" with "rules". Looking at this from another angle, each rule could be defined as a system by itself. I suppose this could be likened to a parent-child relationship in the sense that you could have something like
system
--> rule1
--> rule3
--> rule4
--> rule2
--> rule5
where rule1 and rule2 are "systems" themselves. Enough of this meta-speak...so how do I want to relate this to programming in general? Actually, I'd say more specifically system design in general.
Suppose your boss comes in to your office/cubicle and tells you "I need a system that will give me a report on widgets in the warehouse. I need it as soon as possible." Some paths you can take include [] make a basic system from existing resources based on what your boss told you and [] ask questions. From the beginning, you have to think about how this is to be designed. Of course, your design could be a simple, static webpage that you put together on demand (when your boss tells you to). You could make it where someone enters all of the data into your system. You might even want to pull data from an existing system. All somewhat viable options. But, you of course need to dig deeper into what your boss' vision might be. You will most likely need some sort of input mechanism. Possibly some filtering and sorting. Perhaps different style reports (aggregates and such). Each of these functional requirements depends on rules for definition. Each of the functional requirements make up the system you are defining. The smaller each "rule" is, the easier it is to understand and adjust when needed. Also, and this is fairly important...the easier it is to reuse the rule anywhere else in the system when appropriate.
This moves into another topic that I'll just mention here: refactoring. This book is probably one of the most important books to get you started down the path of good system design.
How do you use this in real life? Start looking at your designs from the perspective that even if your "system" is small, you can add to it easily. Consider that youmay need to modify bisiness rules in the future. Make that easier to do without reworking the system design. Realizing what scope your rules are makes these processes easier.
Apply at least some of these ideas to your current programmatic methods and I'll bet a better system will come of it.