Как да задържим програма в главата си

от Българският сайт за математика

Как да задържим програма в главата си

есе

автор: Поул Греам

превод: Павел Пенев(pavelludiq)

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

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

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

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

Дори най- добрите програмисти не винаги имат цялата програма, вад която работят, заредена в главата им. Но има неща които може да направите, за да си помогнете:

1. Избягвайте разсейките. Разсейките са лоши за много видове работа, но са особено лоши за програмирането, защото програмистите работят на ръба на детайлите които могат да обработят.

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

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

2. Работете в дълги интервали. След като има фиксирана цена всеки път когато седнете да работите върху програма, по ефективно е да работите в няколко, но дълги сесии, от колкото много, но кратки. Разбира се ще дойде моментът при който ще затъпеете, защото сте уморени. Това варира от човек на човек. Чувал съм за хора които са хакерствали по 36 часа нон-стоп, но аз най много съм изкарвал 18. И работя най добре в интервали от по 12.

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

3. Използвайте сбити езици. По мощни езици правят програмите по къси. И програмистите мислят за някоя програма, поне частично в езикът който използват в момента. Колкото по сбит е езикът, толкова по кратка е програмата, и толкова по лесно е да я заредите и използвате в главата си.

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

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

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

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

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

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

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

8. Започнете с малко. Програмите стават по лесни за задържане в главата ви, колкото повече ги разбирате. Можете да ги третирате като черни кутии когато чувствате че сте ги опознали напълно. Но когато започвате да работите над някой проект, трябва да виждате всичко. Ако започнете с прекалено голям проблем, може никога да не успеете да го разберете напълно. Така че ако трябва да работите върху голяма и сложна програма, най- добрия начин да я напишете може би не е да напишете спецификация за нея, а да напишете малък прототип, който да решава малка част от проблема. Каквито и да са предимствата на планирането, те почти винаги са по малко от предимствата на това да можеш да задържаш програмата в главата си.

Удивително е как програмистите могат инцидентно да уцелят всички 8 точки. Някой има идея за нов проект, но понеже не е официално поддържан от фирмата, трябва да работи върху него в извън работно време, което се оказва по продуктивно, защото няма разсейки. Движен от ентусиазмът си за проекта, той работи много часове нон стоп. Тъй като това е просто експеримент, той използва обикновен "скриптов" език, който се оказва по мощен. Той напълно пренаписва програмата няколко пъти; това не би било разумно за официален проект, но той обича трудът си, и иска да е перфектен. И след като никой няма да го чете, освен него самия, не пише никакви коментари, освен тези към него самия. Работи в малка група, защото или не е казал на никого, или е прекалено необещаващо, и на никой не му е позволено да работи по него. Дори да имат група, те не редактират един и същ код, защото той се променя прекалено бързо, и това е невъзможно. И проектът е малък, защото идеята е малка в началото, той просто има някакъв интересен хак който иска да изпробва.

Още по удивителна е цифрата а официалните проекти които успяват да направят всички 8 точки грешно. Всъщност ако погледнете как се пише софтуер във някоя организация, може да си помислите че те нарочно се опитват да направят нещата грешно. В определен смисъл, наистина се опитват да го правят грешно. Една от основните черти на организациите, е да се държат с индивидите като със сменяеми части. Това работи за много различни дейности като воденето на войни. През по голямата част от историята, една армия от добре организирани войници, би могла да победи армия от индивидуални войни, без значение колко умели са те. Да имаш идеи не е много приложимо. И точно това са програмите: идеи.

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

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

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

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

Без значение дали го разбират или не, това може да помогне на големите компании, със сигурност може да помогне на конкуренцията им. Слабото място на компаниите е че не оставят индивидуалните програмисти да вършат гениална работа. И ако сте малка компания, това е мястото където трябва да ги ударите. Работете върху проблемите които трябва да бъдат решени в един голям мозък.

оригинален източник: http://www.paulgraham.com/head.html

Ако намерите места където преводът не е достатъчно точен, или ясен(има такива със сигурност) Дебъгвайте смело. Също и с правописни, пунктуационни и всякакви такива грешки. Никаква милост!!! :D