Why creating simple solutions is important and whether the technical debt is always bad.

1. Przemysław Krzywania
Tworzę komercyjnie oprogramowanie od 2008
Cześć!
@p_krzywania pkrzywania

2. KICK ME

4. NEXUS

5. Plan
1. Prostota
2. Dług techniczny

6. Prostota

7. Jedyna wartościowa miara

8. Dlaczego prostota
jest ważna?

9. Kod czytamy, nie piszemy

10. “
W rzeczywistości stosunek czasu czytania do
pisania jest znacznie wyższy niż 10 do 1. Wciąż
czytamy stary kod w ramach prób napisania nowego
kodu. ... [Dlatego] ułatwienie czytania ułatwia
pisanie
Robert Cecil Martin

12. Przykład
$temp = $a;
$a = $b;
$b = $temp;
3 razy wolniejszy
[$b, $a] = [$a, $b];

13. Spotkaliście się z tym?
1. Nowy developer- super gwiazda
2. Po godzinie stwierdza, że wszystko jest do dupy
3. Forsuje “nowe” standardy
4. Odchodzi po pół roku
5. Nikt nie wie o co chodzi, projekt jest nie
utrzymywalny

14. Wytwarzanie oprogramowania to
gra zespołowa a nie indywidualna
Zespół > gwiazdy programowania

15. Legacy != kod nieutrzymywalny

16. DRY
don’t repeat yourself
KISS
keep it simple stupid
SOLID
single responsibility, open/closed, liskov substitution, interface segregation, dependency inversion
YAGNI
you aren’t gonna need it
Znane zasady

17. Mantra
1. Ty jesteś odpowiedzialny za kod.
2. Spójny styl formatowania.
3. Opisowe nazwy klas i metod.
4. Komentuje, ale nie rzeczy oczywiste!
5. Krótkie funkcje, klasy, metody.
6. Brak zagnieżdżeń, złożoności.

18. Przykład
function doSomethingStupid(arg1 argumentToCheck)
{
if (argumentToCheck) {
…..
} else {
return false;
}
}

19. Przykład
function doSomethingStupid(arg1 argumentToCheck)
{
if (!argumentToCheck) {
return false;
}
...
}

21. Zostaw kod czytelniejszym
niż go zastałeś

26. Prosty kod wymaga prostej
architektury

27. Czysta architektura

28. Jaka powinna być czysta architektura
1. Niezależna od frameworka
2. Testowalna
3. Niezależna od UI
4. Niezależna od DB
5. Słabo zależna od zewnętrznych API
6. Łopatologiczna

29. Monolit

30. Mikroserwisy

31. Przykład
UI
Serwis 1 Serwis 2 Serwis 3
Serwis 4
DB

33. Dług techniczny

34. Czas
Najcenniejszy zasób

36. “
Wszyscy wiedzą, że programiści powinni
spłacać długi, jednakże karencja może
przekroczyć czas życia projektu

37. if you plan to develop it

38. Kiedy dług jest dobry?
W momencie jak go tworzymy

39. Agile wspiera dług techniczny

40. Proof of concept

41. Kiedy dług jest zły
W prawie każdym innym momencie

42. Zależą od tego co chcemy “kredytować”
Koszty długu

43. Jak byś chciał żeby zachowywał się dług techniczny
dług
czas

44. Jak zachowuje się w rzeczywistości
dług
czas

45. Idealna krzywa długu
dług
czas
Linia bazowa
Nieprzekraczalna linia
graniczna długu

46. Trzymanie długu w ryzach
TDD
Code review
Statyczna analiza kodu
Definition of done

47. Jak pomaga definition of done

48. Jak TDD pomaga

49. Software craftsmanship manifesto
Not only working software,
but also well-crafted software
Not only responding to change,
but also steadily adding value
Not only individuals and interactions,
but also a community of professionals
Not only customer collaboration,
but also productive partnerships
Utopia?

50. “
The primary task of a developer is not
the writing of code but to understand
a problem.
https://thephp.cc/news/2017/05/testing-keeps-me-from-get
ting-things-done

51. Rozważne żonglowanie długiem przy zachowaniu prostoty
rozwiązania pozwala osiągnać to optymalnym kosztem
Najważniejsze jest ciągle
móc dostarczać wartość

52. “
Dług techniczny nie dotyczy
technologii. Chodzi o ludzi.

53. Pytania?

54. Przemysław Krzywania
@p_krzywania pkrzywania
Dziękuję!