Застряг через "занадто багато знання" [закрито]

Зверніть увагу на більше обговорення на веб-сайті http://news.ycombinator.com/item?id=4037794

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

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

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

Це неправильно? Це природна еволюція, чи я загнав себе в колію?

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

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

Причини:

1. Аналіз паралічу / Над технікою / позолотою / (будь-яке інше "занадто багато думок вперед може завдати вам шкоди").
2. Занадто багато досвіду для даного завдання.
3. Не зосереджуючись на тому, що важливо.
4. Не вистачає досвіду (і розуміючи це).

Рішення (не узгоджуються з причинами):

1. Тестування спочатку.
2. Почніть кодування (+ для розваги)
3. Один для викидання (+ один API для викидання).
4. Встановити часові обмеження.
5. Спустіть пуху, залиштеся з речами.
6. Зробіть гнучкий код (начебто навпроти "кого викинути", ні?).

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

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

Думати про ці речі, безумовно, добре, але не дозволяйте це зупинити ваш прогрес.

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

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

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

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

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

40 років тому Фред Брукс писав про це "Напиши, щоб викинути, все одно". Нічого не змінилось........

Це неправильно? Це природна еволюція, чи я загнав себе в колію?

Це залежить. Це, як правило, є спільним кроком на шляху розробника.

1. Почніть кидати лайно разом, покусайте його в дупу
2. Почніть з інженерії живого пекла з усього, зрозумійте, що ЯГНИ
3. Поставтеся на деякому прагматичному середньому майданчику, де легкі речі ляпають разом, і важко / ймовірно, що матеріал може бути забезпечений достатньою технікою, щоб зробити його досить легким для роботи / зміни.

Це лише колії, якщо ти залишишся під номером 2.

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

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

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

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

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

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

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

1. Визначте епіцентр : Подумайте про свій проект як на хот-дог, епіцентр - хот-доги. Ви можете взяти будь-яку іншу спецію / заправку / овоч зі своєї підставки і все ще мати можливість продати хот-доги. Яка головна мета вашого програмного забезпечення? Виділіть з нього будь-яке інше додавання та / або додану цінність і сфокусуйтеся спочатку на епіцентрі.
2. Продовжуйте повторювати себе "робити це пізніше, значить робити це краще" : дивіться, де це має сенс, і покладіть на нього трохи "на потім". Якщо ви зробите це добре і думаєте про його використання в реальному світі, ви отримаєте той самий дизайн, але з пріоритетом у дорожній карті.
3. Зменшити-відключити-відкинути : Який би дизайн модуля ви не зробили, це настільки ж просто / суттєво / чисто / універсально, як це можливо (іноді це можна досягти, навіть не видаляючи функції). Коли ви не можете її додатково спростити, починайте роз’єднувати елементи, які могли б існувати самі по собі і мати мету. Зрештою, якщо у вас ще є трохи жиру, ви зможете просто відрізати його.
4. Відокремте "код бібліотеки" від "виробничого коду" : Код, який не можна повторно використовувати, завжди буде використовувати, але він завжди додає шуму дизайну. Цей код - той, що містить правила ведення бізнесу. Ви побачите, що іноді деякі правила ведення бізнесу просто змінюються легше та швидше ( надзвичайно важливо ), ніж із надійною конструкцією. Ви знайдете код, на який можете розраховувати, і код, який клієнт повинен змінити або повторно доповнити в майбутньому. Ви хочете, щоб вони зберігалися якомога більше окремо.

І BTW, крок 0: "з глузду з дизайном". Це допомагає мені вийти з системи та часто знаходити нові наслідки, приховані вимоги та навіть нові функції.

Я взяв 1 і 2 з Rework .

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

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

Є лише дві речі, про які ви дійсно повинні пам’ятати при написанні та розробці програмного забезпечення: ремонтопридатність та коректність.

Правильність є найважливішою короткостроковою і легко її можна довести тестами.

Ремонтопридатність допоможе пізніше в розвитку, але важче відкласти.

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

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

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

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

Я думаю, вам слід подумати про зміну роботи. Можливо, вам слід вивчити нову мову програмування.

У мене була така ж проблема 15 років тому. Я хотів написати ідеальний, багаторазовий, універсальний, .... код, який зробив рішення набагато складнішим, ніж потрібно. Сьогодні я розглядаю це як золото . Що мені дуже допомогло - порада колеги:

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

Це просто параліч шляхом аналізу. Це трапляється з багатьма людьми у багатьох сферах. Ви можете прорватися через нього.

Відповідь - ПОВЕРНЕНО З НЕЮ ;-)

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

Коли у вас є велика програма, і ваш мозок працює понаднормово - просто спершу кодуйте прості випадки. Спочатку програма повинна запускатися, потім повинна брати вклад і т. Д.
Ваша задача полягає в тому, щоб залишити речі легкими для оновлення та рефакторації згодом, але код ОБОВ'ЯЗКОВО не бути складнішим, ніж потрібно для виконання завдання.

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

Код наступного завдання - ТІЛЬКИ. Код - це просто і добре, тому його легко переробити за потреби. Переконайтеся, що програма працює. Повторіть.

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

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

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

Неможливо все виправити, а в деяких випадках навіть БУДЬ-як правильно, коли ви починаєте, тому що дизайн - це справді подорож відкриття; це останнє, що з'явилося, не перше, що потрібно зробити.

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

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

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

У мене є кілька образів, які я маю на увазі, коли я роблю великий. Одна з них - грати з Лего. Я складаю його разом і розбираю за бажанням. Що я починаю робити, можливо, це не те, що я закінчую робити. Я займаюся серфінгом і надаю перевагу можливостям, які мені спадають на думку, коли я йду разом, часто відтворюючи цілі цілком на місці в момент спалаху натхнення ... ось що Творчість ЦЕ.

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

Ви не знаєте занадто багато; ти не знаєш достатньо! І ви лише нещодавно це зрозуміли.

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

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

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

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

Робіть кодування у вільний час, як ви робили 10 років тому, з меншими турботами та просто веселощами.

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

Ні, ви ще недостатньо знаєте.

Збагатіть свої знання, наприклад, цими простими правилами:

• KISS: Нехай це буде маленьким і простим.
• ЯГНІ: Вам це не знадобиться.
• Гірше краще: деякі гірші рішення насправді кращі з точки зору ремонту.

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

Підсумовуючи: зробіть свій код досить гнучким, але не більше. Натомість зробіть себе самостійно гнучким, придбайте книгу з рефакторингу.

Дві речі:

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

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

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

Немає нічого поганого. Ви лише помітили, що настав час вдосконалити свій процес: у цьому випадку ваш процес мислення.

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

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

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

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

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

Ви недостатньо нещадні

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

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