Секрет швидкого програмування: не замислюйтесь



Програмувати швидко — це легко! Так вважає інженер-програміст компанії Google, який всі публікації в своєму блозі підписує лаконічним «Макс». Макс також працює головним архітектором, ком'юніті-менеджером і реліз-менеджером в Bugzilla Project. Ми в Alconost вразили і перевели його поради про те, чи як навчитися програмувати з космічною швидкістю.

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

Вони, звичайно, мають рацію в тому, що в умовах стислих термінів розробники, як правило, будуть писати складний код. Втім, дедлайни не повинні призводити до складності. Замість фрази «Цей дедлайн завадив мені написати простий код» можна вимовити рівноцінну: «Я недостатньо швидко програмують, щоб писати просто». Тобто чим швидше ви як програміст — тим менше впливу на якість вашого коду мають дедлайни.

Тепер давайте розберемося, як, власне, стати швидше? Може, це вроджене магічне вміння? Треба бути «розумнішими» інших, щоб бути швидким?

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

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

Може, це звучить неймовірно, але працює виключно добре. Задумайтеся: коли ви сидите перед вашим редактором, але робота йде нешвидко, бо це, що у вас низька швидкість набору? Я сумніваюся: «занадто багато набирати» — рідкісна проблема программистской продуктивності. Паузи, коли ви не набираєте, — ось що все уповільнює. А чим зазвичай зайняті на таких паузах розробники? Намагаються перестати думати — може бути, про проблеми, про інструменти, про повідомлення в пошті, та про що завгодно. Але всякий раз, коли таке трапляється, воно означає проблему. Роздуми самі по собі — не проблема, але ознака якоїсь іншої проблеми. Ймовірно, замість того, щоб ходити по колу в своїх думках, вам варто звернути увагу на щось з цього:

Розуміння
найпоширеніша причина непродуктивних роздумів розробника — неповне розуміння якогось слова або символи.

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

Таких варіантів — безліч. Багато хто користується мовою програмування, не розбираючись, що (, ), [, ], {, }, +, * і % означають в цьому мові. Деякі розробники не розуміють, як насправді працює комп'ютер. Пам'ятаєте мій «Єдиний секрет програміста-рок-зірки»? Ось де суть! Адже якщо ти по-справжньому розумієш, тобі не треба припиняти непотрібні роздуми. Це також спонукало мене написати книгу: розуміння того, що є непорушні закони створення програмного забезпечення, може позбавити від багатьох епізодів «боротьби з роздумами».

Так що, якщо ви опинилися в розумовому глухому куті, не намагайтеся вирішити проблему в своїй голові — шукайте те, чого не розумієте, поза себе. Після чого візьміть і подивіться на щось, що допоможе вашому розумінню. Це стосується навіть до питань на кшталт «Прочитає чи коли-небудь користувач цей текст?» У вас може не бути Департаменту досліджень користувацького досвіду для цього відповіді на це питання, але ви можете хоча б намалювати що-небудь, показати іншим, вислухати їх думку. Не намагайтеся просто сидіти і думати — зробіть. Тільки дія веде до розуміння.

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

Починання
Іноді проблема в тому, що «немає уявлення код, який потрібно починати писати». Найпростіше рішення — почати писати будь-який відомий вам код, який ви можете писати прямо зараз. Виберіть частина проблеми, яку ви повністю розумієте, і пишіть для неї рішення, навіть якщо це всього одна функція чи не найважливіший клас.

Часто фрагмент коду, з якого найпростіше почати, — це «ядро» програми. Наприклад, якщо б я взявся писати додаток YouTube, я б почав з відеоплеєра. Сприймайте це як вправу по безперервного постачання: пишіть код, який дійсно спочатку створює продукт — неважливо, яким дурним або незначним він може виходити. Відеоплеєр без користувальницького інтерфейсу — вже продукт, виконує корисну завдання (відтворення відео, навіть якщо ще не повноцінний.

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

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

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

Не перестрибуйте кроки при розробці своєї системи — і це дозволить вам бути продуктивним.

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



Відволікаючі фактори
Коли розробник відволікається на щось зовнішнє, наприклад, шум, йому може знадобитися деякий час подумати, щоб згадати, над чим він працював у своєму рішенні. Відповідь тут відносно простий: перед тим, як сідайте за розробку, переконайтеся, що ваше оточення не потурбує вас або відволікаючі фактори не будуть вас переривати. Одним потрібно закрити двері в свій офіс, іншим — надіти навушники, комусь- поставити статус «Не турбувати»: зробіть так, як вам треба. Можливо, вам знадобиться допомога вашого менеджера або співробітників, щоб створити дійсно сприятливу для розробки середу.

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

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

Бездіяльність
Все перераховане вище — ключ до того, як бути швидким програмістом, коли ви сидите і пишете код. Якщо ж ви весь день читаєте пошту і ходите по зустрічам, а програмувати вам колись — це інша проблема. Деякі її аспекти схожі (це як якщо б організації довелося «не замислюватися»), але це не те ж саме.

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

вам такий підхід?

Про перекладача

Переклад статті виконаний в Alconost.

Alconost займається локалізацією додатків, ігор і сайтів на 60 мов. Перекладачі-носії мови, лінгвістичне тестування, хмарна платформа з API, безперервна локалізація, менеджери проектів 24/7, будь-які формати строкових ресурсів.

Ми також робимо рекламні та навчальні відеоролики — для сайтів, що продають, іміджеві, рекламні, навчальні, тизери, эксплейнеры, трейлери для Google Play і App Store.

Детальніше: https://alconost.com

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.