Коли це стає зайвим?

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

Як розробник на багатьох платформах, технологіях і навіть на інфраструктурному рівні; У мене завжди виникає питання, коли я багато роблю?

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

Але де баланс, і як ти знаєш, коли втрачаєш час, не набираєш його ?!

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

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

Я борюся з усіма "архітекторами", керованими резюме, з якими я стикаюся. Бажаю, щоб купол існував! ;)

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

Коли процеси випереджають результати.

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

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

Для мене мені подобається підхід, який Кент Бек висуває в XP (не впевнений, це "його" ідея чи хтось інший, але саме там я вперше почув це):

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

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

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

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

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

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

Ваше запитання досить відкрите, тому я трактую це як "занадто багато роблячи в одній частині проекту":

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

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

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

Але все ж це питання дисципліни та пріоритетності.

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

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

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

найгірший сценарій, звичайно, це коли ти кінцевий користувач / замовник / клієнт! :)