Хороший програміст, який працює над власним проектом, може тримати його повністю в голові так, як математик тримає в голові рівняння, яке вирішує. Математики не вирішують завдання на клаптику паперу, так, як цьому вчать дітей в школі. Замість цього більшість операцій вони проводять в думці, створюючи якийсь образ в голові, приблизно як ми можемо в думках представити образ будинку, в якому провели дитинство. З програмуванням все так само. Ви можете створити якийсь образ всього поточного проекту в голові і розглянути його ретельно з усіх боків.

Це найчастіше буває потрібно на початковому етапі, коли однією з найважливіших речей є можливість поміняти те, що ти робиш. Не просто вирішити задачу іншим способом, а поміняти саму її суть.
Але вмістити цілу програму в голові не так те просто. Якщо з якої-небудь причини ви не зверталися до коду декілька місяців, може бути потрібно до декількох днів, щоб знову в нього вникнути. Навіть коли ви активно працюєте над програмою, для налаштування власної свідомості на роботу над поточним завданням може знадобитися до півгодини кожного ранку. І це лише в кращому разі. Типові програмісти, які працюють в офісних умовах, не можуть справитися з цим і до самого закінчення робочого дня. Кажучи іншою мовою, типовий офісний програміст ніколи не розуміє цілком завдання, яке йому доводиться вирішувати.

Навіть кращі з кращих програмістів часом не мають цілісного представлення програми в своїй голові. Якщо вам здається, що останнє відноситься і до вас, то нижче пропонуються способи вирішення цієї проблеми:

1. Якомога менше відволікайтеся. Відволікання уваги може зіграти погану роль в роботі людей безлічі професій, але особливо це явно для програмістів, які часто працюють з величезною кількістю деталей, які доводиться пам'ятати, що перевищує всі мислимі і немислимі межі.

Наслідки від перемикання уваги на стороннє завдання залежать не стільки від його тривалості, скільки від ступеня відвернення уваги цим завданням. Так, наприклад, програміст може вийти з офісу, перекусити бутербродом сидячи на лавці, ні на хвилину не відволікаючись в цей час від програми, над якою працює.

Особливо шкідливими можуть бути незаплановані ситуації, які віднімають значно більше уваги, чим заплановані, перед якими програміст зазвичай і не починає ніяких серйозних завдань.

2. Працюйте запоєм. Оскільки кожного разу перед початком роботи необхідно втягнутися в поточне завдання, очевидним рішенням по мінімізації непотрібних витрат є довга робота без значних перерв. Зрозуміло, нескінченно працювати неможливо, і воднораз ви зрозумієте, що остоточно "отупіли" від роботи. Швидкість настання такого стану залежить виключно від особливостей конкретної людини. Є люди, які працювали по 36 годин підряд, дні безперервно.

Оптимальний варіант це не той, який максимально допускають ваші фізичні і, мабуть, психічні здібності. Іноді, коли ви робите перерву в роботі, а потім повертаєтеся, до вас приходять несподівані рішення, вироблені вашим мозком поки ваші думки, здавалося б, були далекі від програмної коди. Працюйте довго, але з розумом! Не вдавайтеся в крайнощію

3. Пишіть на лаконічних мовах. Могутні мови програмування роблять ваші програми коротше. Програмісти думають про програми, принаймні частково, на тій мові, на якій їх пишуть. Чим лаконічніша мова, тим коротше програма, і тим легше відновити в своїй пам'яті її образ.

Ви можете досягти ще більшого ефекту використовуючи висхідний стиль програмування, коли ви пишете програми що складаються з абстрактних шарів, нижні з яких створюють базу і програмну оболонку для верхніх. Якщо ви робитимете це правильно, вам достатньо буде зберігати в своїй пам'яті лише самий верхній шар.

4. Постійно переписуйте програми. Переписуючи код, ви часто покращуєте архітектуру додатку. Навіть якщо і ні, в цьому є перевага: щоб переписати програму наново, необхідно повністю розуміти її суть. Так ви зможете відтворити точнішу картину програми у себе в голові.

5. Пишіть код, який зручно читати вам. Всі програмісти знають як добре писати код, який легко читається. Але ви самі є найбільш важливим читачем свого кодк. Особливо на початку проекту; створення прототипу майбутнього проекту це ваш діалог з самим собою. Коли ви пишете самі для себе, перед вами постають абсолютно інші пріоритети. Коли ви пишете для інших, ваш код може розмазуватися на безліч рядків для кращої читабельності. Коли ж ви пишете код для того, щоб його можна було легко відновити в пам'яті, ви швидше віддасте перевагу стислості.

6. Працюйте маленькими групами. Коли ви представляєте програму в своїй уяві, ви приділяєте основну увагу власноручно написаному коду, частини ж, написані іншими людьми, ви розумієте не настільки добре і не можете так живо представити їх. Таким чином, чим менше програмістів працюють над проектом, тим цілісніше ви здатні представити його образ. Якщо ви працюєте над ним поодинці, ви здатні на все.

7. Не допускайте редагування одного і того ж коду декількома людьми. Як я вже сказав, ви ніколи не сожете зрозуміти чужий код так само добре як власний. Не має значення як ретельно ви його прочитали, ви всього лише прочитали його - не написали. Таким чином, якщо ділянка коду написана декількома людьми, то жоден з них не має повного і цілісного його уявлення.

