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

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

- na co dzień zajmuje się prowadzaniem projektówopartych 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

- 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

JAK STAĆ SIĘ LEPSZYM PROGRAMISTĄ?

5

CO TO ZNACZYBYĆ DOBRYM PROGRAMISTĄ?

6

JESTEM DOBRYM PROGRAMISTĄ BO ...

MAM 10 LAT DOŚWIADCZENIA?

7


MAM 10 LAT DOŚWIADCZENIA?

8


ZNAM WSZYSTKIEMETODYKI/ZASADYPROGRAMOWANIA?

9

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_philosophies10


NIE KORZYSTAMZ FRAMEWORKÓW?

11


PISZĘ W NOTATNIKU?

12


PISZĘ DOBRY KOD?

13


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” – Martin Golding.

16

KISS17

nie da się napisać idealnego kodu

18

da się napisać wystarczająco

dobry kod19

BRZYDKI KOD który robi to co powinien

jest LEPSZY od najpiękniejszego ale

NIEDZIAŁAJĄCEGO20

2.O DOBRYM PROJEKCIE

21

The Psychology of Computer ProgrammingGerald M. Weinberg1971

22

Jakość oprogramowaniawg 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

Jakość oprogramowaniawg 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

Jakość oprogramowaniazgodne ze

specyfikacjąo czasie i w

budżecie

wydajne w danym środowisku

łatwe w adaptacji do zmieniających się

wymagań

25

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

Prawo Hofstadtera

29

“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

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


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ść oprogramowaniazgodne ze

specyfikacjąo czasie i w

budżecie



wymagań

43

44

45

3.O DOBRYM PROGRAMIŚCIE

46

MYŚL47

Nie myśl TYLKOo kodzie

48

- kliencie i jego potrzebach- użytkowniku- problemie- utrzymaniu kodu- przyszłości- innych programistach

MYŚL O

49

Zachowuj się jakPROFESJONALISTA

50

Trzymaj się standardów

51

Nie bój się powiedzieć:NIE WIEM

52

Sprawdź w specyfikacjiPytaj klienta

53

PytajDLACZEGO?

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