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?
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.
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
7.
8. Techniki „planowanego” postarzania
… nowy lepszy paradygmat …
… nowa wersja biblioteki …
… nowy język programowania …
… nowe lepsze API ...
… brak kompatybilności wstecznej …
16. Podejście Big-Bang
Uczymy się na żywym organizmie
Ludzie z businessu trzymają się na dystans
Brak zrozumienia domeny problemu
17.
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
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
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”
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.”
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!");
}