Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Bienenstock Architektur - Code entkoppeln ohne ...

Richard
September 26, 2023

Bienenstock Architektur - Code entkoppeln ohne dabei von strukturzementierenden Tests aufgehalten zu werden (v1) 🇩🇪 @JUG Saxony Day 2023

Vortrag auf dem JUG Saxony Day 2023

Unser Team hat mehrere große Legacy-Codebasen entkoppelt, ohne durch strukturabhängige Tests gebremst zu werden. Tatsächlich konnten wir unsere geschäftskritischen Tests mühelos erweitern, während wir unsere interne Struktur komplett neu gestalteten, ohne dass unsere Benutzer davon betroffen waren.

Wir taten dies mit einer Variation der hexagonalen Architektur, die wir heute als Bienenstock-Architektur bezeichnen. Die Bienenstock-Architektur definiert die Struktur sowie die Entkopplung und die Testmuster, die dabei helfen, über 10.000 Codezeilen hinaus zu skalieren. Die Struktur besteht aus mehreren gestapelten Hexagonen, die nur über ihre Fassaden miteinander kommunizieren, wodurch sie wie ein großer Bienenstock aussieht.

Dieser Vortrag befasst sich mit den Isolationsmechanismen im Bienenstock, die die Entkopplung selbst großer Anwendungen unterstützen, sowie mit den refactoringfreundlichen Testmustern, die aufgrund der Struktur möglich sind.

Richard

September 26, 2023
Tweet

More Decks by Richard

Other Decks in Programming

