Programming practises and project management for professionnal software development

IntroductionBest Programming Practices

Software QualityProject Management

Summary

Programming Practices and Project Managementfor Professional Software Development

Sébastien Jodogne

CHU of Liège

Interfaces-Entreprises ULg, May 28th, 2013

1 / 34

1 Introduction

2 Best Programming PracticesPut Your Code in Revision Control SoftwareCoding Style and DocumentationDon’t Reinvent the (Squared) WheelDesign PatternsOther Recommendations

3 Software QualitySoftware Engineers are Part of the TestingAssertion-Driven TestingUnit TestingIntegration and System Testing

4 Project ManagementAgile MethodologiesScrumExtreme Programming

5 SummaryScore Your Project!



Summary

Who Am I?

PhD in Computer Science, ULg. Domains of interest:Image Processing,Machine Learning,High-Performance Computing,Theoretical Computer Science.

5-year professional experience in private companies:CCTV – Closed Circuit Television (Secosys, Euresys),Machine Vision (Euresys),Broadcasting (EVS).

Now: Medical imaging engineer in the Department of MedicalPhysics at the CHU of Liège.This talk: Industrial practices for compiled languages.

2 / 34



Summary

Case Study

SummaryLightweight, scriptable server for medical imaging.Open-source (GPLv3).Developed with an industrial methodology.Main languages:

Core: C++.GUI: HTML5, JavaScript.

3 / 34

1 Introduction





1 Introduction







Summary

Put Your Code in Revision Control SoftwareCoding Style and DocumentationDon’t Reinvent the (Squared) WheelDesign PatternsOther Recommendations

Put Your Code in Revision Control Software

AdvantagesKeep track of all the changes to the code.Share across multiple computers, with multiple collaborators.Track the various versions of the software (“tagging”).Backup (recover deleted or modified files).Avoid the ZIP mess (which version is the latest one?).

Candidates1 Mercurial.2 Git (more adapted to geeks).3 Subversion (becomes legacy).

4 / 34



Summary


Questions When Starting a Project

Choose a licensing model (cf. Jérémie Fays). GPLv3 is thede-facto choice.Choose a software forge:

For closed-source (private): BitBucket, SourceForge.For open-source (public): GitHub, Google Code.For confidential code (medical data, spin-off): ???

5 / 34

http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

1 Introduction







Summary


Choose (and Stick to) a Coding Style

6 / 34



Summary


Documentation

