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

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

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

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

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

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

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

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

Summary

Score Your Project!

33 / 34

Summary

Score Your Project!

Any Question?

34 / 34

programming practises and project management for professionnal software development

Technology

web reserarch and professionnal network

safety practises

professionnal slideshow pierre-jean delvoye

csp best practises - nrel

nvidia gpu computing webinars best practises for opencl...

contemporary professionnal pastry making (dvs 5842) :...

best practises sauvegardes vmware

xcelsius best practises

construction practises

best-practises ro plant

professionnal pressbook

morningstar professionnal juin 2011

best practises lapkeu akrual

top 10 wms practises

professionnal rules for strawbale building...luc floissac -...

global hr practises

laserjet professionnal m1130_m1210

xcelsius best practises[1]

yashica electro 35 professionnal - suaudeau.eu

javascript proven practises