Прадмова перакладчыка: Прачытаўшы гэты артыкул, вы, магчыма, здзівіцеся ці нават раззлуецеся. Так, мы таксама здзівіліся: аўтар нібыта ніколі не чуў пра іерархію ў камандзе, пра пастаноўку задач са статусам «зрабіць хутка і без разваг». Так, усё так, гэта крыху дзіўны тэкст. Сапраўды, аўтар прапануе праграмісту ўзяць на сябе ролю сістэмнага архітэктара - а навошта тады патрэбен архітэктар? Але ўсе гэтыя пярэчанні не павінны закрываць ад вас галоўнага - таго, чаму мы ўсё ж узялі і пераклалі гэты тэкст. Ён жа не пра ролі. Гэты тэкст - пра прафесійны падыход і ўсвядомленасць. Праўда ў тым, што, пакуль вы проста "робіце што скажуць", не задумваючыся аб сэнсе сваіх дзеянняў, вы ніколі не станеце вялікім праграмістам.
Сказаць "не" лішняму коду. Усё, што вы павінны зрабіць, - сабраць разам тры літары і вымавіць гэтае слова. Давайце паспрабуем зрабіць гэта разам: «Неееееет!»
Але пачакайце. Навошта мы гэта які робіцца? Бо асноўная задача праграміста - пісаць код. Але ці трэба пісаць любы код, які ад вас патрабуюць? Не! "Разуменне таго, калі не варта пісаць код, верагодна, найважнейшы скіл для праграміста". .
Нагадваем: для ўсіх чытачоў "Хабра" - зніжка 10 000 рублёў пры запісе на любы курс Skillbox па промакодзе "Хабр".
Skillbox рэкамендуе: Практычны курс .
Праграмаванне - гэта мастацтва рашэння праблем. А вы - майстры гэтага мастацтва.
Часам, імкнучыся хутчэй пачаць працу, мы не думаем ні пра што, акрамя выканання пастаўленай задачы. І гэта можа стаць прычынай яшчэ больш сур'ёзных праблем.
На што заплюшчваюць вочы праграмісты?
Увесь код, які вы пішаце, павінен быць зразумелы іншым распрацоўнікам, а таксама пратэставаны і адладжаны.
Але ёсць праблема: што б вы ні напісалі, гэта ўскладніць ваша ПЗ і, верагодна, дадасць багаў у будучыні.
Па словах Рыча Скрэнта, . Вось што ён піша:
«Код дрэнны, таму што ён пачынае гніць і патрабуе сталага абслугоўвання. Даданне новых функцый часта патрабуе мадыфікацыі старога кода. Чым ён аб'ёмней, тым вышэйшая верагоднасць з'яўлення памылкі і больш часу трэба на кампіляцыю. Больш часу патрабуецца іншаму распрацоўніку, каб разабрацца. А калі патрэбны рэфакторынг, то абавязкова знойдуцца фрагменты, якія варта змяніць. Аб'ёмны код часцяком азначае зніжэнне гнуткасці і функцыянальнасці праекту. Простае і элегантнае рашэнне працуе хутчэй, чым складаны код».
Як даведацца, калі не варта пісаць код?
Праблема ў тым, што праграмісты часта перабольшваюць колькасць функцый, патрэбных іх з дадаткам. У выніку многія ўчасткі кода застаюцца незавершанымі або іх ніхто не выкарыстоўвае, а вось дадатак яны ўскладняюць.
Вы павінны дакладна ўсведамляць, што трэба вашаму праекту, а што - не.
У якасці прыкладу можна прывесці дадатак, якое вырашае ўсяго адну задачу - кіруе электроннай поштай. Для гэтага ўведзены дзве функцыі - адпраўка і атрыманне лістоў. Не варта чакаць, што паштовы мэнэджар стане адначасова і таск-мэнэджарам.
Трэба цвёрда сказаць "не" прапановам дадаць функцыі, якія не адносяцца да галоўнай задачы прыкладання. Гэта менавіта той момант, калі становіцца зразумела, што дадатковы код не патрэбен.
Ніколі не збівайце фокус вашага прыкладання.
Заўсёды пытайце сябе:
- Якая функцыя цяпер павінна быць рэалізавана?
- Які код варта напісаць?
Падвяргайце сумневу ідэі, якія прыходзяць у галаву, і ацэньвайце прапановы, якія паступаюць з боку. У адваротным выпадку лішні код можа проста забіць праект.
Веды, калі не варта дадаваць лішняе, дазволіць трымаць базу кода пад цвёрдым кантролем.
У самым пачатку шляху ў праграміста ёсць усяго два ці тры зыходных файла. Усё проста. Кампіляцыя і запуск прыкладання патрабуюць мінімум часу; заўсёды зразумела, дзе і што можна шукаць.
Па меры пашырэння прыкладання з'яўляецца ўсё больш файлаў з кодам. Яны запаўняюць каталог, у кожным - сотні радкоў. Для таго каб усё гэта арганізаваць правільна, давядзецца ствараць дадатковыя каталогі. Пры гэтым запамінаць, якія функцыі завошта адказваюць і якія дзеянні выклікаюць, становіцца ўсё складаней; лоўля багаў таксама патрабуе больш часу. Ускладняецца і кіраванне праектам, патрабуецца ўжо не адзін, а некалькі распрацоўшчыкаў, каб усачыць за ўсім. Адпаведна, растуць выдаткі, як грашовыя, так і часовыя, тармозіцца працэс распрацоўкі.
Праект у выніку становіцца велізарным, даданне кожнай новай функцыі даецца з вялікай і вялікай працай. Нават на нешта зусім нязначнае даводзіцца траціць некалькі гадзін. Выпраўленне існуючых памылак прыводзіць да з'яўлення новых, зрываюцца тэрміны рэлізу дадатку.
Цяпер даводзіцца змагацца за жыццё праекта. Чаму?
Справа ў тым, што вы проста не разумелі, калі не трэба дадаваць лішні код, і на кожную прапанову і ідэю адказвалі "так". Вы былі сляпыя, жаданне ствараць новае прымусіла вас ігнараваць важныя факты.
Гучыць як сцэнар фільма жахаў, праўда?
Менавіта гэта і адбудзецца, калі вы будзеце працягваць казаць "так". Пастарайцеся зразумець, калі код не варта дадаваць. Выдаліце лішняе з праекта - гэта выдатна палегчыць ваша жыццё і падоўжыць існаванне прыкладання.
"Адзін з самых прадуктыўных маіх дзён - той, калі я выдаліў 1000 радкоў кода".
- Кен Томпсан.
Навучыцца разумець, калі ня трэба пісаць код, складана. Але гэта трэба.
Так, я ведаю, што вы толькі што ўступілі на шлях распрацоўшчыка і хочаце пісаць код. Гэта добра, не губляйце гэтага першага ўражанні, але і не выпускайце з-пад увагі важныя фактары з-за энтузіязму. Мы ўсвядомілі ўсё шляхам спроб і памылак. Вы таксама будзеце дапускаць памылкі і вучыцца на іх. Але калі зможаце атрымаць урок са сказанага вышэй, ваша праца стане больш свядомай.
Працягвайце тварыць, але ведайце, калі трэба сказаць "не".
Skillbox рэкамендуе:
- Прыкладны анлайн-курс .
- Анлайн-курс .
- Практычны гадавы курс .
Крыніца: habr.com