Когда это становится излишним?

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

Как разработчик, на многих платформах, технологиях и даже на уровне инфраструктуры; Я всегда задаюсь вопросом, когда я делаю слишком много?!?

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

Но где баланс, и как вы узнаете, когда теряете время, а не набираете его ?!

Вы делаете слишком много, когда обычный разработчик не может понять, что вы сделали , читая ваш код.

• Делайте частые обзоры кода с вашей командой.
• Обсудите с архитектурами, технологиями или шаблонами, которые вы планируете использовать. (в ежедневных встречах, если они у вас есть)

Я сражаюсь со всеми "архитекторами", которых я ищу. Я желаю, чтобы купол существовал! ;)

Я считаю, что мир тратит огромную кучу денег, которые мы могли бы использовать вместо этого для улучшения нашей (программистской) жизни.

Когда процессы настигнут результаты.

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

Вот почему никогда не следует забывать, что цель обзоров кода, шаблонов проектирования и т. Д. Состоит в том, чтобы сделать код лучше, но сами они не являются целью.

Мне нравится подход, который Кент Бек выдвигает в XP (не уверен, что это «его» идея или идея кого-то другого, но именно там я впервые ее услышал):

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

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

Это время, которое можно вкладывать в вещи, которые пользователи действительно хотят и используют, вещи, которые дадут им преимущества, которые значительно перевесят даже неудобства, которые будут вызваны в маловероятном случае, когда одна из этих вещей действительно произойдет.

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

Так что для меня, если вы знаете или можете быть совершенно уверены, что что-то является требованием или будет вызывать проблему, то решайте ее, если нет, то не делайте этого.

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

Ваш вопрос довольно открытый, поэтому я буду интерпретировать его как «слишком много дел с одной частью проекта»:

Для меня легко тратить слишком много времени на то, что на самом деле не приносит большой выгоды для клиента. Часто это такие крошечные вещи, как «Ну, это работает, но не совсем так, как я этого хочу», когда клиенту, вероятно, было бы все равно, работает ли он так или иначе.

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

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

Но все же, это вопрос дисциплины и расстановки приоритетов.

Когда я отвечаю "нет", я собираюсь злиться, я не делал этого позже, и это кусает меня ..

Ресурсы и временные ограничения в IRL обычно заставляют меня задуматься, прежде чем мне придется много задавать этот вопрос. В этот момент вы просто сосредотачиваетесь на самых важных / достижимых моментах и ​​надеетесь на лучшее.

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

Конечно, худший сценарий - это когда вы - конечный пользователь / клиент / клиент! :)