During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.
48. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
49. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
50. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
51. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
52. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
53. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
54. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
55. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć biznes,
56. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć biznes,
10. Jeśli tylko możesz -> DDD i TDD,
57. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć domenę biznesową,
10. Jeśli tylko możesz -> DDD i TDD,
11. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość.