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

10

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

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

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

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

Феофанис Пантелидес
источник
1
Мы говорим о таких вещах, как масштабирование для миллиона пользователей с первого дня, когда у вас нет клиентов сейчас? Или более функциональные вещи, такие как сделать так, чтобы налоговые расчеты выполнялись «конфигурируемо», когда нет предположения, что они могут когда-либо измениться, и даже если бы они это сделали, никто не имеет ни малейшего представления, как они могли бы работать в этом гипотетическом новом мире?
Джон Хопкинс
1
Сообщество Wiki в значительной степени устарело. Это никогда не работало, как планировалось. Не беспокойся об этом.
Дэвид Торнли
Когда вы говорите о миллионе пользователей, в вашем словаре не должно быть лишнего.
Theofanis Pantelides

Ответы:

12

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

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

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

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

Сообщество
источник
5
«Я сражаюсь со всеми CV-ориентированными» архитекторами «Я сталкиваюсь» :)
Gratzy
2
Я не обязательно согласен с этим (практически), учитывая неравный уровень разработчиков. Временами я делаю рефакторинг подобных проектов, чтобы использовать общую библиотеку, и она не всегда так удобна для чтения, как раньше.
Theofanis Pantelides
1
Я думаю, очень важно, чтобы каждый член команды достаточно хорошо понимал исходный код, над которым он работает. За богатство вашего проекта, а также чтобы архитектор не был рабом своих собственных реализаций. Поэтому, если в знаниях слишком много различий, сначала исправьте это.
1
Мне нравится ваше первое предложение; ясность кода важна. Но частые проверки кода? Архитектурные дискуссии на ежедневных встречах ... Правда? И что именно означает «архитекторы, управляемые CV»?
Роберт Харви
1
Частые проверки кода означают, что они должны быть автоматическими. Вы пишете функцию, один из ваших коллег рассматривает ее и должен понимать, чтобы ее подтвердить. Если он спрашивает вас, вы работаете вместе, чтобы сделать код лучше. Вы упоминаете свои архитектурные проблемы во время выступления, но обсуждение происходит после. Читайте, кому нужен архитектор ( martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf ).
11

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

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

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

конечная станция
источник
4

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

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

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

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

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

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

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

Джон Хопкинс
источник
Как насчет модуляции всего, а затем просто заменить модули по мере масштабирования? или это тоже перебор !?
Theofanis Pantelides
1
@ Theofanis Patelides - Хорошо структурированный код, очевидно, всегда хорошая идея, но, как и в большинстве случаев, вы, безусловно, можете зайти слишком далеко. Я думаю, что со многими из этих вещей это становится инстинктом со временем - вы знаете, что вы сделали ранее, что сработало, и что было пустой тратой времени.
Джон Хопкинс
1

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

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

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

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

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

gablin
источник
Я согласен, но я также обнаружил, что много раз проводил часы функциональности, а затем передавал их нетехническому конечному пользователю и отказывался от него из-за мелких вещей!
Theofanis Pantelides
1

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

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

Билл
источник
1
Для меня нет ничего более раздражающего, чем отклонение от Плана А
Theofanis Pantelides
1

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

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


источник