Добры дрэнны код
З пакоя пачуўся дзікі крык: “Я не веру сваім вачам! За што?” Выпадковы прахожы мог пачуць усе стадыі прыняцця: ад адмаўлення да пакоры. Нядзіўная была і прычына: старэйшаму распрацоўніку Васілю дасталася спадчына! Але гэта была не тая спадчына ад багатай цёткі, якая зрабіла б Васіля багацей матэрыяльна. Гэта была праца дзясяткаў іншых распрацоўнікаў. І мяркуючы па крыкам, якія даносіліся з пакоя і якія вырашана было тут не цытаваць, спадчына не зрабіла Васіля багацей і духоўна.
За сваю працоўную кар’еру Васіль пабачыў усякае: велізарныя файлы па некалькі тысяч радкоў; мудрае выкарыстанне кода з дапамогай капіявання; хітрамудрыя аптымізацыі, якія не давалі прыросту прадукцыйнасці. А аднойчы ў праекце на FORTRAN яму здалося, што ён нават адшукаў сляды дыназаўраў. Але новы праект быў настолькі ўнікальны ў сваім родзе, што Васіль упершыню задумаўся аб выхадзе на пенсію, да якой яму заставалася ўсяго крыху больш за трыццаць гадоў.
Што ж такое дрэнны код?
А я ў дзяцінстве ў вёсцы вычышчаў гной у кароўніку. Вырас, стаў праграмістам, а нічога не змянілася.
Взято с bash.im
Само па сабе паняцце дрэннага кода вельмі суб’ектыўна. Кожны распрацоўнік мысленна дзеліць кодавую базу на дзве часткі: свой уласны код і агіднае нагрувашчванне канструкцый, якое па недарэчнай выпадковасці называецца кодам.
Шмат у чым стаўленне да чужога коду залежыць ад вопыту, назапашанага праз боль і пакуты распрацоўкі і падтрымкі папярэдніх праектаў, а таксама выпрацаваных праз гэта звычак. Ці здаралася вам калісьці зайсці ў супермаркет па хлеб, калі там нечакана адбылася перастаноўка? Праходзячы праз розныя аддзелы вы становіцеся шчаслівым уладальнікам гарбаты, кавы, можа быць нават тэлевізара. Але якое расчараванне чакае дома, калі прыходзіць усведамленне, што вы забылі пра хлеб!
Прыкладна такія ж адчуванні адбываюцца ад блукання па чужым коду: вось тут павінен быць аддзел хлебабулачных вырабаў, але прадаюць спартовае харчаванне. Проста мучное зараз не ў трэндзе, таму вырашана было змяніць асартымент, а перайменаваць аддзел пакуль не дабраліся рукі. Затое тут жа стаіць халадзільнік з півам, таму што яго не было куды ўпіхнуць. А калі трэба хлеб, то кожны пакет мукі выдаецца за куплю аднаго апельсіна. У жаху вы пакідаеце краму ровараў і арганізуеце фабрыку па выпечцы хлеба ў сябе ў абутковым.
Як з’яўляецца дрэнны код?
Разабраліся! Дрэнны код — гэта любы зыходны файл вашага калегі! Кіруючыся дзіўнымі высновамі, на гэтым можна было б скончыць і параіць менеджэру выгнаць астатніх распрацоўшчыкаў з каманды (пакуль яны вас не апярэдзілі). Але вырашыла б гэта праблему, нават калі на час адкінуць у бок фактар аўтобуса? На жаль, не.
Распрацоўка праграмнага забеспячэння ў пераважнай большасці выпадкаў не з’яўляецца крыніцай даходаў сама па сабе, а выкарыстоўваецца дзеля зачынення праблем і аптымізацыі рашэнняў бізнесу. Цяжка ўявіць, як галоўны інвестар з бакалам добрага віскі гартае зыходнікі, дасягаючы нірваны ад дасканаласці. Значна больш верагодна, што вы ўдзельнічаеце ў чарговым відзе безнадзейнага праекта з выдатнай кнігі “Шлях камікадзэ” Э. Йордона, калі зачыніць задачу трэба яшчэ ўчора, а менеджэр запэўнівае, што ў гэты раз досыць абысціся часовым рашэннем.
Дэградацыя па спіралі
Часовых рашэнняў становіцца ўсё больш, яны ўтвараюць ядро праекта. Праз год ужо складана паверыць, што гэты код быў напісаны вамі. У праекце пастаянна нешта ламаецца, часу на ўнясенне новых зменаў не застаецца.
Наймаюцца новыя распрацоўшчыкі, але ў праекце адсутнічае якая-небудзь дакументацыя, а каментарыі больш нагадваюць штогадовы матывацыйны TODO план. Не разумеючы тонкасцяў праекта і глыбіні вашай архітэктурнай думкі, пра якую ўжо складаюцца крыўдныя легенды, разам з новымі функцыямі распрацоўшчыкі дадаюць новыя багі. Вы ўсё больш вымушаны праводзіць часу за рэвізіямі чужога кода і выступаць у ролі інтэрактыўнай дакументацыі.
Паступова праект відавочным або няяўным чынам падзяляецца на зоны адказнасці паміж распрацоўшчыкамі. З прычыны адсутнасці агульнага падыходу (спагецці-код не ў рахунак), кожная частка развіваецца асобна і незалежна. І ўсё рухаецца па спіралі:
- Распрацоўшчыкі мысленна пачынаюць дзяліць кодавую базу на апісаныя раней дзве часткі;
- З’яўляюцца тэрміновыя задачы, якія зачыніць трэба яшчэ ўчора;
- Кожны распрацоўшчык пачынае ўносіць часовыя рашэнні ў сваю частку кода…
І што ж рабіць?
Пішыце код так, як быццам падтрымліваць яго будзе схільны да гвалту псіхапат, які ведае, дзе вы жывяце.
Джон Вудс
У прапанаванага падыходу Джона Вудса ёсць адзін недахоп: распрацоўшчыкі б хутка скончыліся, таму паспрабуем пашукаць яшчэ.
Сучасныя метады распрацоўкі мяркуюць частае ўнясенне змяненняў з магчымасцю развароту праекта ў любы момант на 180 градусаў. Пры гэтым першапачатковая архітэктура хутчэй не зможа падтрымаць такі разварот, але часу на перапісванне з нуля, вядома, няма. Ды і хто дасць гарантыю, што праз дзень усё не паўторыцца зноў?
У канчатковым выніку ўсё гэта вядзе да пагаршэння кодавай базы – з’яўленню таго самага дрэннага кода. У нейкі момант код становіцца проста непрыдатным для далейшай падтрымкі і распрацоўкі, а ўнясенне туды змен больш нагадвае хаджэнне па мінным полі.
Менавіта таму неабходна рабіць паўзы і вылучаць час на рэфактарынг, які дапаможа зрабіць нейкія часткі кода больш надзейнымі і зручнымі для змен. Паколькі часу на поўную перапрацоўку не будзе, гэты код хутчэй за ўсё будзе ісці насуперак з першапачатковай архітэктурай. І як бы вы не былі задаволеныя атрыманага выніку, іншага назіральніка ён можа ўсё роўна здавацца дрэнным: яму не будуць відавочны ўсе тонкасці і прычыны ўнесеных зменаў. Адсюль і атрымліваецца, што код адначасова і добры, і дрэнны, — а мы ўсё пішам добры дрэнны код.
