JDD2014: Systematyczny architekt na drodze ku postarzaniu produktu - Jarosław Pałka
description
Transcript of JDD2014: Systematyczny architekt na drodze ku postarzaniu produktu - Jarosław Pałka
Systematyczny architekt na Systematyczny architekt na drodze ku planowanemu drodze ku planowanemu postarzaniupostarzaniu
O mnie : Jarosław Pałka
• 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
„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
„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
Techniki „planowanego” postarzania
… nowy lepszy paradygmat …… nowa wersja biblioteki …
… nowy język programowania …… nowe lepsze API ...
… brak kompatybilności wstecznej …
Jakby tego było mało
trendy
„We are fashion industry”Uncle Bob
Rewrite
Offload
Modernization
Next Generation Something™
Kilka lat później
Rewrite
Offload
Modernization
Next Generation Something™
Organizacje dostają wysypki na samą myśl o kolejnym
offload, rewrite, NG projekcie
Dobry inżynier,Idź szukaj business value,szukaj
Podejście Big-Bang
Uczymy się na żywym organizmie
Ludzie z businessu trzymają się na dystans
Brak zrozumienia domeny problemu
„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
Nie naprawimy przeszłości,Ale możemy uczynić przyszłość lepszą
Mózg, cobędziemy dziś robić?
Dodamy kolejny framework!
Przygotujmy się na lepszą przyszłość
Przygotujmy się na zmiany
Abstrakcje
Posługujemy się nimi na co dzień
Są zapisane w naszej podświadomości
Dlatego tak trudno o nich rozmawiać
Polimorfizm
Znaczenie ukryte za fasadą słów
„Czy mógłbyś otworzyć zamek?”
Brak jednoznaczności abstrakcji
Znaczenie = abstrakcja(kontekst)
public interface TalkingAboutAbstractions{
public void createEmployee(String candidate);
}
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);
}
public interface TalkingAboutAbstractions{
public Employee hireCandidate(Supplier<Candidate >candidate);
}
public interface GuessWhatIHaveInMind{
String serverStatus() throws Exception;
}
„OK”
„Mam si dobrzeę ”
„Cholera gdzie jest dysk?”
„Daj mi spokoój”
„!@#$%^&*()”
public interface GuessWhatIHaveInMind{
public enum ServerStatus { OK, BUSY, INTERNAL_ERROR }
ServerStatus serverStatus() throws Exception;
}
A teraz czas na coś z klasyki
Prawdziwy, Autentyczny,
jedyny
Brainfuck
public class BrainFuck extends GenericHibernateDAO{
List<Object[]> processList(String target, Long id);
}
public class BrainFuck extends GenericHibernateDAO{
ResultSet processList(String target, Long id);
}
Use types, Luke!
Buisness logic &
system construction&
code infrastructure
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); }
}
Nie mieszajmy odpowiedzialności
Odpowiedzialność to nie tylko „business features”
Obiekt nie może być odpowiedzialny za skonstruowanie samego siebie
public interface ShowMeMore{
@GETpublic Response getRoot(
@Context HttpServletRequest request);
}
public class ShowMeMoreImpl implements ShowMeMore{
@Contextprivate HttpServletRequest request;
@GETpublic Response getRoot();
}
Struktura systemu
Gęstość informacji
„Hierarchies are brilliant systems inventions, not only because they give a systemstability and resilience, but also because they reduce the amount of information thatany part of the system has to keep track of.”
„Hierarchies are brilliant systems inventions, not only because they give a systemstability and resilience, but also because they reduce the amount of information thatany part of the system has to keep track of.”
„In hierarchical systems relationships within each subsystem are denser and strongerthan relationships between subsystems. Everything is still connected to everythingelse, but not equally strongly.”
„In hierarchical systems relationships within each subsystem are denser and strongerthan relationships between subsystems. Everything is still connected to everythingelse, but not equally strongly.”
„Hierarchical systems are partially decomposable. Their subsystems with theirespecially dense information links can function at least partially as systems in theirown right. When hierarchies break down, they usually split along their subsystemboundaries”
Donella Meadows
„Hierarchical systems are partially decomposable. Their subsystems with theirespecially dense information links can function at least partially as systems in theirown right. When hierarchies break down, they usually split along their subsystemboundaries”
Value is Your Subsystem Boundary
Kandydat
Aplikant
Kandydat
Aplikant
Kandydat
Bezrobotny
Aplikant
Kandydat
Bezrobotny
Value is usually
Your subsystem boundary
„Encapsulation is the packing of data and functions into a single component.”
„Hierarchies are brilliant systems inventions, not only because they give a systemstability and resilience, but also because they reduce the amount of information thatany part of the system has to keep track of.”
public class WrongEncapsulation{public String name;
}
public class IsItEncapsulation{private String name;
}
public class JavaStyleEncapsulation{
private String name;
public String getName(){ ... };
public void setName(String name){ …
};
}
Software design porn
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!");
}
… Jakie są granice szaleństwa ...
… Jakie są granice szaleństwa ...
Kiedy znowu zobaczysz Java Bean,usuń go,
poważnie,natychmiast,
git rm AnotherStupidJavaBean.java
Jedyne rzeczy które warto zapamiętać
AbstrakcjePolimorfizm
Context is King
Gęstość informacjiEnkapsulacja
Hierarchical Systems
Software construction vs
business logic