OO Summary (Homework 1-3)

【1】Previous Coding Analysis

(1) Poly Add

(2) Idiot Elevator

 

 

(3) ALS Elevator

 

COMMENTS:　

　　Cyclomatic complexity is a software metric, used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a box program's source code. 

　　A large Cyclomatic Complexity means low quality of code and difficulties in testing and maintaining. Higher Cyclomatic complexity may cause higher probability of bugs. From both three Metrics forms, my programs all show the same problem, which is caused by my One-For-All architecture. Due to this kind of structure, my time spent on debug is very long and it's uneasy to find out where the bug lies. It's also a problem that when I find a problem it would be difficult to correct, for one problem solved the others appear. As the forms show, high complexity program is more like a Procedure-Oriented program wearing the mask of Object-Oriented. This is a serious problem that is eager to be solved.

 

【2】About Bugs

(1) My Bugs

1. Not setting restrictions on input length. 

　　I intended not to set too much limitations, however, I missed a point that due to my java program, if input is larger than Long-Int, an exception will be called. Better solutions will be: setting input limitations / setting length in Regular Expression.

2. Not printing results in the sequence of input.

　　This is an algorithm problem. It’s caused because I missed this demand at the beginning. Since correct this problems would cause other problems, I decided not to fix it. This has shown the importance of architecture.

 

(2) How to Find Others’ Bugs

　　Firstly, though not willing to admit, this is somehow a game of luck! All three times, assignments distributed to me are all above me, which I can tell for sure from their coding style, preciseness, and code architecture. In this case, when I’m facing almost perfect assignments, it’s like mission impossible to find their bugs, yet I still made it though only for one time. However, on the other hand, this has brought me a great opportunity to learn from talented and experienced peers and motivated me to keep working hard. 

　　Back to myself, the first thing I go to is the testee’s Readme document, from which I may learn his thought and design clue. Also, it’s the quickest method to find differences and mistakes. To see what points does he omit or stress, I can have a better understanding of what the programmer emphasizes the most. Omission of a key point may be a more obvious mistake, however, what one stresses may also hide mistakes, since it’s the part that he regards the most difficult.

　　The basic and always useful way is to read the testee’s code. This may be the most time-consuming way, for we have different coding style, algorithms, and mindset. But to get to know deeper, it’s a must to turn to the origin, thus focus on the code. Besides, in the future, we’ll have to read numerous source code. This way of training may be of some help.

 

【3】Reflections

(1) Procrastination

　　Farewell to you — Procrastination & Welcoming you — Planning! No one would deny that the result is proportional to the time spend on it, especially for beginners. Sufficient time and well-planning are both essential to pull through projects more smoothly.

 

(2) What Should I Do Before Coding

1. Read Guidebook.

　　Guidebook is where problems originate as well as where answers be born. It’s never too much to read the guidebook, since it’s the most authoritative teacher. When reading it, there’s a few key points to figure out:

　　What is the purpose of the project? - What basic functions should I realize? - Are there any special demands? - Are there anything implicit in the guidebook? - What is the most important part in this project? If possible, read the guidebook out, not in silence.

2. List Demands.

　　There may be many demands in the project, which is exactly like daily lives: Customers’ demands would always beyond your imagination, even beyond their owns. The project we are facing now has much less demands than real life but much more than my previous experience. In this case, to avoid missing important information, I choose to list each demand in detail.

3. Design Structure.

　　Draw the whole picture first. The structure and framework are much important and necessary than coding. Coding on terrible frame may cause many problems and unpredictable bugs, especially when the amount of code gets larger.

4. Make Plan. 

　　Analyzing what to do first and what module is the basis of others. Then, make a plan or To-Do list  to schedule time and make the best use of it. 

 

(3) How to Deal With Emotions

Persistence:　　Beginning is never easy, yet never yield to it. Spend time working hard, instead of complaining. 

Positive:　　Not losing heart when you’re facing difficulties. Coding while gaining power and strength.

Peaceful:　　Not panic when you fall behind. Take a deep breath and start debug again.

 

(4) Encouragement

As a starter, it’s not a easy task to handle. But remember in mind: ONLY THE UPHILL IS HARD!