Какво научих от четенето на „Прагматичният програмист“

Накратко: старо, но златно.

Публикувана през 1999 г., Прагматичният програмист е книга за това как да станеш Прагматичен програмист. Което наистина означава „добър програмист“.

Да, публикувано е преди около 20 години. Но тази книга все още предоставя много прозрения, които са много подходящи за програмисти или софтуерни инженери, както някои хора може да ги наричат ​​в наши дни.

Може би сте чували за тази книга и преди и сте поставяли под въпрос за какво всъщност става дума. Е, днес ще споделя с вас някои от интересните неща, които научих, докато четях книгата.

Да бъдеш програмист има нещо повече от технически умения

почиствах си лаптопа и го намерих за прекрасен.  ще се видим.

Когато четете заглавието на книгата, може да очаквате, че тя ще даде много технически уроци. Но всъщност не е така. Това, което прави тази книга все още актуална 20 години по-късно, е, че тя ни учи, че да бъдеш програмист не е всичко в техническата сила. И ние често пренебрегваме този факт.

Книгата ни учи, че в програмирането има нещо повече от технически способности.

Котката изяде моя изходен код

моето котешко къри

Това е първата глава в книгата и е много интересна концепция.

Не забравяйте, че един ден, когато не завършихме домашното си и казахме, че кучето го е изяло? (Всъщност не го помня, защото винаги завършвам домашното си?)

Това, което ни учи и тази глава, всъщност е отговорността. Когато носите отговорност за нещо, трябва да сте подготвени да носите отговорност за това.

Ако правите грешки и не можете да изпълните тези отговорности, трябва да компенсирате това и да намерите решение. Не си измисляйте оправдания и играйте играта, сочеща с пръст. Не можете просто да отидете на работа и да кажете на всички, че котката просто е изяла вашия изходен код .

Осигурете опции, не се оправдавайте.

Всичко е за счупен прозорец

Тази самотна и студена гледка ми привлече вниманието веднага.

В книгата има история за градска зона, която стана много разхвърляна и пропаднала, всичко заради един счупен прозорец.

Това прилича много на нашия код: когато видим някакъв мръсен код (който можем да видим като счупен прозорец), може да започнем да мислим, че е добре да оставим кода да бъде мръсен. Че е добре просто да се върнем по-късно, което през повечето време никога не правим.

Опитайте се да не оставяте „счупени прозорци“ неремонтирани. Когато намерите такъв код, поправете го възможно най-скоро. Когато продължавате да мислите, че никой няма време да поправи този счупен код, може и да си купите контейнер за самосвал, само за да запазите кода си.

Това, което обсъжда тази глава, всъщност е просто: става въпрос за инициатива и грижа за вашите неща .

Поемете инициативата, бъдете катализатор

Релеен бегач

Също така може да има моменти, в които знаете, че или нещо е всичко добро, или нещо трябва действително да се свърши. Идва ти на ум и просто си мислиш, че е правилното нещо.

Ако просто продължите да мислите, нищо няма да се случи. Или ако просто поискате той да бъде в графика на проекта, може да ви срещнат огромни заявки за развитие на функции и технически дълг. Така се озовава в друга година на дискусия.

Време е да ускорите играта си. Работете каквото можете, не прекалявайте, но също така го направете разумно . След като получите пълната си идея, покажете я на хората. Те може да си помислят, че „Да, може би е по-добре, ако имахме това.“

Покажете им поглед към бъдещето и хората ще се обединят около вас. Бъдете катализатор на промяната .

Още повече, че тази книга ни учи и на основни основи, които често забравяме като програмисти.

Понякога, колкото повече се задълбочаваме все повече в работата си, толкова по-често забравяме за основните неща, които научихме отдавна.

Заети функции за преследване и нови технологични подобрения, често забравяме, че всъщност има много повече неща, на които трябва да обърнем внимание преди да се задълбочим.

Чист код

Приплъзване, пътуване или падане

Един от най-основните принципи, за които често забравяме, е чистият код. Тъй като функциите се натрупват все повече и повече, кодовата база става по-дебела и техническият дълг нараства.

Но винаги трябва да помним да поддържаме нашия код последователен и чист всеки път, когато го пишем.

Едно от нещата, които се споменават в книгата, е принципът СУХО (Не се повтаряйте). Това е свързано с повторната употреба на кода. Дублирането е зло и това е истината. Дублиращият код ще затрудни поддържането на кода ви и може да предизвика объркване, когато трябва да промените функция или да поправите грешка.

Помните ли времето, когато трябваше да поправите част от кода си? И разбрахте, че има код, който много прилича на бита, който току-що променихте? И така, тогава трябва да промените и тази част, и друга също, а след това може би и тази малко ... получавате картината.

