Your SlideShare is downloading. ×
Patterns for organic architecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Patterns for organic architecture

1,052
views

Published on

Published in: Software

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,052
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Wzorce organicznej architektury Pamiętnik szaleńca
  • 2. Kim jestem work://chief_architect@lumesse owner://symentis.pl twitter://j_palka blog://geekyprimitives.wordpress.com scm:bitbucket://kcrimson scm:github://kcrimson
  • 3. Co społeczeństwo myśli o mnie?
  • 4. Co moja żona myśli o mojej pracy?
  • 5. Co ja tak naprawdę robię?
  • 6. ~ 8 firm w przeciągu 16 lat ~ 26 projektów
  • 7. … i tylko jeden projekt budowany od podstaw ...
  • 8. Jak się z tym czuje?
  • 9. I am feelingI am feeling lucky!lucky!
  • 10. Czego się dziś nie dowiem? Która kombinacja wzorców, xDD, języków, frameworków i paradygmatów gwarantuje sukces
  • 11. Dowiem się za to jak nie oszaleć... Pracując z monolityczną, odziedziczoną, masą kodu, który zbliża się do granic wytrzymałości, by za chwilę zapaść się pod własnym ciężarem, tworząc czarną dziurę, która pochłonie wszystkich żywych programistów w okolicy
  • 12. We are living in a ... Big Ball of Mud
  • 13. Autogenerated Stovepipe Stovepipe Enterprise Jumble Stovepipe System Cover Your Assets Vendor Lock-In Wolf Ticket Architecture by Implication Warm Bodies Design by Committee Swiss Army Knife Reinvent the Wheel The Grand Old Duke of York
  • 14. Co łączy te wszystkie przypadki?
  • 15. Złożoność
  • 16. Dowód?
  • 17. „I fucking love science”
  • 18. Myślenie systemowe System dynamics Teorie złożoności Strange Attractor
  • 19. The Gap
  • 20. Jak organizacje sobie z tym radzą?
  • 21. Może by tak zatrudnić więcej studentów?
  • 22. Przepiszmy to wszystko... (najlepiej w technologi i na platformę o której nie mamy zielonego pojęcia)
  • 23. Dlaczego?
  • 24. Czas? Kilka „extra feature” na które wszyscy czekali? Nadmierna wiara w siłę sprawczą technologii? Projekty często postrzegane jak czysto techniczne? Ignorancja? Arogancja?
  • 25. A może by tak?
  • 26. The Gap
  • 27. Wzorce organicznej architektury
  • 28. Architektura to proces który ma na celu transformację twojego systemu
  • 29. Architektura to proces który ma na celu transformację twojego systemu
  • 30. Architektura to proces który ma na celu transformację twojego systemu
  • 31. Gap ↓ Context ↓ Constraints
  • 32. You can't control what you can't measure Tom DeMarco, Controlling Software Projects,
  • 33. You can't Reason about what you can't measure
  • 34. Miara jakości architektury?
  • 35. Complexity Resilience
  • 36. Source code the truth will tell you
  • 37. Listen to the system you must
  • 38. SCM Bug tracker Continous integration Static code analisys
  • 39. Znajdźmy stabilne obszary systemu
  • 40. # count complexity per each file find. -inamejacoco.csv |xargstail -q-n+2 |awk -F , '{gsub(".","/",$2);print($1"/src/main/java/"$2"/"$3".java"),$10+$11}' |sort>coverage.txt # count number of changes echo 'changeset="{files}"' >files.style; echo'file="n{file}"' >>files.style hglog--stylefiles.style |sort |uniq-c |awk '{print$2,$1}' >changes.txt # mergechanges joincoverage.txtchanges.txt
  • 41. Michael Feathers Quadrant
  • 42. publicenumQuadrant{ /** * low complexity, little changes - simple utilities. * / tools, /** * simple yet frequently touched area of your code. Core of it, yet done well * and expanding. New features grow, new classes are extracted, complexity * is kept at bay. Keep it that way! * / breedinggrounds, /** * Ugly files but stable - written once for specific purpose, which they * fulfill well enough. High complexity makes them risky to touch, but is * there any need to? * * Ugly Stables also because of Hercules and Augias's stables... ;-) * / uglystables, /** * Code fitting here is fraught with complexity and changed often. Meaning, * you either didn't got the client's needs right and need to make lotsa * changes now, or you mis-designed and now have to work around it. * Or there's simply a number of bugs... * / designflaw }
  • 43. tools uglystables designflaw breedinggrounds
  • 44. Znajdźmy kruche obszary systemu
  • 45. #fetch all jobs jobs_rsp=requests.get( "https://primitive.ci.cloudbees.com/job/roadrunner/api/python") #all buildsurls build_urls=[x['url'] for x ineval(jobs_rsp.content)['builds']] pairs=[] for build_url inbuild_urls: build=eval(requests.get("%sapi/python" %(build_url)).content) result=build['result'] changeSetItems=build['changeSet']['items'] if changeSetItemsandnotresult=='SUCCESS': affectedPaths=build['changeSet']['items'][0]['affectedPaths'] for i initertools.permutations(affectedPaths,2): pairs.append(i) counter =collections.Counter(pairs).most_common(5) for pair incounter: printpair
  • 46. (('.../cli/CliConfigurationBuilderTest.java', '.../cli/RunTest.java'), 3) (('.../cli/RunTest.java', '.../cli/CliConfigurationBuilderTest.java'), 3) (('.../cli/CliConfigurationBuilderTest.java', '.../cli/BenchTest.java'), 3) (('.../cli/BenchTest.java', '.../cli/RunTest.java'), 3) (('.../cli/RunTest.java', '.../cli/BenchTest.java'), 3)
  • 47. Czy ja to wszystko dobrze spakowałem? Package principles aka Coś tu za chwilę wyleci w powietrze
  • 48. (echo"<changes>" && hglog--template "<changeset> {files%'<file>{file}</file>n'} </changeset>n" && echo"</changes>") >out.xml
  • 49. + Neo4j
  • 50. neo4j-sh (?)$ MATCH (a)-[c:`changeset`]->(b) RETURN labels(a),c.times,labels(b) order by c.times desc limit 5; +-----------------------------------------------------------------------------------------------------------+ | labels(a) | c.times | labels(b) | +-----------------------------------------------------------------------------------------------------------+ | [".../listeners/SummaryScenarioListener.java"] | 13 | [".../listeners/LoggingScenarioListener.java"] | | [".../listeners/LoggingScenarioListener.java"] | 13 | [".../listeners/SummaryScenarioListener.java"] | | ["pom.xml"] | 12 | ["roadrunner-core/pom.xml] | | [".../cli/BenchTest.java"] | 12 | [".../cli/RunTest.java"] | | [".../cli/RunTest.java"] | 12 | [".../cli/BenchTest.java"] | +-----------------------------------------------------------------------------------------------------------+
  • 51. To gdzie te wzorce organicznej architektury?
  • 52. Zasiej i pielęnguj
  • 53. „aka” refactoring kompulsywny „refactoring” to zło unikaj „historyjek” typu „zrefaktoryzować X” zanim zaczniesz, zastanów się czy warto nie pytaj o pozwolenie, raczej proś o przebaczenie nadaj „technical debt” znaczenie
  • 54. „visual management” wyznacz tylko kilka miar jakości Tylko te które wspierają twoje cele ponieważ „You get what you measure”
  • 55. Zasiej i zbierzZasiej i zbierz
  • 56. „aka” modularyzacja modularyzuj do stabilnych elementów systemów zanim jednak zaczniesz ...
  • 57. … zbuduj „framework” ...
  • 58. Architektura to proces który ma na celu transformację twojego systemu
  • 59. … musisz mieć jasno określony cel … … strategia dobrana do potrzeb i możliwości … … daj sobie przestrzeń na zmianę zdania … nie daj się znowu sparaliżować „big design (tm)” … gdyż twój cel może się zmienić ...
  • 60. co jeśli twój „big design (TM)” wyglądałby tak...
  • 61. procesy wsadowe (batch) odseparowane moduły komunikują się ze sobą asynchronicznie Użytkownicy widzą system jako jedność i komunikują się synchronicznie Jedyne co współdzielimy w systemie to mentalny model mvn clean install < 60 sekund
  • 62. Każdy moduł musi dziedziczyć kontekst i ograniczenia Może też wprowadzać specyficzne, lokalne ograniczenia w kontekście poszczególnych modułów
  • 63. Kompostowanie
  • 64. Czasami mimo wysiłków, pracy... i szczerych chęci Którymi piekło jest wybrukowane
  • 65. Complexity
  • 66. Czy wiesz jak twoi użytkownicy korzystają z systemu? Czy wiesz że twój „kluczowy” klient nie korzysta już z systemu od 5 lat? Czy wiesz że „killer feature” nie zachwycił rynku a ty ciągle utrzymujesz ten kod?
  • 67. Skąd ja mam to wiedzieć?
  • 68. /var/log/httpd/access.log Zinstrumentuj kod? Aspekty? Byteman? Bug tracker? Ludzie z utrzymania?
  • 69. Nie inwestuj w drogie narzędzia Będziesz czekał miesiącami na „approval” A potem narzędzie i tak zawiedzie twoje oczekiwania :) Zainwestuj w kreatywność
  • 70. Tylko proszę bez „wykomentowania” kodu Twój SCM będzie pamiętał … po prostu wyrzuć to...
  • 71. Czas podsumowań
  • 72. Hierarchy ↓ Self-Organization ↓ Resilience
  • 73. System's resilience is often sacrificed for purposes of short-term productivity and stability.
  • 74. Productivity and stability are the usual excuses for turning creative human beings into mechanical adjuncts to production processes.
  • 75. Or for establishing bureaucracies and theories of knowledge that treat people as if they were only numbers. Donella Meadows, thinking in systems a primer
  • 76. Dziękuję!!!