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.

1. Systematyczny aarrcchhiitteekktt nnaa
ddrrooddzzee kkuu ppllaannoowwaanneemmuu
ppoossttaarrzzaanniiuu

2. O mnie :
Jarosław Pałka

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

5. „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

6. „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

8. Techniki „planowanego” postarzania
… nowy lepszy paradygmat …
… nowa wersja biblioteki …
… nowy język programowania …
… nowe lepsze API ...
… brak kompatybilności wstecznej …

9. Jakby tego było mało
trendy

10. „We are fashion industry”
Uncle Bob

11. Rewrite
Offload
Modernization
Next Generation Something™

12. Kilka lat później

13. Rewrite
Offload
Modernization
Next Generation Something™

14. Organizacje dostają wysypki na
samą myśl
o kolejnym
offload, rewrite, NG projekcie

15. Dobry inżynier,
Idź szukaj business value,
szukaj

16. Podejście Big-Bang
Uczymy się na żywym organizmie
Ludzie z businessu trzymają się na dystans
Brak zrozumienia domeny problemu

18. „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

19. Nie naprawimy przeszłości,
Ale możemy uczynić przyszłość lepszą

20. Mózg, co
będziemy
dziś robić?

21. Dodamy kolejny framework!

22. Przygotujmy się na lepszą przyszłość
Przygotujmy się na zmiany

23. Abstrakcje

24. Posługujemy się nimi na co dzień
Są zapisane w naszej podświadomości
Dlatego tak trudno o nich rozmawiać

25. Polimorfizm

26. Znaczenie ukryte za fasadą słów

30. „Czy mógłbyś otworzyć zamek?”
Brak jednoznaczności abstrakcji

31. Znaczenie = abstrakcja(kontekst)

32. public interface TalkingAboutAbstractions{
public void createEmployee(String candidate);
}

33. 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);
}

34. public interface TalkingAboutAbstractions{
public Employee
hireCandidate(Supplier<Candidate >candidate);
}

35. public interface GuessWhatIHaveInMind{
String serverStatus() throws Exception;
}

36. „OK”
„Mam się dobrze”
„Cholera gdzie jest dysk?”
„Daj mi spokoój”
„!@#$%^&*()”

37. public interface GuessWhatIHaveInMind{
public enum ServerStatus { OK, BUSY, INTERNAL_ERROR }
ServerStatus serverStatus() throws Exception;
}

38. A teraz czas na coś z klasyki
Prawdziwy,
Autentyczny,
jedyny

39. Brainfuck

40. public class BrainFuck extends GenericHibernateDAO{
List<Object[]> processList(String target, Long id);
}

41. public class BrainFuck extends GenericHibernateDAO{
ResultSet processList(String target, Long id);
}

42. Use types, Luke!

43. Buisness logic
&
system construction
&
code infrastructure

44. 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);
}
}

45. Nie mieszajmy odpowiedzialności
Odpowiedzialność to nie tylko
„business features”
Obiekt nie może być odpowiedzialny za
skonstruowanie samego siebie

46. public interface ShowMeMore{
@GET
public Response getRoot(
@Context HttpServletRequest request);
}

47. public class ShowMeMoreImpl implements
ShowMeMore{
@Context
private HttpServletRequest request;
@GET
public Response getRoot();
}

48. Struktura systemu

49. Gęstość informacji

50. „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.”

51. „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.”

52. „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.”

53. „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.”

54. „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

55. „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”

57. Value is Your Subsystem Boundary

58. Kandydat

59. Aplikant
Kandydat

60. Bezrobotny
Aplikant
Kandydat

61. Bezrobotny
Aplikant
Kandydat

62. Value is
usually
Your subsystem boundary

63. „Encapsulation is the packing
of data and functions into a
single component.”

64. „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.”

65. public class WrongEncapsulation{
public String name;
}

66. public class IsItEncapsulation{
private String name;
}

67. public class JavaStyleEncapsulation{
private String name;
public String getName(){ ... };
public void setName(String name){
…
};
}

68. Software design porn

69. 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!");
}

70. … Jakie są granice szaleństwa ...

71. … Jakie są granice szaleństwa ...

72. Kiedy znowu zobaczysz Java Bean,
usuń go,
poważnie,
natychmiast,
git rm AnotherStupidJavaBean.java

73. Jedyne rzeczy które warto zapamiętać

74. Abstrakcje
Polimorfizm
Context is King
Gęstość informacji
Enkapsulacja
Hierarchical Systems
Software construction
vs
business logic