Transcript

  1. Slides by richargh.de Der Lebenszyklus von Software 2 Excel-Tabelle Kleines

    System Großes System mit niedriger Qualität Audit Probleme Sanierung Großes System mit hoher Qualität
  2. Slides by richargh.de 4 Dave Farley @davefarley77 The Quality of

    a System is Defined by Our Ability to Change it! Dave Farley, author of the best-selling book “Continuous Delivery”
  3. Slides by richargh.de Most Systems mechanise a human or societal

    activity, are embedded in and modify the real world they model and must change when the real world does1 6 1 “Programs, Life Cycles, and Laws of Software Evolution” - M M Lehman Unzufriedenheit? System Feedback Druck Verhaltens- Änderung
  4. Slides by richargh.de Der paradoxe Legacy Code • Wir müssen

    den Code verändern • Wir haben keine Tests (aka Legacy Code) • Wir haben Angst den Code zu verändern • Wir sollten testen • Aber Tests an der falschen Stelle zementieren unser Design • à Entweder wir können verändern oder wir haben Tests 7
  5. Slides by richargh.de Synergie zwischen Testability und Design Tests geben

    Design Feedback Tests zementieren Design 8 Siehe https://systemsthinking.dev Schlechtes Design Schwierig zu schreibender Test Weniger von Mehr von Design Änderung Ganz viele Tests unbrauchbar Tests
  6. Slides by richargh.de Die Bienenstock-Architektur umfasst 10 Stil Echte Module

    Dekompositionsstrategie Test-Timeline Test-DSL & Contract Tests Test-Stereotypen
  7. Slides by richargh.de Die Bienenstock-Architektur umfasst 11 Stil Echte Module

    Dekompositionsstrategie Test-Timeline Test-DSL & Contract Tests Test-Stereotypen
  8. Slides by richargh.de Ein typisches System verarbeitet Daten* 12 *

    Überraschung! System Daten rein Daten raus Datenfluss im System
  9. Slides by richargh.de Die Datenverarbeitung geschieht in mehreren Schichten 1

    13 1 https://www.martinfowler.com/bliki/PresentationDomainDataLayering.html Daten rein Daten raus Datenfluss im System Data Domain Schicht für die wir bezahlt werden Presentation Notwendige Übel
  10. Slides by richargh.de Datenfluss im System System Wir machen Domain

    Testbar mit Adaptern und Ports1 14 1 Ports & Adapters von Alistair Cockburn https://alistair.cockburn.us/hexagonal-architecture/ Domain Daten rein Daten raus Modul Port Adapter MongoRepo Mongo jsonController Facade
  11. Slides by richargh.de Dann testen wir von außen und nutzen

    Test Doubles 15 1 Ports & Adapters von Alistair Cockburn https://alistair.cockburn.us/hexagonal-architecture/ Port Modul Adapter Ein Test InMemory Repository Facade
  12. Slides by richargh.de Dieser Stil lässt uns dann auf Änderungen

    reagieren1 16 1 Ports & Adapters von Alistair Cockburn https://alistair.cockburn.us/hexagonal-architecture/ Mongo Modul Port Adapter Facade MongoWriteRepo Elastic ElasticReadRepo jsonController csvController
  13. Slides by richargh.de Beispiel eines kleinen Moduls 17 1. export

    interface ForRenting { // Port 2. rent(userId: UserId, itemId: ItemId); 3. } 4. 5. 6. class RentingFacade implements ForRenting { 7. 8. #items: ForWritingItems; // Port 9. 10. rent(userId: UserId, itemId: ItemId){ 11. // do stuff 12. } 13.} <module>/renting.facade.ts RentingFacade ForRenting 1. export interface ForWritingItems { // Port 2. add(item: Item); 3. } 4. 5. 6. class MongoItemRepository // Adapter 7. extends MongoBaseRepository implements ForWritingItems { 8. // do stuff 9. } <module>/internal/items.ts Mongo ItemRepository ForWritingItems Port Name beginnt immer mit For*
  14. Slides by richargh.de Die Bienenstock-Architektur umfasst 18 Stil Echte Module

    Dekompositionsstrategie Test-Timeline Test-DSL & Contract Tests Test-Stereotypen
  15. Slides by richargh.de 19 Glenford J. Myers 95% of the

    words [about software architecture] are spent extolling the benefits of “modularity” and that little, if anything, is said about how to achieve it.
  16. Slides by richargh.de 21 On the Criteria To Be Used

    in Decomposing Systems into Modules – DL Parnas
  17. Slides by richargh.de Maintainability is inversely proportional to the number

    of exposed classes, dependencies, microservices1 22 1 Frei nach Simon Brown
  18. Slides by richargh.de Wir brauchen echte Module • Systeme bestehen

    aus Modulen • Module • Sind Deep (viel Funktionalität hinter simpler Api)1 • Verstecken Informationen, ihre Interna • Greifen nur auf die Api anderer Module zu, nie auf die Interna • Schützen sich vor der Außenwelt mit Ports • Bestehen aus immer kleineren Submodulen, bis runter zu Leafs • Führen Actions 2 aus (Nutzen die Außenwelt) • Oder führen Computations 2 aus (Pur, ohne Auswirkung auf Außenwelt) • Können als einzige ihre Daten schreiben 23 1 A Philosophy of Software Design 2 Grokking Simplicity
  19. Slides by richargh.de Per Konvention zeigen wir wofür ein Top-Level

    Modul ist, was die Api und was internal ist src/features/core/ ├── renting/ │ ├── internal/ │ │ ├── an.action.ts │ │ ├── a.computation.ts │ │ ├── a.port.ts │ │ └── ... │ ├── exposed/ │ │ ├── a.type.ts │ │ └── ... │ ├── a.renting.facade.ts │ └── another.renting.facade.ts 24 Der Zweck des Moduls; Gerne deklariert via Verb internal/ darf nur von Facade genutzt werden Facade und exposed (types) der Facade definieren die Modul Api
  20. Slides by richargh.de Die Facade bietet Flexibilität die interne Modulstruktur

    zu verändern • Facades sind die einzigen Einstiegspunkte von Modulen • Stellen die simple Api nach außen bereit und exposen dafür types • Composen dafür Actions 1 und Computations 1 • Delegieren nur und haben keine Logik (if,map,filter, …) • Können als einzige schreibende Operationen auf Ports etc. ausführen 25 1 Grokking Simplicity Abhängigkeit F A C C C C
  21. Slides by richargh.de Die Bienenstock-Architektur umfasst 26 Stil Echte Module

    Dekompositionsstrategie Test-Timeline Test-DSL & Contract-Tests Test-Stereotypen
  22. Slides by richargh.de 28 Allen Holub @allenholub the key to

    incremental architecture is to build on a framework that can accommodate change, … that framework is the domain itself. By modeling the domain, you can more easily handle changes to the domain.1 1 https://twitter.com/allenholub/status/1099074412530196482
  23. Slides by richargh.de Wir fragen die Domain Experten und teilen

    fachlich 29 System Daten rein Daten raus Datenfluss im System KernFunktion 1 KernFunktion 2 Kern-Entität 1 Kern-Entität 2
  24. Slides by richargh.de Domain Experten liefern die Grundlage für die

    Dekomposition • src/features/core/<modul> • Die Kernmodule sind der Grund warum das System existiert • src/features/supporting/<modul> • Unterstützende Daten für Kern • Kommen von anderen Systemen • src/commons/<modul> • Technischer Code ohne Business Logik • Unsere eigene commons-library • z.B. repository, permissions, base- types 30 Features / Core Features / Supporting Features / Supporting Commons 1 Package by Feature 2 DDD Context Classification at Module Level
  25. Slides by richargh.de Unser Bienenstock wächst 31 Features / Supporting

    Features / Supporting Features / Supporting Commons Features / Core Features / Core Features / Core
  26. Slides by richargh.de Bis wir ihn dann in Systeme splitten1

    32 1 Situativ, Monolith aus echten Modulen sind sehr angenehm. Das Aufsplitten will gut begründet sein. Features / Supporting Features / Supporting Features / Supporting Commons Features / Core Features / Core Features / Core Features / Supporting Commons Features / Core Features / Supporting
  27. Slides by richargh.de Group together what fires together 1 Feature,

    1 Commit, 1 Modul 33 Frei nach der Hebbschen Lernregel
  28. Slides by richargh.de Wir gewinnen je weniger wir preisgeben High

    Coupling Low Cohesion1 Low Coupling High Cohesion1 34 Dependency 1 Unbekannte Quelle Module
  29. Slides by richargh.de Die Bienenstock-Architektur umfasst 35 Stil Echte Module

    Dekompositionsstrategie Test-Timeline Test-DSL & Contract-Tests Test-Stereotypen
  30. Slides by richargh.de 37 Testkosten Schreibzeit Feedbackzeit Kompliziertes Test- Harness

    Gutes/Schlechtes Design Wartungszeit Zementiertes Design Code- Änderungen Lesbarkeit, gerade bei roten Tests Ausführungs- zeit
  31. Slides by richargh.de 38 1 Echte Werte aus einem ts-node

    + Jest Projekt - 2 Tests parallelisiert - 3 Paralellisiert, da geht aber noch was 4 könnte mit anderem Setup wahrscheinlich auf 10ms gedrückt werden Wie teuer ist das Feedback? 0 Ausführungszeit Pro Test1 Small2,4 50 ms/Test 200 ms/Test Medium2 3,9 s/Test Large3
  32. Slides by richargh.de Test Sizes1, nicht Bike-Shedding 39 1 Google

    Test Sizes https://testing.googleblog.com/2010/12/test-sizes.html Feature Network access Database File system access Use external system Multiple threads Sleep statements System properties Time limit (seconds) Außenwelt Small No No No No No No No 60 Medium Localhost only Yes Yes Discouraged Yes Yes Yes 300 Large Yes Yes Yes Yes Yes Yes Yes 900+
  33. Slides by richargh.de Die Außenwelt, auf der ein ganzes System

    steht, nennen wir Floor 40 Modul Floor Mongo MongoRepo Other Services SocketIo RabbitMq
  34. Slides by richargh.de 41 Michael Feathers @mfeathers Write tests where

    you want your module boundaries to be. Writing them any other place just shifts the boundary — and your modularization. https://twitter.com/mfeathers/status/1585720577477615616
  35. Slides by richargh.de Tests auf der richtigen Ebene: Flexibilität in

    der internen Modulstruktur • Small (Scope) Tests laufen in-process • Ports implementiert von Test Doubles • Wir testen viel outside-in • Es gibt • Facade Tests • Top-Module Action & Calculation Tests • Leaf Tests • Keine Tests im “Murky Middle”, da Struktur-zementierend 42 1 Grokking Simplicity Abhängigkeit
  36. Slides by richargh.de Das Ziel der Tests ist Abhängig vom

    Scope1 • Small Tests pro Modul • (Business) Logik funktioniert • Kleiner Scope, spezifische Assertions • Medium (Contract) Tests für Adapter • Floor Adapter funktioniert • Large Tests für Api, FE+BE • Für den Anwender funktioniert alles • Performant machen mit Test Data Aliasing oder Mandantenfähigkeit • Großer Scope, grobe Assertions 43 1 Google Test Sizes https://testing.googleblog.com/2010/12/test-sizes.html
  37. Slides by richargh.de 44 1 Kleine Differenzen zu, aber im

    Kern => Urs Enzler – Die Agile Testpyramide https://www.youtube.com/watch?v=-35GpOJnjmM Zeit1 Test-Driven Facade Tests Top-Level A&C Tests Leaf Tests Floor Adapter Tests Test-After Smoke Tests Api/FE+BE Tests Exploratory Tests Load & Soak Tests Monitoring & Alerting REDS Rate Errors Delay Saturation Nachdenken Wenige Viele Roof Floor
  38. Slides by richargh.de Die Bienenstock-Architektur umfasst 46 Stil Echte Module

    Dekompositionsstrategie Test-Timeline Test-DSL & Contract Tests Test-Stereotypen
  39. Slides by richargh.de Test-Smells • Langsamer Test • Länger Warten

    à Weniger ausgeführte Tests à Weniger getestete Fachlichkeit à Weniger Refactoring • Langer Test • Viel zu lesen, viele versteckte Fehler • Irrelevante Details • Muss es ein bestimmtes Buch sein oder ist jedes möglich? • Muss dieses Feld den Wert haben, damit der Test erfolg hat? • Struktur-zementierende Tests • Domain Entitäten von Hand erstellt, neue Felder nicht hinzufügbar • In vielen Tests wird redundant die gleiche Methode gemockt 48 1 http://xunitpatterns.com/Test%20Smells.html 2 Art of Unit Tests – 3rd Edition
  40. Slides by richargh.de Langer Test voller irrelevanter Details 49 1.

    2. 3. 4. 5. test(‘should be able to rent book’, () => { 6. // GIVEN 7. const book = new Item(id: “1”, “Refactoring”, “Martin Fowler”); 8. const permission = new Permission(id: “1”, “CAN_RENT_BOOK”); 9. const role = new Role(id: “1”, “Renter”, [permission.id]); 10. const user = new User(id: “1”, “Alex Mack”, role.id); 11. 12. const items = new InMemoryItemsDouble(item); 13. const permissions = new InMemoryPermissionsDouble(permission); 14. const roles = new InMemoryRoleDouble(role); 15. const users = new InMemoryUsersDouble(user); 16. 17. const testee = new RentingFacade(new ClockDouble(), items, permissions, roles, users, …); 18. // WHEN 19. const result = testee.rentBook(book, user); 20. // THEN 21. expect(result.isRented).toBeTrue(); 22.} <module>/a.small.test.ts Versteckt hier unten ist was wir eigentlich testen Welche der Parameter sind tatsächlich relevant? Weitere unnötige Details Duplizierte initialisierung zementiert Struktur
  41. Slides by richargh.de Mit einer TestDsl zu verständlichen und wartbaren

    Tests 50 1. // create the low-level test-DSL 2. // small test, all floor ports are now stubs or fakes, they never connect to the real world 3. const { a, floor } = smallTest().withoutState().buildDsl(); 4. 5. test(‘should be able to rent book’, () => { 6. // GIVEN 7. const book = a.book(); // I need a book, don’t care which 8. const { user } = a.userBundle(it => it.hasPermission(“CAN_RENT_BOOK”); // a user, don’t care who 9. 10. await a.saveTo(floor); // store book and user entities in floor 11. 12. const testee = rentingFacadeWith(floor); // configure renting facade to use floor 13. // WHEN 14. const result = testee.rentBook(book, user); 15. // THEN 16. expect(result.isRented).toBeTrue(); 17.} <module>/a.small.test.ts
  42. Slides by richargh.de Mit einer TestDsl zu verständlichen und wartbaren

    Tests 51 1. // create the low-level test-DSL 2. // most floor ports now use real world 3. const { a, floor } = mediumTest().withoutState().buildDsl(); 4. 5. test(‘should be able to rent book’, () => { 6. // GIVEN 7. const book = a.book(); // I need a book, don’t care which 8. const { user } = a.userBundle(it => it.hasPermission(“CAN_RENT_BOOK”); // a user, don’t care who 9. 10. await a.saveTo(floor); // store book and user entities in floor 11. 12. const testee = rentingFacadeWith(floor); // configure renting facade to use floor 13. // WHEN 14. const result = testee.rentBook(book, user); 15. // THEN 16. expect(result.isRented).toBeTrue(); 17.} <module>/a.medium.test.ts
  43. Slides by richargh.de Mit der DSL vermeiden wir type-zementierende, weil

    duplizierte, Initialisierung 52 Test 1 new Item(“1”, “Abc”, …) Test 2 new Item(“2”, “Bcd”, …) Test … new Item(“3”, “Cde”, …) Test n new Item(“n”, “Xyz”, …) Die duplizierte Initialisierung zementiert das Design vom Type class Item { … }
  44. Slides by richargh.de Small Tests nutzen, trivial zu schreibende, InMemory

    Fakes 53 ForWritingItems 1. export interface ForWritingItems { // Port 2. add(item: Item); 3. } <module>/internal/items.ts InMemory ItemsDouble 1. export class InMemoryItemsDouble // test double 2. implements ForWritingItems { 3. 4. #allItems: Item[] = []; 5. 6. add(item: Item){ 7. this.allItems.push(item); 8. } 9. } fixtures/<module>/in-memory-items.ts GOH Good Old Handcraft
  45. Slides by richargh.de Doch verhalten sich die Fakes wie der

    Produktionscode? Halten sich beide Implementierungen an den selben Contract? 54
  46. Slides by richargh.de Synchron halten mit Contract Tests1,2,3 55 1

    J.B. Rainsbergers Original Post https://blog.thecodewhisperer.com/permalink/getting-started-with-contract-tests 2 Meine Kotlin Variante http://richargh.de/posts/Contract-Tests-in-Kotlin 3 Alternativer Name, Role Tests https://codesai.com/posts/2022/08/role-tests-jest 1. export interface ForWritingItems { // Port 2. add(item: Item); 3. } 4. 5. export interface ForReadingItems { // Port 6. getById(id: ItemId): Item; 7. } <module>/internal/items.ts 1. const implementations = [ 2. [() => new InMemoryItemsDouble()], // Fake 3. [() => new MongoItems()] // Real 4. ]; 5. 6. describe.each(implementations, (configure) => { 7. test(‘a saved item can be retrieved’, () => { 8. // GIVEN 9. const testee = configure(); 10. const item = a.item(); 11. // WHEN 12. testee.add(item); 13. // THEN 14. const result = testee.getById(item.id); 15. expect(result).toEqual(item); 16. }); 17.}); tests/<module>/items.contract.ts
  47. Slides by richargh.de Die Bienenstock-Architektur umfasst 56 Stil Echte Module

    Dekompositionsstrategie Test-Timeline Test-DSL & Contract Tests Test-Stereotypen
  48. Slides by richargh.de Bei Fire&Forget Ports setzen wir auf NoopDoubles

    57 ForMobilePush 1. export interface ForMobilePush { // Port 2. push(event): void; 3. } commons/mobile-push/mobile-push-facade.ts MobilePush NoopDouble 1. export class NoopMobilePushDouble 2. implements ForMobilePush { 3. 4. push(event): void { 5. // noop J 6. } 7. } fixtures/commons/mobile-push /noop-mobile-push.double.ts
  49. Slides by richargh.de Bei Ports dessen Return der Test steuern

    muss, setzen wir auf EchoDoubles 58 ForAuthentication 1. export interface ForAuthentication { // Port 2. authenticate(user: User): Token; 3. } capi/auth/authentication.facade.ts Echo AuthenticationDouble 1. export class EchoAuthenticationDouble 2. implements ForAuthentication { 3. 4. constructor( 5. #authenticateEcho: Token = someToken()){ } 6. 7. authenticate(user: User){ 8. return #authenticateEcho; 9. } 10.} fixtures/capi/auth /echo-authentication.dobule.ts Keine ifs, keine Logik.
  50. Slides by richargh.de Bei Ports die wichtige Parameter bekommen nutzen

    wir SpyingDoubles 59 ForAuthentication 1. export interface ForWritingEvents { // Port 2. emit(event: Event): void; 3. } commons/events/events.facade.ts Authentication EchoDouble 1. export class SpyingEventsDouble 2. implements ForWritingEvents { 3. 4. #events: Event[] = []; 5. 6. emit(event: Event): void; 7. this.#events.push(event); 8. } 9. 10. eventsOfType(type: EventType): Event[] { 11. // … 12. } 13.} fixtures/commons/event /spying-events.double.ts
  51. Slides by richargh.de Generell vermeiden struktur-zementierendes, weil dupliziertes, Mocking 60

    Test 1 mockObject<SamePort> Test 1 mockObject<SamePort> Test … mockObject<SamePort> Test n mockObject<SamePort> SamePort Die Duplikation zementiert das Design vom Port
  52. Slides by richargh.de Übermäßiges Mocking hat Probleme, situatives ist praktisch

    • Startup Zeit des Mocking-Frameworks • Struktur-Zementierendes Mock-Setup • x Tests die die selbe Methode “mocken” • Behindern dann Strukturveränderungen dieser Methode • In 95% der Fälle brauchen wir keinen Mock1 • Bei Repos brauchen wir einen (InMemory) Fake • Bei Events einen Spy • Meistens einen (Echo) Stub • Nur bei 3rd Party Services brauchen wir manchmal einen Mock2 61 1 https://martinfowler.com/articles/mocksArentStubs.html 2 Art of Unit Testing
  53. Slides by richargh.de Unterschiedliche Test-Stereotypes, alle fördern eine softe Struktur

    62 1 http://xunitpatterns.com/Test%20Double%20Patterns.html Port Prod Test Double1 Mock1 Test-Stereotypes (Good Old Handcraft) Fake1 InMemory Stub1 (Spying)Noop (Spying)Echo Spy1 Port-Änderungen nur an einer Stelle nötig
  54. Slides by richargh.de Recompose Legacy 65 Fachliches Decompose Halbechte Module

    (viele interna noch exposed) Medium Facade-Tests Echte Module Mit Small Facade Tests
  55. Slides by richargh.de Bienenstock Architektur… Fordert • Echte Module •

    Entkopplung • Findable SW Architecture • Test-Dsl, Doubles und Contracts Bietet • Tests die • Struktur-flexibel • Schnell • Verlässlich • Geringer Wartungsaufwand • Wachsen mit Legacy Code mit 66
  56. Slides by richargh.de Dankeschön 67 Richard Gross (he/him) richargh.de/ speakerdeck.com/richargh

    @arghrich Works for maibornwolff.de/ People. Code. Commitment. DE TN ES Archaeologist Auditor Hypermedia- Designer
  57. Slides by richargh.de Alternative Stile • Hexagonale Architektur nach eigenen

    Wünschen • A-Frame Architecture und Nullable Infrastructure • Test-Timeline 3,4 72 3 Die agile Testpyramide https://www.youtube.com/watch?v=-35GpOJnjmM 4 Architektur, aber bitte agil! https://www.youtube.com/watch?v=12q6LDM8DIY
  58. Connascence als Refactoringhilfe 2 elements A,B are connascent if there

    is at least 1 possible change to A requires a change to B in order to maintain overall correctness Jim Weirich‘s “Grand Unified Theory of Software Development” J Meilir Page-Jones
  59. Connascence of Meilir Page-Jones | Jim Weirich‘s “Grand Unified Theory

    of Software Development” J • Name: variable, method, SQL Table • Type: int, String, Money, Person • Meaning: what is true,‘YES‘,null,love • Position: order of value • Algorithm: encoding, SPA vs Server • Execution (order): one before other • Timing: doFoo() in 500ms | doBar() in 400ms • Value: constraints on value, invariants • Identity: reference same entity Weak Strong Static Dynamic
  60. Connascence of Meilir Page-Jones | Jim Weirich‘s “Grand Unified Theory

    of Software Development” J • Identity • Value • Timing • Execution order • Algorithm • Position • Meaning • Type • Name Strong Weak Refactor this way
  61. Connascence of Name Jim Weirich‘s “Grand Unified Theory of Software

    Development” J Komponente Komponent e doSth(..) doFoo(…)
  62. Connascence of Meaning Jim Weirich‘s “Grand Unified Theory of Software

    Development” J Komponente Komponent e doSth(5) doFoo(true)
  63. Locality is important Jim Weirich‘s “Grand Unified Theory of Software

    Development” J Komponente Komponent e doSth(5) doFoo(true)
  64. Local can be stronger Jim Weirich‘s “Grand Unified Theory of

    Software Development” J Komponente Komponent e doSth(5) doSpecialFoo()
  65. 3-axes of Connascence Strength Level How explicit Locality How close

    Degree Number of Impacts Meilir Page-Jones | Jim Weirich‘s “Grand Unified Theory of Software Development” J
  66. Slides by richargh.de A Set of Unit Testing Rules A

    test is not a unit test if: • It talks to a database • It communicates across the network • It touches the file system • It can't run at the same time as any of your other unit tests • You have to do special things to your environment (such as editing config files) to run it. Tests that do these things aren't bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes. 93 1 A Set of Unit Testing Rules https://www.artima.com/weblogs/viewpost.jsp?thread=126923
  67. Slides by richargh.de 94 Dave Farley @davefarley77 High-quality code is

    modular, loosely-coupled, has high-cohesion, good separation of concerns, and exhibits information- hiding. https://pages.xebia.com/whitepaper-test-driven-development-is-not-about-unit-tests
  68. Slides by richargh.de Encapsulation • Ein objekt guarantiert, dass es

    immer in einem erlaubten Zustand ist • Vorbedingungen beschreiben die Veranwortlichkeit des Aufrufenden • Nachbedingungen beschreiben die Verantwortlichkeit des Objkets 95