І безумовно, ви не зможете щось кардинальне поміняти в нім. Не просто тому що вам потрібний для цього дозвіл, а тому що ви просто не можете уявити собі цього. Реорганізація коду, написаного декількома людьми це як реорганізація законів всесвіту. Реорганізація власного коду, це просто інша інтерпретація неоднозначного образу програми, що знаходиться у вашій голові.

Якщо вам необхідно декілька людей для розробки одного проекту, розділіть його на частини і виділите по одній кожному програмісту.

8. Починайте з малого. Чим доскональніше ви вивчаєте програму, тим легше вам створити її уявний образ. Ви можете представляти окремі частини готової програми як чорні коробки виконують свої функції не вдаючись до деталей реалізації до тих пір, поки не будете до цього готові. Коли ж ви починаєте новий проект, вам просто необхідно утримувати його в голові повністю. Якщо ви почнете з дуже складного і об'ємного завдання, ви, ймовірно, ніколи не зможете охопити її цілком. Якщо перед вами постає подібне завдання, почніть не з його формального опису, а з написання прототипу, який вирішує одну з підзадач. Які б не були переваги планування, вони часто не так значні в порівнянні з перевагами, які ви отримуєте від можливості тримати весь проект у себе в голові.

Дивно як часто програмісти дотримуються всіх восьми пунктів навіть не підозрюючи про їх існування. Коли у когось з'являється ідея, йому доводиться займатися нею поза робочим часом, оскільки вона не має офіційної підтримки керівництва. Це приводить до продуктивнішої роботи з причини відсутності відволікаючих чинників. Ведений вперед чистим ентузіазмом програміст працює ночі безперервно. Оскільки його проект носить виключно екпериментальний характер, він пише код не на мовах, які являються корпоративним стандартом, а на лаконічних ськриптових мовах. Він повністю переписує програму наново, що не дістало б схвалення вищестоячих людей, якби це було офіційною розробкою. Але в даному випадку це особистий проект, і він хоче зробити його ідеально. Враховуючи, що ніхто окрім нього не побачить код, він пише його якомога більш стисло і коротко, так, щоб було легко узятися за нього після перерви. Проектом зайнята лише невелика к-ть людей, навіть якщо він пише його і не один, оскільки зміни коду відбуваються так швидко, що немає можливості підключати до проекту когось ще.
І нарешті, він починає з малого, тому що його задумка спочатку дійсно була невеликою і скромною.

Ще дивовижнішим є число офіційних проектів, які якимсь чином вмудряються порушувати всі вісім «правил». І справді, якщо ви поглянете на методи розробки програмного забезпечення в більшості організацій, то побачите що вони нібито навмисне роблять все неправильно. У деякому роді так і є. Однією з відмінних рис організацій є сприйняття людей як взаємозамінних частин загального механізму. Це працює добре для завдань, що допускають розпаралелювання завдань між учасниками, таких, наприклад, як війна. У всій історії немає жодної згадки випадку, коли добре організована армія натренованих найманців поступалася б армії, що складається з самостійних воїнів, наскільки б доблеснимі вони не були. Але розумовий процес не дуже то і можна розподілити між людьми. А що таке програмування, якщо не розумовий процес.

Не зовсім вірне твердження, що організації заперечують можливість бути залежними від одного геніального співробітника. Просто в нашому сьогоднішньому розумінні, організації за визначенням повинні не допускати цього.

Можливо, нам варто дати визначення новому типу організацій, які б використовували спільну діяльність окремих співробітників без необхідності для них бути взаємозамінними. В деякій мірі ринок можна назвати подібного роду організацією, хоча вдалішим описом був би опис ринку як виродженого випадку, того, що виходить само собою, коли організація недоречна.

Може бути нам варто вибрати якийсь обхідний шлях і зробити так, щоб програмісти працювали відмінно від інших співробітників. Ймовірно для великих компаній оптимальним рішенням не провадити ідеї самостійно, а купувати їх у інших. Не дивлячись на те, яке з рішень буде доречне у кожному конкретному випадку, необхідно спочатку усвідомити існування проблеми. У самій фразі «компанія розробки ПЗ» поміщено суперечність. Слова неначе відштовхуються один від одного в протилежних напрямах. Будь-який хороший програміст відчуватиме себе в чужій тарілці, знаходячись у великій організації, оскільки організації придумані такими, щоб недопуськать того, чого програміст більше всього жадає.

Хороший програміст у будь-якому випадку справляється з безліччю завдань. Проте у багатьох випадках для цього йому доводиться мало не організовувати повстання проти власної компанії. Така поведінка обумовлена самими вимогами до його роботи. Програмісти з головою йдуть в програмування, забуваючи про інших своїх обов'язках, кидаються писати код, не описавши його спецфікаций, переписують вже працюючий код не тому що безвідповідальні. Вони вважають за краще працювати поодинці і гніваються на голови колег, що вітаються, періодично показуються з дверей, не тому що не доброзичливі або замкнуті. Що цей здається абсолютно випадковим набір звичок в їх поведінці має єдину причину: необхідність тримати в своїй голові весь проект цілком.

Допоможе чи ні розуміння цього великим компаніям, воно безумовно може допомогти їх конкурентам. Найбільш слабке місце таких компаній в тому, що вони не дозволяють програмістам виконувати значущу роботу. Якщо ви маленька початкуюча компанія, то скориставшись цим ви можете скласти їм значну конкуренцію. Просто враховуйте особливості завдання, яке мозок програміста повинен брати на себе цілком.

Оригинал: http://ua.redtram.com/redirect/news/62831416/