Document functions and classes in the source code⇒ Doxygen (C/C++), Javadoc (Java), XML (C#).Document architecture and algorithms elsewhere (separatefiles or Wiki).Don’t forget the User Manual (PDF or Wiki).Be verbose and use explicit names (possibly long) for variables,functions and methods.⇒ “Self-Documented Code”.Do not reuse variables and introduce them only when they areneeded (not at the top of a function as in C).

7 / 34

1 Introduction







Summary


Don’t Reinvent the (Squared) Wheel

Use third-party libraries.⇒ Know your ecosystem (language, frameworks, StackOverflow).Recommended libraries for C++: STL, Boost, SQLite, Qt. . .Caveats:

Minimize the number of dependencies!Avoid heavyweight, not supported or “exotic” libraries.Pay attention to portability (Windows, Mac OS).License compatibility.

8 / 34

http://stackoverflow.com/

http://www.dwheeler.com/essays/floss-license-slide-image.png

1 Introduction







Summary


Anti-Patterns (Don’ts!)

Programs whose structure isbarely comprehensible, espe-cially because of misuse of codestructures (especially GOTO).

9 / 34



Summary



Classes not properly encapsulated,thus permitting unrestricted access totheir internals.

10 / 34



Summary



An object that knows too muchor does too much.

11 / 34



Summary



ConclusionsLearn and recognize bad software architectures.Inventories do exist!

Lasagna code,Magic numbers,Poltergeists,Error hiding. . .

[Antipatterns, Code smells, Fifth-System Effect]

12 / 34

http://en.wikipedia.org/wiki/Antipattern

http://en.wikipedia.org/wiki/Code_smells

http://fifthsystemeffect.wordpress.com/



Summary


Design Patterns (Do’s!)

Recurring solutions to commonproblems in software design.

13 / 34



Summary


Design Patterns (Do’s!)

Basic Philosophy

Uncouple the software components by adding abstractions (“Javainterfaces”), thanks to object-oriented programming.

[Wikipedia, Head First Design Patterns]

Some Common PatternsSingleton.Factory.Observer.Model-View-Controller (aka. separate GUI and core).

14 / 34

http://en.wikipedia.org/wiki/Design_Patterns

http://shop.oreilly.com/product/9780596007126.do



Summary


RAII — Resource Acquisition Is InitializationMost useful design pattern for C++.Automatic release of a resource on leaving scope or onexception ⇒ Never any leak!Applicable to memory allocation, I/O, multithreading. . .

class FileWriter{private:

FILE* fp_;

public:FileWriter(const char* filename){

fp_ = fopen(filename, "w");}

~FileWriter(){

printf("Closing file\n");fclose(fp_);

}};

void Demo1(){

FileWriter w1("/tmp/hello.txt");// Leaving scope => closing "w1.fp_"

}

void Demo2(){

FileWriter w2("/tmp/hello.txt");throw std::runtime_error("Sorry guy");// Exception => closing "w2.fp_"

}

15 / 34

1 Introduction







Summary


Other Recommendations

1 KISS (“Keep it simple, stupid”) — A code is written once, butread many times by different people!

2 DRY (“Don’t repeat yourself”) — Implement somecomputation at a single place to ensure consistency.

3 “Premature optimization is the root of all evil” [D. Knuth].4 Use exceptions, never return error codes (except in C).5 Use a build system (CMake, SCons or Visual Studio).6 Windows-only: Do not create DLL and favor static linking,

except if you know what you are doing (ABI, DLL hell)!7 Learn debugging tools:

Debuggers (Visual Studio, Eclipse, gdb. . . ).Linux-only: Valgrind (memory leaks, access violations. . . ).

16 / 34

http://en.wikipedia.org/wiki/Kiss_principle

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

1 Introduction





1 Introduction







Summary

Software Engineers are Part of the TestingAssertion-Driven TestingUnit TestingIntegration and System Testing

What is Legacy Code?

Legacy code is defined ascode without tests.

⇓

Impossible to know whenthings get broken (i.e. to

detect regressions).

⇓

Impossible to refactor.

17 / 34



Summary


“Testing is up to the Testers and the Users!”

Really? Bugs detected at thecode level are:

Easier to understand,Easier to reproduce,Easier and cheaper to fix,More contained.

⇓Software engineers are part ofthe testing process!

18 / 34



Summary


“Testing is up to the Testers and the Users!”

Really? Bugs detected at thecode level are:

Easier to understand,Easier to reproduce,Easier and cheaper to fix,More contained.

⇓Software engineers are part ofthe testing process!

18 / 34

1 Introduction







Summary


Assertion-Driven Testing (aka. Invariants/Preconditions)

#include <assert.h>#include <stdio.h>

int factorial(int value){

assert(value >= 0);

if (value == 0)return 1;

elsereturn value * factorial(value - 1);

}

int main(){

printf("%d\n", factorial(-5)); /* => crash */}

19 / 34

1 Introduction







Summary


Unit Testing

int main(){

printf("%d\n", factorial(0)); /* 1 */printf("%d\n", factorial(1)); /* 1 */printf("%d\n", factorial(2)); /* 2 */printf("%d\n", factorial(3)); /* 6 */printf("%d\n", factorial(4)); /* 24 */printf("%d\n", factorial(5)); /* 120 */

}

⇒

TEST(Example, Factorial){ASSERT_EQ(1, factorial(0));ASSERT_EQ(1, factorial(1));ASSERT_EQ(2, factorial(2));ASSERT_EQ(6, factorial(3));ASSERT_EQ(24, factorial(4));ASSERT_EQ(120, factorial(5));

}

Basic IdeaAccumulate a database of tests!

20 / 34



Summary


Unit Testing

int main(){


}

⇒

TEST(Example, Factorial){

ASSERT_EQ(1, factorial(0));ASSERT_EQ(1, factorial(1));ASSERT_EQ(2, factorial(2));ASSERT_EQ(6, factorial(3));ASSERT_EQ(24, factorial(4));ASSERT_EQ(120, factorial(5));

}


20 / 34



Summary


Unit Testing

int main(){


}

⇒

TEST(Example, Factorial){

ASSERT_EQ(1, factorial(0));ASSERT_EQ(1, factorial(1));ASSERT_EQ(2, factorial(2));ASSERT_EQ(6, factorial(3));ASSERT_EQ(24, factorial(4));ASSERT_EQ(120, factorial(5));

}


20 / 34



Summary


Unit Testing In Practice

Use a unit testing framework (e.g. Google Test).Move your main() tests as unit tests.Keep your unit tests small and fast.Add unit tests each time a function or a class is added.Add an unit test for each solved bug.Execute the unit tests as a step of the build process!Even better: Write tests before writing the code (aka. TDD— Test-Driven Development).

21 / 34



Summary


Continuous Integration Server (Build + Unit tests)

22 / 34

1 Introduction







Summary


Different Flavors of Quality Assurance

ClassesFunctions

Executable

Hardware/OS

Unit testing

Integration testing

System testing

23 / 34



Summary


Integration Tests

“End-to-end” tests on the final binaries (black box).Typically less automated and much more lengthy than unittests (white box).Possible approaches:

1 Inject stimuli, compare outputs with expected results.2 GUI automation testing.3 Challenge the API (cf. Orthanc).

Run integration tests (at least) before each release, or evenbetter as part of the nightly builds.

System TestsAt last, the testing team makes user-level tests.

24 / 34



Summary


Issue Tracker: Link between Engineers, Testers and Users

Common ChoicesBugzilla, JIRA, FogBugz, Redmine, Trac.Often integrated within the software forge.

25 / 34



Summary


The Software Quality Iceberg

26 / 34

1 Introduction





1 Introduction







Summary

Agile MethodologiesScrumExtreme Programming

A New Vision of Project Management

⇒

The cathedral (monolithic)

The bazaar (agile)

27 / 34



Summary


A New Vision of Project Management

⇒

The cathedral (monolithic) The bazaar (agile)27 / 34



Summary


Agility: Cut Down Release Cycles

⇒

Features are incrementally added.Software architecture is continuously refactored.

28 / 34



Summary



⇒


28 / 34



Summary



⇒


28 / 34



Summary


Continuous Testing is at the Center of Agile Development

⇒

The cathedral (monolithic) The bazaar (agile) 29 / 34

1 Introduction







Summary


Scrum: Most Popular Agile Methodology

30 / 34



Summary


Scrum: The Product Backlog of Orthanc in Trello

31 / 34

1 Introduction







Summary


Extreme Programming: Agile Engineering Practices

32 / 34



Summary



32 / 34



Summary



32 / 34

1 Introduction





1 Introduction







Summary

Score Your Project!

Score Your Project!

33 / 34



Summary

Score Your Project!

Any Question?

34 / 34

Technology

Programming practises and project management for professionnal software development