1. SOFTWARE ENGINEERING:various concepts around- implementation- testing- debugging- development rulesO. Teytaud

2. I will here give a list of rules thatone can meet as a developer.I dont claim that all these rules areGood. In fact, I keep only some ofthem for myself.It also depends on the context inwhich you develop.Make your own choice :-) 3. Various sayings around software development (1) Debugging and maintaining takesmuch more time than implementing. ==> good development saves up time.Typesetting is a very small part ofimplementation.Data structures are more importantthan codes/algorithms ==> discuss datastructures more than codes 4. Various sayings around software development (2)Premature optimization isthe source of all evil. Slow bug-free code is often ok.Only a few parts of the program are worthbeing optimized.People who never code dont know. Trust only people who code. If theboss does not code, dont trust the boss. 5. ASSERT We already discussed this, do you remember ?Function tralalaItou(.....){x=a/b;y=log(z);...} 6. ASSERT We already discussed this, do you remember ?Function tralalaItou(.....){assert(b!=0); x=a/b;assert(z>0); y=log(z);...} 7. UNIT TESTSAnyone who knowswhat is a unit test ?Example:I implement a function half(x) {return x/2} Its unit test is===================y=drand48()assert(half(y)==y/2);=================== Principle of unit tests:unit tests for all functions. 8. NO OBESE CODE (1) Implement only the methodswhich are really necessary. Many programs die (no users, no maintenance, ) because they are too big and unreadable.Keep it simple. Four small classes/filesare better than one huge class/file. 9. NO OBESE CODE (2)Do not include a code which is not extremely useful.Because:- license issues- maintenance issues- compatibility/portability issues 10. MAINTENANCE RULES If you find a bug,- first, correct the bug :-)- put several asserts which prevent the bug from coming back- if unit testing, build the unit testcorresponding to the bug 11. PREMATURE OPTIMIZATION is the source of all evil. Do you understand what I mean by optimization ?1) Implement with slow functions2) Find where you should optimize (how ?)3) Optimize this place only; possibly, then,go back to (2) 12. Find where your program isslow Profiling: Finding where and why your program is slow.Possible tool: instrumentationt1=clock();some code...t2=clock();timeSpent=t2-t1; 13. Find where your program isslowProfiling: Finding where and why your program is slow. Possible tool: instrumentationstatic timeSpent=0; suggests that prototyping is a good idea==> not sure we need a lot oftheory on this idea 27. Other examplesSo many examples now...See e.g. Unified Process(based on Unified Modeling Language). With plenty of non-convincing graphs withboxes, circles, arrows, philosophical statements. 28. In my opinion:- know SVN (and/or other such tools)- read and understand object-oriented programming(like it or not, but you will see itin your professional life...)- maybe give a try to functional programming- and do prototyping-approaches (whenever you dont call it prototyping: fast release, no premature optimization,prefer the easy way first) 29. What is software testing ?- unit tests (each functions doeswhat it is intended to do)- global test (the program doeswhat it is intended to do)- performance test (is the programfast enough / does it save upresources) 30. Should we have testings ?Yes, very often. Well, some people say thatyou should not, and that you should prove correctness (good luck). 31. Should we have testings ? But not necessarily yourself:- have users (release often) withautomatic upgrades- use open source- include automatic bug report in case of assert (e.g. core files; do you remember ?) 32. Terminology of testingUnit testing: remember ?Real-time testing: assert! 33. Terminology of testing Functional testingchoose a functionalityin the documentation and test it.= testing high-level feature, andonly features included in doc. 34. Terminology of testing Non-functional testing:check something which is notin the doc, but which might beImportant: scalability (w.r.tnumber of cores, or memory, orsize of problem, or compatibility...) 35. Static testingRe-read the code.Re-read the specifications.Two readers: very efficient. 36. Dynamic testing Debugger.Profiler. 37. Black box, white boxBlack-box: testing without knowing any thing about how it works. White-box: testing with the APIor using internal pieces of codes fordriving tests. 38. Regression testingChecking that the program performs at least as well as the previous version. 39. Greek lettersAlpha-testers: testers from your company.Beta-testers: testers who accepta possibly highly unstable code. 40. Usability testing: is it easy to use ?Security testing: can we cheat for getting confidential data ? 41. How to have plenty of free testers ?Cloud development:if the code is mainly on your side(on your cluster), then you can easilyswitch some users to a new version. E.g.: gmail 42. How to have plenty of free testers ?Automatic updates: Linux, Windows, many codes.Incidentally: bugfixes are immediately spread everywhere. 43. How to have plenty of free testers ?Open source:when using is free, you get many users. When they can see the source, they might even find the bug. 44. Related stuffSoftware verification:includes testing; answersthe question does it work ?Also includes program proving. Software validation: Is it really what we need ?Integration by the customer ok ? 45. Related stuff Warranty: should you give some warrantyto your user ?==> quite dangerous.==> if your user looses 15 billionsUS dollars and can claim that it isbecause your softwarehad a bug, you have a trouble==> limited warranty at most. 46. Want to test your programming skills ?Enter a programming contest. Often possible just by internet. E.g.: 24 hours, 3 persons for developing a programwhich performs a given task. You get celebrity if you win, you get experience if you loose.Ill organize one soon, join :-) 47. DISCLAIMER (1)These slides might be biased by my personal experience.Many programs in real life are incredibly dirty and buggy.A brief sample of my experience: - nobody wanted to be responsible of anything (afraidof troubles; so people prefercoding minor unimportant easy stuff); - someone was angry, and decided to makeit impossible to get rid of bugs; - the crucial person who could make it workhas gone away (happens often); - no time for testing, because everybody had tojustify that he is very very fast; 48. DISCLAIMER (2)- bugs were considered as features, becausenobody really wanted to maintain a dirty obese code;- delays were unrealistic, because the guy whodecides has no idea of what it is about (theboss is often not a developper);- everything was blocked by intellectual property people (when theres no use protecting a code, they protect it anyway just because they must justify that they work). 49. PERSONAL CONCLUSION (1)I think theres much more respect than 10 yearsago for developpers in software companies (e.g. Google)Switching from waterfall to prototyping illustrates this. My take-home message:I think that assert is great, as well astest suites, profiling, debuggers, automatic upgrades, open source, pair coding, cool atmosphere. Many sophisticated philosophical discussions on software development are (for me...)a little bit useless and just a posteriori rationalizationof what people actually decided to do. 50. PERSONAL CONCLUSION (2)Think of specialized languages- Matlab / Octave: fastprototyping / modelization with maths- R for statistics / machine learning- Cobol for business applications- Bash/Perl for fast prototyping of file manipulation 51. Do you know the COBOL language ? A main victim of the year 2000 problem(because it is dedicated to business applications).COBOL is also a self-modifying language: Alter X to proceed to Ymeans: goto X becomes goto Y. Original COBOL had no local variable;no while; no dynamic allocation. A nice challenge for software testing:who had guessed the year 2000 problem10 years in advance ? 52. Testing can only prove the presence ofdefects, never their absence.E. Djikstra (author of A Case against the GOTO Statement ) (militant against software testing) 53. Object-oriented programming is anexceptionally bad idea which could onlyhave originated in California.-- Edsger DijkstraI do not consider that object orientedprogramming is always a good idea.Dont say this in a job interview; OOP isnow politically correct. 54. It is practically impossible to teach goodprogramming to students that have had aprior exposure to BASIC: as potentialprogrammers they are mentally mutilatedbeyond hope of regeneration.-- Edsger W. Dijkstra, SIGPLAN Notices,Volume 17, Number 5(I started programming with Basic...) 55. The use of COBOL cripples the mind;its teaching should, therefore, beregarded as a criminal offense.Edsger W. Dijkstra 56. Dont consider that programming languages will never change.In old programming languages:- lines had a number;impossible to concatenatetwo functions.- variables should be written with two letters at most.- there were goto everywhere.And some people, at that time, claimed thatextending variable names to 3 or morecharacters was a stupid idea.