Chapter 29: Integration Jacob Harper

The Integration Approach The order of adding components to a system is crucial Benefits to careful integration – Easier defect diagnosis – Fewer defects – Less scaffolding – Shorter time to a working project – Shorter overall development – Better customer relations – Improved morale – Improved code quality

Phased Integration Design, code, test and debug the each class – Unit development Combine the classes into one huge system – System integration Test and debug the whole system – System dis-integration

Problems with Phased Integration Problems arise when new classes are put together – Hard to find the culprit All problems present themselves at once All this happens late in the project – Hence, panic mode

Incremental Integration Develop a small functional part of the system – The skeleton Design, code, test, and debug a class Integrate the new class on the skeleton – Thoroughly test and debug the new addition

Benefits of Incremental Integration Errors easy to locate The system succeeds early in the project – Improved morale Improved progress monitoring You’ll improve customer relations The units are more fully tested You can build the system in a shorter development cycle – Certain jobs can be done in parallel

Top-Down Integration Start with the main function Then move through each level of the program Disadvantages – Leaves tricky system interfaces until the end of the project – Have to make stubs to fill in the missing classes Alternative: Vertical Slice

Bottom-Up Integration Build all low level classes Test them with scaffolding Replace the scaffolding with real classes Disadvantages: – Leaves integration of the whole system until last – Forces complete design of the whole system before integration Alternative: similar Vertical Slice method

Sandwich Integration Start with high level business-object classes Make the device interface Finish with everything else in the middle A realistic, practical approach

Risk-Oriented Integration “Hard part first integration” Identify level of risk with each component Code the most risky parts first

Feature-Oriented Integration Code a skeleton first Then make each feature Three advantages – Eliminates scaffolding – Visible evidence of progress – Works well with object design

T-Shaped Integration One vertical slice is selected for early development Then the overall breadth is developed Often combined with risk-oriented and feature- oriented

Daily Build and Smoke Test Build daily Check for broken builds Smoke test daily Keep the smoke test current Add revisions when it makes sense …but don’t wait too long Penalty for breaking builds Release builds in the morning

Chapter 32: Self-Documenting Code Jacob Harper

Programming Style as Documentation Use layout of code to define logical progression (indents and spaces)

Keys to Effective Comments Don’t just repeat what the code says – Explain what it does in common English

Kinds of Comments Repeat of the code – Restate in different words Explanation of the code Marker in the code – Gives notes to the programmer (ex: ***NOT DONE!) Summary of the code Description of the code’s intent Information that cannot possibly be expressed by the code itself

Commenting Efficiently Use a style that does not discourage modification – Boxes: too much spacing – Lines above and below: alright /******************************** * ********************************/ /******************************** Comments in here See, more comments Another line of comments Ok, these lines of comments are getting old *********************************/

Endline Comments Use them to annotate data declarations Avoid using for maintenance //fixed error.. To mark end of blocks } // End of main

Commenting Control Structures Before the control structure Put condition on ending bracket To show nesting // copy input field up to a comma While (…) { super awesome code here; }// while –- code input field For( int i = 0, i < 10, i++) { while( condition ) { if( something ) {... }// if } // while } // for