O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
JAK STAĆ SIĘ
LEPSZYM
PROGRAMISTĄ?
1
Jerzy Zawadzki
- Programista PHP z 10-letnim stażem
- Senior PHP Developer w firmie Polcode, w której pracuje ponad 7 lat
...
- założona w 2006r. przez programistów
- PHP (m.in. Symfony 2, Laravel, ZF, Magento,
Wordpress)
- Ruby On Rails
- Python
-...
4
JAK STAĆ SIĘ
LEPSZYM
PROGRAMISTĄ?
5
CO TO ZNACZY
BYĆ DOBRYM
PROGRAMISTĄ?
6
JESTEM DOBRYM
PROGRAMISTĄ BO ...
MAM 10 LAT
DOŚWIADCZENIA?
7
JESTEM DOBRYM
PROGRAMISTĄ BO ...
MAM 10 LAT
DOŚWIADCZENIA?
8
JESTEM DOBRYM
PROGRAMISTĄ BO ...
ZNAM WSZYSTKIE
METODYKI/ZASADY
PROGRAMOWANIA?
9
Abstraction principle, Code reuse, Cohesion, Command–query separation, Defensive
programming, Dependency inversion princip...
JESTEM DOBRYM
PROGRAMISTĄ BO ...
NIE KORZYSTAM
Z FRAMEWORKÓW?
11
JESTEM DOBRYM
PROGRAMISTĄ BO ...
PISZĘ W NOTATNIKU?
12
JESTEM DOBRYM
PROGRAMISTĄ BO ...
PISZĘ DOBRY KOD?
13
JESTEM DOBRYM
PROGRAMISTĄ BO ...
PISZĘ DOBRY KOD?? 14
1.
O DOBRYM KODZIE
15
“”Zawsze pisz kod tak, jakby gość, który
ma się nim zajmować był agresywnym
psychopatą, który wie, gdzie
mieszkasz”
– Mart...
KISS
17
nie da się napisać
idealnego kodu
18
da się napisać
wystarczająco
dobry kod
19
BRZYDKI KOD
który robi to co powinien
jest LEPSZY od
najpiękniejszego ale
NIEDZIAŁAJĄCEGO
20
2.
O DOBRYM
PROJEKCIE
21
The Psychology of
Computer Programming
Gerald M. Weinberg
1971
22
Jakość oprogramowania
wg Weinberga
- Używaj symfony
- DDD!
- BDD!
- Absolutnie nie pisz w Laravelu
- Nie dotknij nigdy Wor...
Jakość oprogramowania
wg Weinberga
- Używaj symfony
- DDD!
- BDD!
- Absolutnie nie pisz w Laravelu
- Nie dotknij nigdy Wor...
Jakość oprogramowania
zgodne ze
specyfikacją
o czasie i w
budżecie
wydajne w danym
środowisku
łatwe w adaptacji do
zmienia...
zgodne ze
specyfikacją
26
poszukiwanie wymagań
27
o czasie i w
budżecie
28
“Zadanie zawsze zajmie więcej
czasu niż myślisz.
Nawet jeśli wziąłeś pod uwagę
Prawo Hofstadtera
- Douglas Hofstadter
Praw...
“Napisanie pierwszych 90% kodu
aplikacji zajmuje 90% czasu pracy.
Napisanie pozostałych 10% kodu
zajmuje pozostałe 90% cza...
wydajne w danym
środowisku
31
Nie piszecie facebooka*
32
Optymalizacja
jako
“sztuka dla sztuki”
33
Serwery są tańsze od
czasu programistów
34
Najszybsze zapytanie
to takie które się
nie wykona
35
36
Najszybszy kod
to taki który się
nie wykona
37
łatwe w adaptacji do
zmieniających się
wymagań
38
które wymagania
systemu mogą się
zmienić?
Wszystkie!
39
40
41
X
W dużych projektach
nie ma możliwości
przygotowania się na
każdą zmianę.
42
Jakość oprogramowania
zgodne ze
specyfikacją
o czasie i w
budżecie
wydajne w danym
środowisku
łatwe w adaptacji do
zmienia...
44
45
3.
O DOBRYM
PROGRAMIŚCIE
46
MYŚL
47
Nie myśl TYLKO
o kodzie
48
- kliencie i jego potrzebach
- użytkowniku
- problemie
- utrzymaniu kodu
- przyszłości
- innych programistach
MYŚL O
49
Zachowuj się jak
PROFESJONALISTA
50
Trzymaj się standardów
51
Nie bój się powiedzieć:
NIE WIEM
52
Sprawdź w specyfikacji
Pytaj klienta
53
Pytaj
DLACZEGO?
54
Komunikacja
55
Empatia.
56
57
Nie ma jednego słusznego
rozwiązania dla
większości problemów
58
59
Jeśli coś jest głupie, ale działa,
to nie jest głupie.
60
DZIĘKUJĘ
Pytania?
61
Próximos SlideShares
Carregando em…5
×

