Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Evolving architecture 4 Confitura 2017

734 views

Published on

During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.

  • Be the first to comment

  • Be the first to like this

Evolving architecture 4 Confitura 2017

  1. 1. Evolving Architecture @dpokusa
  2. 2. Document A B C
  3. 3. Document A B CDocumentFactory
  4. 4. Document A B CDocumentFactory AbstractDocumentFactory
  5. 5. Document A B CDocumentFactory AbstractDocumentFactory SectionA SectionB
  6. 6. Document A B CDocumentFactory AbstractDocumentFactory SectionA SectionB Decorated A
  7. 7. fot. Iza Janoszek, Radio Eska
  8. 8. Overdesign
  9. 9. DIE
  10. 10. DRYDIE
  11. 11. https://commons.wikimedia.org/wiki/File:Tecnology_Life_Cycle.png
  12. 12. UNDERDESIGN
  13. 13. KISS
  14. 14. YAGNIKISS
  15. 15. COMMONS
  16. 16. COMMONS UTILS BASE GENERAL STUFF SHARED POPULAR VARY GLOBAL
  17. 17. A COMMONS CA B
  18. 18. Quality means doing it right when no one is looking - Henry Ford
  19. 19. CZAS FUNKCJONALNOŚĆ ZASOBY
  20. 20. CZAS FUNKCJONALNOŚĆ ZASOBY
  21. 21. CZAS FUNKCJONALNOŚĆ ZASOBY
  22. 22. CZAS FUNKCJONALNOŚĆ ZASOBY
  23. 23. JAKOŚĆ CZASFUNKCJONALNOŚĆ ZASOBY
  24. 24. JAKOŚĆ CZASFUNKCJONALNOŚĆ ZASOBY
  25. 25. JAKOŚĆ CZASFUNKCJONALNOŚĆ ZASOBY
  26. 26. JAKOŚĆ CZASFUNKCJONALNOŚĆ ZASOBY
  27. 27. JAKOŚĆ CZASFUNKCJONALNOŚĆ ZASOBY
  28. 28. QUALITY
  29. 29. TECHNOLOGY FREEDOM
  30. 30. TECHNOLOGY PRISON
  31. 31. READABILITY CONSIDERATIONS
  32. 32. 1. Podejmuj decyzje najpóźniej jak to możliwe,
  33. 33. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
  34. 34. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości,
  35. 35. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny,
  36. 36. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny, 5. Nigdy nie zapominaj o refaktoryzacji,
  37. 37. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny, 5. Nigdy nie zapominaj o refaktoryzacji, 6. Nie traktuj testów jako odrębnego bytu,
  38. 38. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny, 5. Nigdy nie zapominaj o refaktoryzacji, 6. Nie traktuj testów jako odrębnego bytu, 7. "Scrappy" zostanie na dłużej niż sądzisz,
  39. 39. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny, 5. Nigdy nie zapominaj o refaktoryzacji, 6. Nie traktuj testów jako odrębnego bytu, 7. "Scrappy" zostanie na dłużej niż sądzisz, 8. Pisz biblioteki, nie frameworki,
  40. 40. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny, 5. Nigdy nie zapominaj o refaktoryzacji, 6. Nie traktuj testów jako odrębnego bytu, 7. "Scrappy" zostanie na dłużej niż sądzisz, 8. Pisz biblioteki, nie frameworki, 9. Spróbuj zrozumieć biznes,
  41. 41. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny, 5. Nigdy nie zapominaj o refaktoryzacji, 6. Nie traktuj testów jako odrębnego bytu, 7. "Scrappy" zostanie na dłużej niż sądzisz, 8. Pisz biblioteki, nie frameworki, 9. Spróbuj zrozumieć biznes, 10. Jeśli tylko możesz -> DDD i TDD,
  42. 42. 1. Podejmuj decyzje najpóźniej jak to możliwe, 2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy, 3. Klient zawsze oczekuje jakości, 4. Kod powinien być czytelny, 5. Nigdy nie zapominaj o refaktoryzacji, 6. Nie traktuj testów jako odrębnego bytu, 7. "Scrappy" zostanie na dłużej niż sądzisz, 8. Pisz biblioteki, nie frameworki, 9. Spróbuj zrozumieć domenę biznesową, 10. Jeśli tylko możesz -> DDD i TDD, 11. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość.
  43. 43. ABOUT software-empathy.pl @dpokusa
  44. 44. @dpokusa ABOUT SPREADIT.PL 18.11.2017
  45. 45. @dpokusa ABOUT
  46. 46. Q&A

×