Чи нормально думати про проблему дизайну цілими днями без написаного коду? [зачинено]

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

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

Залежно від проблеми, яку ви намагаєтеся вирішити, фаза проектування може тривати тижні і місяці (якщо не роки), а не лише дні.

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

Це зазвичай називають "паралічем аналізу"

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

Рекомендується ознайомитись з Прагматичним програмістом, зокрема з розділу 2 "Кулі слідів"

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

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

Це залежить від того, що веде вас до цього та ваших причин. Ось декілька:

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

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

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

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

Це природне явище і добре, що розробник перехоплює свій час і між ними.

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

На мій погляд, існує три підходи, кожен підходить для конкретної ситуації кодування

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

   => Використовуйте BDD / TDD, починаючи з бажаних рішень і працюючи над кодом. (Добре, іноді я обманюю і пишу трохи коду, а потім тест - вид вкладеного 2. -> 1. підходу).

2. Я маю гарне уявлення про шаблони, які слід застосувати, але я не впевнений, як має виглядати рішення.

   => Прототип, щоб побачити, які цікаві речі вискакують. Перейдіть до 1., коли я з’ясую, які цікаві речі бажані.

3. Я не впевнений, які шаблони застосовувати.

   => Подумайте про проблему та як різні способи підходу до проблеми впливають на код. Перейдіть до 2) або 1) залежно від результату цієї вправи.

Іншими словами, відповідь є улюбленим інженером: Це залежить.

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

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

• Створіть артефакти дизайну. То що робити, якщо ви не пишете код? Можливо, ви просто записуєте журнал своїх думок. Або ескіз загального рішення. Або навіть просто справжній підсумок проблеми, який ви вдосконалюєте з часом. Розглядаючи ідеї та приймаючи / відкидаючи їх, ведіть журнал своїх міркувань з цього приводу. Таким чином, наприкінці дня ви все ще можете вказати на реальні результати як доказ вашої праці.

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

Як сказала Сатчель Пейдж, "Іноді я сиджу і думаю, а іноді просто сиджу".

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

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

Програма = Алгоритм + Структура даних

ІМХО, процес проектування (вирішення проблем) повністю правила. Деталі щодо впровадження (технічного питання) випливають і вирішуються природним шляхом.

Ось мій роздум.

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

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

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

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

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

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

Тож справжня порада: «Використовуйте кожен інструмент навчання, необхідний для наближення до визначення проблеми» , а також «пам’ятайте, що це інструменти для навчання, тому не закохуйтеся в них» і код, і ескізи призначені для викидання. .

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