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.

Systematyczny architekt na drodze ku planowanemu postarzaniu

795 views

Published on

Czym jest planowane postarzanie produktu? Zapewne wielu z was spotkało się z tym określeniem, oznaczającym planowane działania mające na celu skrócenie czasu życia produktu na rynku, w mniej lub bardziej szczytnym celu. Jak to się ma do tworzenia oprogramowania?

Być może nie tak planowane, jak często chaotyczne, jednak ciągle mamy do czynienia z nieustannym procesem postarzania naszych bibliotek, kontenerów aplikacji, języków, narzędzi i API. oprócz sil wywieranych przez biznes na naszą aplikację, jest ona też po wpływem potężnych ruchów technologicznych, wynikających z nieustannych zmian w trendach tworzenia oprogramowania. Jak efektywnie uniknąć powolnego postarzania się technologicznego naszej aplikacji? Jak uniknąć wysokich kosztów, odkładanych w nieskończoność modernizacji technologicznych aplikacji? Jak uzasadnić wartość biznesową kolejnego "big up front total next generation rewrite"?

A może by tak uwolnić się od hegemoni frameworków, bibliotek i kontenerów i oddać całą władzę w ręce programistów?

Podczas prezentacji opowiem jak ważnym elementem tej strategi są właściwe "abstrakcje w kontekście", jak efektywnie oddzielić "software construction" od "infrastructure code" i "business logic" i dlaczego właściwa architektura, która pozwala podjąć decyzje technologicznie jak najpóźniej, lub nawet odłożyć je na jutro, które nie nadejdzie, może pomóc wam i przyszłym pokoleniom, tych którzy będą musieli pracować z kodem odziedziczonym po was.

Published in: Software
  • Be the first to comment

