Що робити, коли пахне кодом?

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

Кілька пропозицій:

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

2. Вивчайте та вивчайте схеми програмного забезпечення . Програмні зразки - це перевірені та перевірені методи для виконання певних загальновідомих завдань.

3. Вивчення та розуміння структур даних. Вивчіть відповідне використання та характеристики продуктивності для кожного типу структури даних.

4. Добре знайте свою мову програмування, її сильні та слабкі сторони та як найкраще використовувати її функції.

Вам не потрібно знати все це одразу, але слід вивчити все це з часом.

Моя порада: перестаньте хвилюватися.

Досвід - найкращий викладач, і ви не отримаєте досвіду, якщо не пишете код. Крім того , погано сплановані код , який буде написаний краще , ніж відмінний дизайн , який НЕ .

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

Крім того, не сподівайтеся, що це відчуття "кодового запаху" коли-небудь згасне. У міру оздоровлення ви вирішите деякі проблеми, але почнете помічати нові, більш незрозумілі / вдосконалені.

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

Чи повинен я спробувати навчитися трохи всього одразу?

Я сподіваюся, що не. З іншого боку, ви повинні весь час навчатися та вдосконалюватись.

Читайте книги, проходьте курси, отримуйте кваліфікацію, працюйте над цим, і вам слід удосконалитися.

Моя найкраща порада - зосередити увагу на таких основах, як список, запропонований Робертом Харві. Розробка програмного забезпечення - це складний монстр, на який потрібні роки, щоб навіть віддалено виграти, особливо в темі хорошого дизайну інтерфейсу. Дійсно важко оцінити багато аспектів розробки програмного забезпечення, не попередньо відчуваючи їх. Навіть щось таке базове, як коментування коду, може бути недооцінене. З першого дня вас навчають писати добре задокументований код. Я визнаю, що це було не до того, як я насправді опинився в $$ спробі зрозуміти код, який я написав місяці тому, перш ніж я справді оцінив цінність хороших коментарів. Те саме можна сказати для багатьох програм програмування. Наприклад, інкапсуляція даних, низько зв'язані модулі та чіткі інтерфейси.

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

Розробка програмного забезпечення - це постійний досвід навчання. Задайте багато питань, перегляньте ваш код, зрозумійте, чому пропонуються пропозиції старших людей, не бійтеся ставити під сумнів обґрунтованість пропозицій, які дають більше старших розробників, і більш за все не боїтеся помилитися. Врешті-решт фактор залякування чи відчуття переповненості примхами. Для запису ... криві навчання смокчуть.

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

Погляньте на книгу « Рефакторинг: вдосконалення дизайну існуючого коду» Мартіна Фаулера. Перше, що вам слід зробити - це рефакторинг вашого коду , щоб покращити читабельність коду та зменшити складність, щоб покращити його ремонтопридатність.

Коли ви рефакторируете код, ви вже використовуєте шаблони дизайну , код інкапсуляції тощо.

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

Хороший ресурс - Прагматичний програміст . У розділі "Зламані Windows" описано, де ви себе бачите. Короткий і жалюгідний відгук - це виправити проблеми.

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

• Хороший дизайн дозволить повторно використовувати невелику кількість концепцій у кодовій базі (ідеал - це одна концепція, але на практиці вам може знадобитися ще пара)
• Хороший дизайн дозволить легко зрозуміти, де виправити проблеми (принцип DRY, принцип SRP)
• Хороший дизайн матиме гарну звітність про помилки (пов’язану з вищезазначеною точкою, але називається окремим пунктом, оскільки це часто забуваючий аспект)

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

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

Крім того, дизайнерські шаблони є обов'язковими для знань - подумайте про це, вся ідея наявності шаблонів полягає у вирішенні відомих проблем без повторного винайдення колеса або написання баггі-коду.

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

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

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

Моя порада - сприйміть кожен запах серйозно і спробуйте його виправити. На тему існує багато хороших книг (Чистий код та GOOS - найкращий ІМХО). Але більше, ніж книги ходять на конференції, щоб почути та обговорити з іншими людьми та в Інтернет-спільнотах (список розсилки, групи). Ще краще спробуйте приєднатись до свого локального xxug (dotnetug, глечик, xpug тощо) або знайдете його.

Обговорення з іншими програмістами - це єдиний спосіб, який я знаю, як реально вдосконалитись (якщо тільки вам не щастить працювати разом з іншими спеціалістами-програмістами).