У мене була (ймовірно) така ж проблема багато років тому, вона тривала кілька років, і я її подолав. Тож, можливо, вам було б цікаво знати, як я цього досягнув, навіть якщо я не впевнений, що мій шлях стосуватиметься і вас.
Ви також повинні поглянути тут: Сім етапів знань у галузі програмного забезпечення. Це показує, що продуктивність значною мірою є побічним ефектом рівня кваліфікації. Можливо, ви перебуваєте на деякому етапі між етапом 3 та етапом 4 за технологією, яку ви зараз використовуєте (майстерність навичок залежить від технології, ви можете оволодіти деякими технологіями, ще навчаючись інших).
Зараз я починаю з біографічних свідчень.
Трохи контексту. Мені 47. Я почав програмувати в 12 в 80-х. Ще в середній школі я працював за сумісництвом професійним ігровим програмістом. В основному це не отримало у мене стільки грошей, достатньо лише придбати обладнання, але я насолоджувався цим і багато чому навчився. У 18 років я розпочав офіційне вивчення інформатики.
Як результат, коли мені виповнилося 20 років, коли я починав будь-яке завдання програмування, я знав багато способів вирішити задану проблему і був дуже усвідомлений безлічі параметрів і підводних каменів, а також недоліків і обмежень будь-якого методу.
У деяких моментах (скажімо, про 26 років) мені стало важко взагалі написати будь-яку програму. Відкрилося стільки можливостей, що я більше не міг вибрати між ними. На кілька років (зробіть це 6) я навіть припинив програмування і став технічним автором новин.
Я ніколи повністю не переставав намагатися програмувати. І в якийсь момент він повернувся. Ключовим для мене було екстремальне програмування, точніше принцип простоти: "Напишіть найпростішу річ, яка могла б працювати".
В основному я змусив себе не піклуватися про ефективність коду (це був мій основний блокпост, уникайте неефективних проектів), а просто йти найпростішим шляхом. Я також змусив мене менше піклуватися про помилки та затримувати обробку помилок на більш пізній час, після написання тестів, що підвищують помилку (справді це TDD).
Це щось я дізнався, коли писав. Коли я не знаю, що писати, або знав, що пишу, було погано . Просто продовжуй. Насправді пишіть погані речі. Я згодом це виправлю пізніше. Або якщо це дійсно так погано стирає і переписує, але швидше два рази писати речі, які пишуть щось ідеальне з першого разу.
Дійсно, дуже ймовірно, що код, на який ви вважаєте, що добре спочатку писати, потребує вдосконалення, як і справді поганий.
Якщо ви слідуєте шляху простоти, ви також отримаєте додатковий бонус. Ви легко приймаєте для видалення / зміни початкового дизайну / кодування. Ви отримуєте більш гнучкий розум.
У мене також з'явилася звичка вводити тимчасовий коментар у код, пояснюючи те, що я зараз не робив, і мав намір зробити пізніше, коли код буде функціональним у звичайному випадку використання.
Я також відвідував XP Dojo, який практикував коди з іншими програмістами, щоб інтерналізувати практики XP. Це допомогло. Це зробило вищезазначені формальні методи інстинктивними. Також допомогло програмування пар. Робота з молодими програмістами дає певний імпульс, але з досвіду ви також бачите, чого вони не роблять. Наприклад, у моєму випадку я часто бачу, як вони беруть участь у надмірно складних проектах, і я знаю, що може призвести до кошмару дизайну. Пішов таким чином. Зробив це. Були проблеми.
Першочерговим моментом для мене є утримання потоку. Бути швидким - це справді успішно утримувати потік.
Тепер я повернувся як професійний програміст і вважаю, що я і кращий, і швидший, з глибшим розумінням того, що роблю. Практикуючи TDD, я все ще можу трохи повільніше, ніж коли я був молодим биком (і нічого не випробовував), але я також не маю страху рефакторингу і, звичайно, витрачаю набагато менше часу на налагодження (майже зовсім немає часу, роблять це менше 10% часу ).
Підсумовуючи: я подолав свій блоковий код за допомогою гнучких методів (XP), ідучи простотою, потім рефакторингом, і практикуюсь, щоб зробити це інстинктивним. Це працювало для мене. Не впевнений, що це може бути узагальнено для будь-кого іншого.
Щодо рівня набуття навичок, я здебільшого навчився сприймати те, що кожного разу, коли я змінюю технологію (вивчаю нову мову, нові рамки тощо), я пройду етап, коли буду гальмувати. Це нормально, і з часом це подолає. Я також можу компенсувати це хорошою методологією та навичками програмування загального призначення, і це не буде великою проблемою.
