{"id":36115,"date":"2019-10-31T22:09:42","date_gmt":"2019-10-31T19:09:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete\/"},"modified":"2019-10-31T22:09:42","modified_gmt":"2019-10-31T19:09:42","slug":"ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/ne-soglashajtes-razrabatyvat-to-chego-ne-ponimaete","title":{"rendered":"Nie zgadzaj si\u0119 na rozwijanie czego\u015b, czego nie rozumiesz.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nie
\n
\nOd pocz\u0105tku 2018 roku pe\u0142ni\u0119 funkcj\u0119 lidera \/ kierownika \/ g\u0142\u00f3wnego programisty w zespole \u2014 jak to nazwiesz, nie ma znaczenia, ale w istocie odpowiadam w pe\u0142ni za jeden z modu\u0142\u00f3w oraz za wszystkich programist\u00f3w, kt\u00f3rzy nad nim pracuj\u0105. Ta pozycja otwiera przede mn\u0105 nowy spos\u00f3b postrzegania procesu tworzenia, poniewa\u017c jestem zaanga\u017cowany w wi\u0119ksz\u0105 liczb\u0119 projekt\u00f3w i aktywniej uczestnicz\u0119 w podejmowaniu decyzji. Niedawno, dzi\u0119ki tym dw\u00f3m okoliczno\u015bciom, nagle zda\u0142em sobie spraw\u0119, jak mocno zrozumienie wp\u0142ywa na kod i na aplikacj\u0119.<\/p>\n

My\u015bl, kt\u00f3r\u0105 chc\u0119 wyrazi\u0107, sprowadza si\u0119 do tego, \u017ce jako\u015b\u0107 kodu (i ostatecznego produktu) jest \u015bci\u015ble zwi\u0105zana z tym, jak bardzo ludzie, kt\u00f3rzy zajmuj\u0105 si\u0119 projektowaniem i pisz\u0105 kod, s\u0105 \u015bwiadomi tego, co tak naprawd\u0119 robi\u0105.<\/p>\n

Mo\u017cecie teraz pomy\u015ble\u0107: \u201eDzi\u0119ki, kapitanie. Oczywi\u015bcie dobrze by\u0142oby wiedzie\u0107, co si\u0119 pisze. W przeciwnym razie r\u00f3wnie dobrze mo\u017cna zatrudni\u0107 grup\u0119 ma\u0142p, aby pisa\u0142y na przypadkowych klawiszach, i na tym poprzesta\u0107\u201d. I macie ca\u0142kowit\u0105 racj\u0119. Dlatego przyjmuj\u0119 jako oczywiste, \u017ce zdajecie sobie spraw\u0119, i\u017c og\u00f3lne zrozumienie tego, co robicie, jest konieczne. Mo\u017cna to nazwa\u0107 zerowym poziomem zrozumienia, a tym si\u0119 nie b\u0119dziemy szczeg\u00f3\u0142owo zajmowa\u0107. Szczeg\u00f3\u0142owo om\u00f3wimy to, co dok\u0142adnie trzeba zrozumie\u0107 i jak wp\u0142ywa to na decyzje, kt\u00f3re podejmujecie ka\u017cdego dnia. Gdybym zna\u0142 te rzeczy wcze\u015bniej, zaoszcz\u0119dzi\u0142oby mi to mn\u00f3stwo zmarnowanego czasu i w\u0105tpliwego kodu.
\n<\/a><\/noindex>
\nChocia\u017c poni\u017cej nie zobaczycie ani jednej linijki kodu, i tak uwa\u017cam, \u017ce wszystko, co tutaj powiedziano, ma ogromne znaczenie dla pisania wysokiej jako\u015bci, wyrazistego kodu. <\/p>\n

Pierwszy poziom zrozumienia: Dlaczego to nie dzia\u0142a?<\/h4>\n

\nNa ten poziom programi\u015bci zazwyczaj dochodz\u0105 na bardzo wczesnych etapach swojej kariery, czasami nawet bez jakiejkolwiek pomocy ze strony otoczenia \u2014 przynajmniej wed\u0142ug moich obserwacji. Wyobra\u017acie sobie, \u017ce otrzymali\u015bcie zg\u0142oszenie b\u0142\u0119du: jaka\u015b funkcja w aplikacji nie dzia\u0142a, trzeba j\u0105 naprawi\u0107. Jakie dzia\u0142ania podejmiecie?<\/p>\n

Standardowy schemat wygl\u0105da tak:<\/p>\n

    \n
  1. Znale\u017a\u0107 fragment kodu, kt\u00f3ry wywo\u0142uje problem (jak to zrobi\u0107 \u2014 to osobny temat, kt\u00f3ry omawiam w mojej ksi\u0105\u017cce o przestarza\u0142ym kodzie)<\/li>\n
  2. Wprowadzi\u0107 zmiany w tym fragmencie<\/li>\n
  3. Upewni\u0107 si\u0119, \u017ce b\u0142\u0105d zosta\u0142 naprawiony, a regresja nie wyst\u0105pi\u0142a<\/li>\n<\/ol>\n

    \nSkupmy si\u0119 teraz na drugim punkcie \u2014 wprowadzaniu zmian w kodzie. Istniej\u0105 dwa podej\u015bcia do tego procesu. Pierwsze: zrozumie\u0107, co dok\u0142adnie dzieje si\u0119 w obecnym kodzie, zidentyfikowa\u0107 b\u0142\u0105d i go naprawi\u0107. Drugie: dzia\u0142a\u0107 na czuja \u2014 doda\u0107, powiedzmy, +1 w warunku lub p\u0119tli, sprawdzi\u0107, czy ta funkcja zacz\u0119\u0142a dzia\u0142a\u0107 w odpowiednim scenariuszu, a potem spr\u00f3bowa\u0107 czego\u015b jeszcze, i tak w niesko\u0144czono\u015b\u0107.<\/p>\n

    Prawid\u0142owe jest pierwsze podej\u015bcie. Jak wyja\u015bnia w swojej ksi\u0105\u017cce Code Complete Steve McConnell (zreszt\u0105 bardzo j\u0105 polecam), za ka\u017cdym razem, gdy wprowadzamy zmiany w kodzie, musimy by\u0107 w stanie z pe\u0142nym przekonaniem przewidzie\u0107, jak wp\u0142ynie to na aplikacj\u0119. Przytaczam cytat z pami\u0119ci, ale je\u017celi naprawa b\u0142\u0119du dzia\u0142a inaczej ni\u017c oczekiwa\u0142e\u015b, powinno to wzbudzi\u0107 twoje w\u0105tpliwo\u015bci, a ca\u0142y plan dzia\u0142ania powinien zosta\u0107 poddany rewizji.<\/p>\n

    Podsumowuj\u0105c, aby wykona\u0107 solidn\u0105 napraw\u0119 b\u0142\u0119du, kt\u00f3ra nie pogorszy jako\u015bci kodu, nale\u017cy rozumie\u0107 zar\u00f3wno ca\u0142\u0105 struktur\u0119 kodu, jak i \u017ar\u00f3d\u0142o konkretnego problemu.<\/p>\n

    Drugi poziom zrozumienia: Dlaczego to dzia\u0142a?<\/h4>\n

    \nTen poziom jest osi\u0105gany znacznie mniej intuicyjnie ni\u017c poprzedni. Ja, b\u0119d\u0105c jeszcze pocz\u0105tkuj\u0105cym programist\u0105, przyswoi\u0142em go dzi\u0119ki mojemu szefowi, a p\u00f3\u017aniej wielokrotnie sam wyja\u015bnia\u0142em t\u0119 kwesti\u0119 nowicjuszom.<\/p>\n

    Tym razem wyobra\u017amy sobie, \u017ce otrzymujesz od razu dwa raporty b\u0142\u0119d\u00f3w: pierwszy dotyczy scenariusza A, drugi \u2014 scenariusza B. W obu scenariuszach dzieje si\u0119 co\u015b nie tak. W zwi\u0105zku z tym najpierw zajmujesz si\u0119 pierwszym b\u0142\u0119dem. Kieruj\u0105c si\u0119 zasadami, kt\u00f3re ustalili\u015bmy dla pierwszego poziomu zrozumienia, dok\u0142adnie analizujesz kod zwi\u0105zany z problemem, ustalasz, dlaczego powoduje on takie a nie inne zachowanie aplikacji w scenariuszu A, i wprowadzasz sensowne korekty, kt\u00f3re daj\u0105 dok\u0142adnie ten rezultat, jakiego si\u0119 spodziewa\u0142e\u015b. Wszystko idzie \u015bwietnie.<\/p>\n

    Nast\u0119pnie przechodzisz do scenariusza B. Powtarzasz scenariusz w pr\u00f3bie sprowokowania b\u0142\u0119du, ale \u2014 niespodzianka! \u2014 teraz wszystko dzia\u0142a jak nale\u017cy. Aby potwierdzi\u0107 swoje przypuszczenie, cofasz zmiany wprowadzone w trakcie pracy nad b\u0142\u0119dem A, a b\u0142\u0105d B wraca. Twoja naprawa rozwi\u0105za\u0142a oba problemy. Szcz\u0119\u015bcie!<\/p>\n

    Nie spodziewa\u0142e\u015b si\u0119 tego. Wymy\u015bli\u0142e\u015b spos\u00f3b na naprawienie b\u0142\u0119du w scenariuszu A i nie masz poj\u0119cia, dlaczego zadzia\u0142a\u0142 r\u00f3wnie\u017c w scenariuszu B. Na tym etapie mo\u017ce by\u0107 wielka pokusa, by uzna\u0107, \u017ce oba zadania zosta\u0142y pomy\u015blnie zako\u0144czone. To ca\u0142kiem logiczne: chodzi\u0142o przecie\u017c o naprawienie b\u0142\u0119d\u00f3w, prawda? Ale praca jeszcze si\u0119 nie sko\u0144czy\u0142a: musisz jeszcze zrozumie\u0107, dlaczego twoje dzia\u0142ania naprawi\u0142y b\u0142\u0105d w scenariuszu B. Po co? Bo mo\u017ce on dzia\u0142a na niew\u0142a\u015bciwych zasadach, a wtedy b\u0119dziesz musia\u0142 szuka\u0107 innego rozwi\u0105zania. Oto kilka przyk\u0142ad\u00f3w takich sytuacji:<\/p>\n