Як мені боротися з паралічем аналізу?

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

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

Що мені робити для боротьби з цією проблемою?

Два простих правила:

1. Зробіть найпростішу річ, яка могла б працювати.
2. Рефактор безперервно.

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

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

Зазвичай, коли я відчуваю це так, це означає, що мені потрібно спробувати:

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

Якщо проблема стосується синтаксису та невеликих фрагментів, тоді:

1. Задоволіть себе тим, що, навіть якщо це некрасиво, воно десь добре інкапсульоване і являє собою суто місцевий вид крихти.
2. Додайте маркери TODO або просто коментарі, які пояснюють, чому код вас помиляє.
3. Перейдіть до наступного завдання.

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

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

Я також вчуся уникати паралічів аналізу, тому нам кудо =) Це часто трапляється, тому що ми хочемо зробити «найкращий дизайн». Насправді "найкраще" - це в очах глядача . Моя формула, щоб уникнути паралічу в аналізі, полягає у застосуванні досить хорошого принципу проектування . Як я це роблю? Я привожу такі змінні, як часові обмеження, графік і запитую себе, що є найпростішим дизайном, який може виконати роботу (це не означає найпростіший) без погіршення якості, але в той же час я переконуюсь, що це перевіряється і відкриті для розширення закриті для модифікації (ВСР)дизайн також. Що я маю на увазі під тестуванням та OCP? Ну а замість того, щоб шукати те, що я вважав найкращим, я розглядав дизайн, який може підказати мені, коли справи йдуть погано, і намагаюся зробити достатньо коду, який дозволяє мені переробляти та вдосконалювати пізніше. Крім того, спробуйте відокремити код, який зміниться, і код, який залишається однаковим. Рефакторинг стає простішим, тому що код, який не повинен змінюватися, є більш безпечним для вашого майбутнього ви чи когось іншого.

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

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

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

Удачі! :)

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

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

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

Після того, як ви створили його і викинули, я б хотів покласти сумніви, що вам буде легше приймати ці рішення.

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

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

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

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

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

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

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

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

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

Ось стратегія, яка поєднує в собі пропозиції Рейна Генріха ( start simple, refactor ) та ammoQ ( timeboxing ):

1. Дайте собі досить суворий часовий обмеження для першого рішення, яке просто працює. Наприклад, 30 секунд для назви змінної. Спочатку ви можете придумати щось подібне x, потім вдосконалити його string, а потім nameпоки не настане час.
2. Потім перейдіть до інших завдань протягом певного часу, наприклад 10 хвилин.
3. Тільки тоді дозвольте собі черговий графік для подальшого вдосконалення свого рішення, наприклад, доuserHandle

Можливі переваги такого підходу:

• знання про повернення до цього пізніше може полегшити поки що проблему
• продовжуючи інші завдання, ви можете просто придумати гарне задовольняюче рішення, не забираючи багато часу
• відпустивши крок після кроку 1 і перебуваючи в кроці 2 , може бути легко тримати крок 3 дуже швидко, як ви хочете продовжити крок 2, і, таким чином, із задоволенням просто виберіть одне гідне рішення і прийміть його

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

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

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

У випадку б) - вам потрібна додаткова інформація, а сидіти на своєму великому жирі А .... цілий день не збираєтесь його надавати. Вийдіть з режиму проектування і перейдіть в режим збору інформації. Прототипи, задавати питання, читати технічні журнали. Що б ви не робили, не спите на ньому занадто довго.

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

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

Сформулюйте проблему, а потім викладіть можливі рішення, що добре в кожному з них тощо.

Хоча це не завжди спрацьовує, процес виведення думок з голови (оперативної пам’яті) та на зовнішній носій (документ блокнота) дає більше свободи для встановлення нових зв’язків та перегляду рішення з різних точок зору.

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

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

TLDR; Виберіть розумне рішення, вдосконалюйте його по мірі просування.

Це також актуально:

Вчитель кераміки в день відкриття оголосив, що ділить клас на дві групи. Усі ті, хто знаходиться на студії ліворуч, за його словами, будуть оцінені виключно за кількістю виробленої ними роботи, а всі справа - виключно за її якістю. Його процедура була простою: в останній день заняття він приносив би ваги у ванній кімнаті і зважував роботу групи «кількість»: п’ятдесят фунтів горщиків оцінили «А», сорок фунтів - «В» тощо. Тим, хто оцінив "якість", проте, для отримання "А" потрібно було виготовити лише один горщик - хоч і ідеальний.

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

з http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Я ніколи цього не розумів. Коли я був інструктором, я сказав би щось на зразок:

"OK, create an integer variable and assign the return value of strlen() to it."

Ви не надто складні, можна подумати, і 95% людей написали щось на кшталт:

int x;   // or y, or len, or whatever
x = strlen( s );

Але іноді знайдеться той, хто сидів, як кролик, паралізований у фарах. Я б співчутливо запитав, в чому проблема, і вони відповіли б "я не знаю, як це назвати!".

Це люди, які повинні шукати іншу кар’єру. Як, можливо, ви повинні.