.. include:: What's There? What Have We Accomplished? ======================================== .. contents:: :local: Rules? Why Rules? ----------------- Rules are there to enforce ... * A working state * Maintainability/modifiability (|longrightarrow| readability) * Respect from ... * Co-workers * Employer * Users/customers Which rules and tools have established in software? Object Oriented Programming --------------------------- .. sidebar:: Survey Who ever over-engineered a program? *Talk about the code as if you'd talk about you domain objects*. A rather old discipline ... * Encapsulation * Interfaces * *Overengineering* * |longrightarrow| *a hard discipline* **Looks like that is part of our craft** .. image:: /trainings/material/soup/clean-code/design_patterns.webp * Not tied to any programming language * "This is how things are done" * *Only a write-up of existing practice* * Gives things *names* * |longrightarrow| chances are good that what we do is a craft Coding Style ------------ .. sidebar:: Disclaimer Don't ask me too much about coding style - I like to break rules. * Respect: others might not be as smart as you - they want uniformity * No rules? * |longrightarrow| consensus is needed * People don't usually consent easily (especially male individuals) * All rules? * No consensus needed * *But:* rules are never 100% (has your company established prcesses?) * War between those who obey the rules and those who (occasionally) don't .. _clean-code-solid: Design Principles: SOLID ------------------------ * Single Responsibility * Every class must have a single responsibility * Open/Closed * Software entities must be open for extension, but closed for modification * Liskov Substitution * It must be possible in a program to exchange two implementations of an interface *without* compromising the correctness of the program * Interface Segregation * No client of an interface should be forced to depend on methods it does not use * Dependency Inversion * High-level modules should not depend on low-level modules. Both should depend on abstractions. * Abstractions should not depend upon details. Details should depend upon abstractions. *Antipattern*: a pattern that violates any of these principles Another One: YAGNI ------------------ "You ain't gonna need it!" * Extreme Programming (XP) * Test Driven Development * When everything is covered by tests, then you can implement a feature at the time you need it * |longrightarrow| the system can be changed at any time Architecture ------------ * Good architecture allows major decisions to be deferred * Maximizes the number of decisions *not* made * Makes choice of tools irrelevant "Interfaces are a sign of indecisiveness!" |:middle_finger:| Project Management: Traditional ------------------------------- * Road construction business * Fundamentally different from software * No cycles (version 2.0 of a road?) * Hardware manufacturing * Somewhere in the middle * PCB design * BOM * Production * Bug are fixed |longrightarrow| new version Project Management: Software ---------------------------- * Continuous change possible |longrightarrow| happens! * Great tools: version control systems (craft?) * Do we want continuous change? * What is bad about it? * Is it necessary? * Is it possible to plan 100% ahead? * Requiremenets must be rock stable * Road construction? * Anyway, fact is ... * Cycles are possible * We are too stupid to plan ahead |longrightarrow| let's just accept the fact, and make the best out of it! **Let's go AGILE!** So What? -------- * Everything's there: tools, principles, do's and dont's ... * Well understood * It's just that it takes about 20 years to learn all that (because everyone has do experience all that by themselves) * Did Bob Martin move anything? (I don't know.)