PHPCon Poland 2015 - Jak stać się lepszym programistą - Jerzy Zawadzki

2.627 visualizações

Publicada em

Pisanie czystego kodu, znajomość i przestrzeganie zasad SOLID, DDD, BDD czy TDD nie wystarczy, by być dobrym programistą. Opowiem, co tak naprawdę składa się na jakość oprogramowania, postaram się Was przekonać do bardziej pragmatycznego podejścia do jego tworzenia oraz pokażę proste zasady, które sprawią, że każdy Wasz projekt będzie udany.

Publicada em: Software
  • Świetna prezentacja! Ja bym tylko zamienił pytanie "dlaczego?" na "po co?". Zazwyczaj klienci nie do końca rozumieją swoje rzeczywiste potrzeby, a to pytanie lepiej kieruje na proces odkrycia celowości danej funkcjonalności. Pytanie "dlaczego?" bardziej skłania do poszukiwania uzasadnienia (potwierdzenia) konieczności wprowadzenia funkcjonalności, bez analizy rzeczywistych potrzeb.
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui

PHPCon Poland 2015 - Jak stać się lepszym programistą - Jerzy Zawadzki

  1. 1. JAK STAĆ SIĘ LEPSZYM PROGRAMISTĄ? 1
  2. 2. Jerzy Zawadzki - Programista PHP z 10-letnim stażem - Senior PHP Developer w firmie Polcode, w której pracuje ponad 7 lat - na co dzień zajmuje się prowadzaniem projektów opartych o Symfony2 lub Magento. - Zend Certified Engineer - Magento Certified Developer - w wolnych chwilach chodzę po górach, biegam z aparatem za służbami specjalnymi albo buduje coś z klocków LEGO 2
  3. 3. - założona w 2006r. przez programistów - PHP (m.in. Symfony 2, Laravel, ZF, Magento, Wordpress) - Ruby On Rails - Python - klienci głównie z Ameryki Północnej, Europy Zachodniej i Australii - 800 zadowolonych klientów - 1200 zakończonych projektów - >100 programistów - Warszawa, Kraków, Katowice, Łodź, Białystok - + zdalnie - - założona w 2006r. przez programistów - PHP (m.in. Symfony 2, Laravel, ZF, Magento, Wordpress) - Ruby On Rails - Python - klienci głównie z Ameryki Północnej, Europy Zachodniej i Australii - 800 zadowolonych klientów - 1200 zakończonych projektów - >100 programistów - Warszawa, Kraków, Katowice, Łódź, Białystok + zdalnie 3
  4. 4. 4
  5. 5. JAK STAĆ SIĘ LEPSZYM PROGRAMISTĄ? 5
  6. 6. CO TO ZNACZY BYĆ DOBRYM PROGRAMISTĄ? 6
  7. 7. JESTEM DOBRYM PROGRAMISTĄ BO ... MAM 10 LAT DOŚWIADCZENIA? 7
  8. 8. JESTEM DOBRYM PROGRAMISTĄ BO ... MAM 10 LAT DOŚWIADCZENIA? 8
  9. 9. JESTEM DOBRYM PROGRAMISTĄ BO ... ZNAM WSZYSTKIE METODYKI/ZASADY PROGRAMOWANIA? 9
  10. 10. Abstraction principle, Code reuse, Cohesion, Command–query separation, Defensive programming, Dependency inversion principle, Discoverability, Don't repeat yourself, Fail-fast, GRASP, Hollywood principle, Information hiding, Interface segregation principle, Inversion of control, KISS principle, Law of Demeter, Liskov substitution principle, Loose coupling, MINASWAN, Open/closed principle, Principle of least astonishment, Separation of concerns, Separation of mechanism and policy, Single responsibility principle, SOLID, Uniform access principle, 80:20 rule, Amdahl's law, Code smell, Deutsch limit, Greenspun's tenth rule, Gustafson's law, If it ain't broke, don't fix it, IIABDFI, MINASWAN, Ninety-ninety rule, Rule of three, Zero one infinity rule, Acceptance test-driven development, After the Software Wars, Agile Manifesto, Agile software development, Behavior-driven development, The Cathedral and the Bazaar, Comment programming, Cowboy coding, Design-driven development, Domain-driven design, Extreme programming, Formal methods, Hollywood principle, Homesteading the Noosphere, Integration competency center, Iterative and incremental development, Kanban, KISS principle, Lean integration, Lean software development, Lightweight methodology, The Magic Cauldron, Mayo-Smith pyramid, Micro-innovation, Minimalism, Open/closed principle, Planning poker, PM Declaration of Interdependence, Release early, release often, Retrenchment, Rule of least power, Secure by design, Slow programming, Specification by example, Test double, Continuous test-driven development, Test-driven development, Test-Driven Development by Example, There's more than one way to do it, Transformation Priority Premise, Unix philosophy, Waterfall model, Worse is better, You aren't gonna need it, https://en.wikipedia.org/wiki/Category:Software_development_philosophies 10
  11. 11. JESTEM DOBRYM PROGRAMISTĄ BO ... NIE KORZYSTAM Z FRAMEWORKÓW? 11
  12. 12. JESTEM DOBRYM PROGRAMISTĄ BO ... PISZĘ W NOTATNIKU? 12
  13. 13. JESTEM DOBRYM PROGRAMISTĄ BO ... PISZĘ DOBRY KOD? 13
  14. 14. JESTEM DOBRYM PROGRAMISTĄ BO ... PISZĘ DOBRY KOD?? 14
  15. 15. 1. O DOBRYM KODZIE 15
  16. 16. “”Zawsze pisz kod tak, jakby gość, który ma się nim zajmować był agresywnym psychopatą, który wie, gdzie mieszkasz” – Martin Golding. 16
  17. 17. KISS 17
  18. 18. nie da się napisać idealnego kodu 18
  19. 19. da się napisać wystarczająco dobry kod 19
  20. 20. BRZYDKI KOD który robi to co powinien jest LEPSZY od najpiękniejszego ale NIEDZIAŁAJĄCEGO 20
  21. 21. 2. O DOBRYM PROJEKCIE 21
  22. 22. The Psychology of Computer Programming Gerald M. Weinberg 1971 22
  23. 23. Jakość oprogramowania wg Weinberga - Używaj symfony - DDD! - BDD! - Absolutnie nie pisz w Laravelu - Nie dotknij nigdy Wordpressa - Najlepiej to w ogóle nie pisz w php bo jest głupi 23
  24. 24. Jakość oprogramowania wg Weinberga - Używaj symfony - DDD! - BDD! - Absolutnie nie pisz w Laravelu - Nie dotknij nigdy Wordpressa - Najlepiej to w ogóle nie pisz w php bo jest głupi 24 X
  25. 25. Jakość oprogramowania zgodne ze specyfikacją o czasie i w budżecie wydajne w danym środowisku łatwe w adaptacji do zmieniających się wymagań 25
  26. 26. zgodne ze specyfikacją 26
  27. 27. poszukiwanie wymagań 27
  28. 28. o czasie i w budżecie 28
  29. 29. “Zadanie zawsze zajmie więcej czasu niż myślisz. Nawet jeśli wziąłeś pod uwagę Prawo Hofstadtera - Douglas Hofstadter Prawo Hofstadtera 29
  30. 30. “Napisanie pierwszych 90% kodu aplikacji zajmuje 90% czasu pracy. Napisanie pozostałych 10% kodu zajmuje pozostałe 90% czasu pracy. - Tom Cargill, Bell Labs Zasada wiarygodności (90:90) 30
  31. 31. wydajne w danym środowisku 31
  32. 32. Nie piszecie facebooka* 32
  33. 33. Optymalizacja jako “sztuka dla sztuki” 33
  34. 34. Serwery są tańsze od czasu programistów 34
  35. 35. Najszybsze zapytanie to takie które się nie wykona 35
  36. 36. 36
  37. 37. Najszybszy kod to taki który się nie wykona 37
  38. 38. łatwe w adaptacji do zmieniających się wymagań 38
  39. 39. które wymagania systemu mogą się zmienić? Wszystkie! 39
  40. 40. 40
  41. 41. 41 X
  42. 42. W dużych projektach nie ma możliwości przygotowania się na każdą zmianę. 42
  43. 43. Jakość oprogramowania zgodne ze specyfikacją o czasie i w budżecie wydajne w danym środowisku łatwe w adaptacji do zmieniających się wymagań 43
  44. 44. 44
  45. 45. 45
  46. 46. 3. O DOBRYM PROGRAMIŚCIE 46
  47. 47. MYŚL 47
  48. 48. Nie myśl TYLKO o kodzie 48
  49. 49. - kliencie i jego potrzebach - użytkowniku - problemie - utrzymaniu kodu - przyszłości - innych programistach MYŚL O 49
  50. 50. Zachowuj się jak PROFESJONALISTA 50
  51. 51. Trzymaj się standardów 51
  52. 52. Nie bój się powiedzieć: NIE WIEM 52
  53. 53. Sprawdź w specyfikacji Pytaj klienta 53
  54. 54. Pytaj DLACZEGO? 54
  55. 55. Komunikacja 55
  56. 56. Empatia. 56
  57. 57. 57
  58. 58. Nie ma jednego słusznego rozwiązania dla większości problemów 58
  59. 59. 59
  60. 60. Jeśli coś jest głupie, ale działa, to nie jest głupie. 60
  61. 61. DZIĘKUJĘ Pytania? 61

×