Systematyczny architekt na drodze ku planowanemu postarzaniu

  1. 1. Systematyczny aarrcchhiitteekktt nnaa ddrrooddzzee kkuu ppllaannoowwaanneemmuu ppoossttaarrzzaanniiuu
  2. 2. O mnie : Jarosław Pałka
  3. 3. • chief architect @ Lumesse • owner/founder/one man orchestra @ symentis.pl • blogger @ geekyprimitives.wordpress.com • philosopher @ twitter:j_palka • code mangler @ bitbucket:kcrimson & github:jpalka • evil emperor @ 4developers conf/architecture track • restrained Padawan @ church of JVM
  4. 4. „Created weakness for the numbers on the board Absurd amount of things, obsolete creation The lust for always more, indulgence in hunger A greed for power, the demon needs to feed … Designed for failure” Gojira – Planned Obsolescence
  5. 5. „strategia producenta, mająca na celu takie projektowanie towarów, aby miały one ograniczony czas użytecznego życia, po tym zaś okresie stawały się niesprawne, a często nieopłacalne w naprawie. Towary te zwykle psują się zaraz po upływie gwarancji.” Wikipedia
  6. 6. Techniki „planowanego” postarzania … nowy lepszy paradygmat … … nowa wersja biblioteki … … nowy język programowania … … nowe lepsze API ... … brak kompatybilności wstecznej …
  7. 7. Jakby tego było mało trendy
  8. 8. „We are fashion industry” Uncle Bob
  9. 9. Rewrite Offload Modernization Next Generation Something™
  10. 10. Kilka lat później
  11. 11. Rewrite Offload Modernization Next Generation Something™
  12. 12. Organizacje dostają wysypki na samą myśl o kolejnym offload, rewrite, NG projekcie
  13. 13. Dobry inżynier, Idź szukaj business value, szukaj
  14. 14. Podejście Big-Bang Uczymy się na żywym organizmie Ludzie z businessu trzymają się na dystans Brak zrozumienia domeny problemu
  15. 15. „It is up to us to live up to the legacy that was left for us, and to leave a legacy that is worthy of our children and of future generations.” Christine Gregoire
  16. 16. Nie naprawimy przeszłości, Ale możemy uczynić przyszłość lepszą
  17. 17. Mózg, co będziemy dziś robić?
  18. 18. Dodamy kolejny framework!
  19. 19. Przygotujmy się na lepszą przyszłość Przygotujmy się na zmiany
  20. 20. Abstrakcje
  21. 21. Posługujemy się nimi na co dzień Są zapisane w naszej podświadomości Dlatego tak trudno o nich rozmawiać
  22. 22. Polimorfizm
  23. 23. Znaczenie ukryte za fasadą słów
  24. 24. „Czy mógłbyś otworzyć zamek?” Brak jednoznaczności abstrakcji
  25. 25. Znaczenie = abstrakcja(kontekst)
  26. 26. public interface TalkingAboutAbstractions{ public void createEmployee(String candidate); }
  27. 27. public vois hireCandidate(){ String candidate = "Jan Kowalski"; employeeBean.createEmployee(candidate); candidate = "<candidate><id>123456</id></candidate>"; employeeBean.createEmployee(candidate); candidate = "{ candidate : {id : "123456"} }"; employeeBean.createEmployee(candidate); }
  28. 28. public interface TalkingAboutAbstractions{ public Employee hireCandidate(Supplier<Candidate >candidate); }
  29. 29. public interface GuessWhatIHaveInMind{ String serverStatus() throws Exception; }
  30. 30. „OK” „Mam się dobrze” „Cholera gdzie jest dysk?” „Daj mi spokoój” „!@#$%^&*()”
  31. 31. public interface GuessWhatIHaveInMind{ public enum ServerStatus { OK, BUSY, INTERNAL_ERROR } ServerStatus serverStatus() throws Exception; }
  32. 32. A teraz czas na coś z klasyki Prawdziwy, Autentyczny, jedyny
  33. 33. Brainfuck
  34. 34. public class BrainFuck extends GenericHibernateDAO{ List<Object[]> processList(String target, Long id); }
  35. 35. public class BrainFuck extends GenericHibernateDAO{ ResultSet processList(String target, Long id); }
  36. 36. Use types, Luke!
  37. 37. Buisness logic & system construction & code infrastructure
  38. 38. public class SoftwareConstruction<K,V> implements BeanFactoryAware, DisposableBean { @Override @SuppressWarnings("unchecked") public void setBeanFactory(final BeanFactory beanFactory) throws BeansException { consumerConfigurations = (Map<String, ConsumerConfiguration<K,V>>) (Object) ((ListableBeanFactory) beanFactory).getBeansOfType(ConsumerConfiguration.class); } }
  39. 39. Nie mieszajmy odpowiedzialności Odpowiedzialność to nie tylko „business features” Obiekt nie może być odpowiedzialny za skonstruowanie samego siebie
  40. 40. public interface ShowMeMore{ @GET public Response getRoot( @Context HttpServletRequest request); }
  41. 41. public class ShowMeMoreImpl implements ShowMeMore{ @Context private HttpServletRequest request; @GET public Response getRoot(); }
  42. 42. Struktura systemu
  43. 43. Gęstość informacji
  44. 44. „Hierarchies are brilliant systems inventions, not only because they give a system stability and resilience, but also because they reduce the amount of information that any part of the system has to keep track of.”
  45. 45. „Hierarchies are brilliant systems inventions, not only because they give a system stability and resilience, but also because they reduce the amount of information that any part of the system has to keep track of.”
  46. 46. „In hierarchical systems relationships within each subsystem are denser and stronger than relationships between subsystems. Everything is still connected to everything else, but not equally strongly.”
  47. 47. „In hierarchical systems relationships within each subsystem are denser and stronger than relationships between subsystems. Everything is still connected to everything else, but not equally strongly.”
  48. 48. „Hierarchical systems are partially decomposable. Their subsystems with their especially dense information links can function at least partially as systems in their own right. When hierarchies break down, they usually split along their subsystem boundaries” Donella Meadows
  49. 49. „Hierarchical systems are partially decomposable. Their subsystems with their especially dense information links can function at least partially as systems in their own right. When hierarchies break down, they usually split along their subsystem boundaries”
  50. 50. Value is Your Subsystem Boundary
  51. 51. Kandydat
  52. 52. Aplikant Kandydat
  53. 53. Bezrobotny Aplikant Kandydat
  54. 54. Bezrobotny Aplikant Kandydat
  55. 55. Value is usually Your subsystem boundary
  56. 56. „Encapsulation is the packing of data and functions into a single component.”
  57. 57. „Hierarchies are brilliant systems inventions, not only because they give a system stability and resilience, but also because they reduce the amount of information that any part of the system has to keep track of.”
  58. 58. public class WrongEncapsulation{ public String name; }
  59. 59. public class IsItEncapsulation{ private String name; }
  60. 60. public class JavaStyleEncapsulation{ private String name; public String getName(){ ... }; public void setName(String name){ … }; }
  61. 61. Software design porn
  62. 62. public class AnotherStylishClass{ private List<String> strings = new ArrayList<>(); public List<String> getStrings(){ return strings; } AnotherStylishCase obj = new AnotherStylishCase(); obj.getStrings().add("Hello leaky abstraction!"); }
  63. 63. … Jakie są granice szaleństwa ...
  64. 64. … Jakie są granice szaleństwa ...
  65. 65. Kiedy znowu zobaczysz Java Bean, usuń go, poważnie, natychmiast, git rm AnotherStupidJavaBean.java
  66. 66. Jedyne rzeczy które warto zapamiętać
  67. 67. Abstrakcje Polimorfizm Context is King Gęstość informacji Enkapsulacja Hierarchical Systems Software construction vs business logic

×