Намерете правилните инструменти

Пара тодо решение за сено

Подобно на дърворезба, намирането на правилните и правилни инструменти е много важно. Преди дървар да започне да реже дървета. те трябва да решат - трябва ли им резачка? Или брадвата е достатъчно добра? Или може би има чисто нов светлинен меч, който те могат да използват. Но използването на кухненски нож може да отнеме известно време, за да се отсече дърво.

Подобно е и за програмистите: тази книга ни учи, че е много важно да намерим подходящите инструменти, преди да започнем да работим (като добър редактор на код). Не бива да прескачаме правото на кодиране.

Например, всъщност е възможно да кодирате с помощта на Windows notepad и да го компилирате с помощта на конзолата. Но дали това е правилният инструмент за вас? Опитайте се да намерите най-добрия редактор, който най-удобно да използвате. Ученето и овладяването му ще увеличи вашата производителност няколко пъти.

В книгата са споменати няколко редактора, като Emacs или Vim. Но в наши дни можете да намерите по-модерни редактори на кодове като Visual Studio Code. Намерете такъв, който ви подхожда. Това е като вкуса ви към кафето - някои предпочитат лате, а други капучино.

Не програмирайте по стечение на обстоятелствата

Това е един много важен момент, отбелязан в книгата. Във всички наши програмни пътувания вероятно е имало моменти, когато просто сме кодирали сляпо и неочаквано ... и някак си е работило.

Вероятно не бяхте сигурни какво всъщност правите, така че продължавахте да добавяте все повече и повече код и пак работеше. Това е, докато един ден, когато имаше проблем и не се опитахте да премахнете част от кода и той напълно счупи всичко. И не бяхте сигурни кое парче го е причинило.

Разчитането на неизвестни е много опасно. Когато не сте сигурни какво трябва да прави кодът, опитайте се да го опростите и се уверете, че кодът е надежден сам по себе си, а не само случайно.

Разчитайте само на неща, в които сте сигурни. Не програмирайте по стечение на обстоятелствата.

Единичен тест

Тестването е актуална тема в наши дни. И да, това също беше важна тема преди 20 години (и винаги ще бъде).

Но понякога хората забравят за модулните тестове в наши дни. Може би току-що са завършили кода си и са предположили, че всичко е наред ... докато кодът не се е повредил в производството поради крайни случаи.

За да поддържаме стабилността и рефакторирането безопасно, винаги трябва да поддържаме кода си защитен чрез писане на модулни тестове. И никога не е достатъчно, ако вашите тестове покриват само щастливия път. Извършете безмилостно тестване на вашия код и не забравяйте, че вашият код не е завършен, докато не покриете всеки наличен тест.

Единичното тестване ще ви помогне да бъдете уверени, че вашата част от кода е наистина направена.

Поемане на собственост

Има едно последно нещо, за което искам да говоря. Както знаем, програмистите обичат да оставят „наследство“ под формата на код. И да, през повечето време е лошо.

Като програмист, ние трябва да се гордеем със собствената си работа. Трябва да се гордеем с отговорността, която ни е поверена, и частта от кода, върху която работим.

Когато най-накрая успеем да се гордеем с нашия код и да го притежаваме, ще можем да оставим добро наследство. И хората ще видят нашия код като подпис. Когато видят нашия код, те ще знаят, че той ще бъде солиден и добре написан от професионалист.

Довършване

В тази книга има още повече теми, които не съм обсъждал тук, като изисквания и работа в екип. Ако се интересувате от проучване на тези теми, трябва да се опитате да намерите и прочетете книгата!

Само бележка: колкото и да ми хареса книгата, някои неща просто не изглеждаха свързани, гледайки на колко години е книгата (на 20 години). Той говори за стари езици като Prolog и говори за OOP, сякаш е наистина нова концепция - така че тези странности просто не изглеждат правилни.

Но това не може да бъде обвинено, тъй като вече е на няколко десетилетия.

Освен това повечето неща, обхванати в книгата, все още са доста подходящи за настоящата епоха на програмиране, като тези теми, които разгледах по-горе.

Ако се опитвах да обобщя всичко в тази книга, бих казал, че основно обхваща всичко, което някога съм чел в мрежата, за да стана по-добър инженер .

Благодаря, че прочетохте моята статия за Прагматичния програмист! Надяваме се, че ви е дал известна представа за пътуването ви като програмист или софтуерен инженер. И вземете копие на книгата, ако искате да научите повече.

PS Написах тази статия сам, без никакви средства за реклама или маркетинг от трета страна. Снимката на корицата е взета от сайта на Amazon.