Способи зламати "Синдром ідеального програміста" [закрито]

Я, мабуть, не єдиний, хто так відчуває. Але я маю те, що я, як правило, називаю "Синдром ідеального програміста", який багато хто може сказати - це те саме, що бути перфекціоністом, але в цьому випадку це в області програмування. Однак область програмування є дещо проблематичною для такого синдрому.

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

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

Поставте пріоритет . Насамперед. Зосередьтеся на тому, що має значення.

Ваші пріоритети можуть відрізнятися, але загалом вам слід подбати про:

• Правильний код
• Підтримуваний код
• Чистий код
• Простий, елегантний код
• Ефективний код

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

Зробіть це спрацьованим, все інше майже не має значення для вирішення проблем, які потрібно вирішити. Звичайно, я теж від цього страждаю. Те, що я дізнався, що допомагає, - це просто зосередитись на рішеннях, які працюють . Досить. Це 99% роботи.

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

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

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

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

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

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

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

Зрештою, важливіше всього іншого - це те, що програмне забезпечення працює і може бути використане. І цього не станеться, якщо ви цього не закінчите.

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

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

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

Зробіть це навпаки.

Замість "що можна зробити краще?" шукати "що мене злить?" поки нічого не робить.

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

Зробіть його робочим, зробіть його чистим, зробіть його твердим, зробіть його діючим.

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

Елегантність коду має бути досягнута там, коли програміст помічає можливість, і це, як правило, функція спрощення, очищення та в цілому поліпшення читабельності та ремонтопридатності коду, виконуючи попередні кроки. Це не те, щоб бути максимальним .

Код виконавця майже завжди викликає найменше занепокоєння в мовах, керованих пам'яттю (Java, сім'я .NET, більшість функціональних мов тощо). У цих середовищах мета полягає в тому, щоб записати правильну коду ("правильний" тут визначено як отримання очікуваного результату у всіх очікуваних випадках, і , зрозумілу та добре структуровану, і, таким чином, досяжну), а продуктивність другорядна (зазвичай це буде виходити певною мірою від правильного коду). У всіх випадках алгоритм працює, коли він "досить хороший". Пам’ятайте, «передчасна оптимізація - корінь усього зла»; Оптимізація, яку ви не знаєте, вам знадобиться, витрачає трохи більше, ніж витрачати час, придушувати код і взагалі запобігати прогресу. Спершу він повинен працювати, потім, як тільки він працює, ви запускаєте його і бачите, як швидко він працює. Якщо це недостатньо швидко (як визначено деяким орієнтиром, який є опублікованою вимогою),і тоді ти зупинишся .

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

Підхід, який потрібно застосувати, - це "виконати" у своєму професійному житті. Поставте і рухайтеся далі. Збережіть свій перфекціонізм для особистих проектів.