Обнаружение перебора

Question

Как я узнаю, что я переэтапирую?

Я преследовал проблему последние 3 дня. Я прошел через множество проектов и достиг комплексного решения, используя около 3 классов. Обсудив с коллегой, я понял, что все, что мне нужно, это один метод и struct. Как я могу не быть астронавтом архитектуры ?

Answer 1

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

Так что поговорите с кем-нибудь об этом.

Answer 2

Лично я не могу жаловаться на тех, кто на самом деле ПЛАНИРУЕТ их программное обеспечение первым! Я делаю это, но я знаю много программистов, которые знают, как просто перейти прямо в код ... и мне часто приходится исправлять такой код ...

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

Совет, который я имею для вас, состоит в том, чтобы спросить себя: я думаю о деталях моего решения или о реальной проблеме?

Answer 3

Лучший способ не стать астронавтом архитектуры - это привыкнуть прыгать. Лучший способ прыгнуть - написать несколько тестов, которые пройдут, когда ваша реализация будет полной и правильной. Это заставляет вас противостоять тому, что «сделано» означает с самого начала, и , это обеспечивает проверку работоспособности кода, который будет следовать.

Тогда идите к решению.

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

Answer 4

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

1. Если бы у меня было все время и ресурсы в мире, какое было бы наилучшее решение в любом случае. (Технологически, логически, с точки зрения производительности, опционально решая несколько связанных вопросов, переписывание модулей, которые вы найдете, могло бы быть лучше ...) Проведите свой (чрезмерный) анализ здесь, просто чтобы узнать как можно больше. Запустите тесты, статистику и создайте подтверждение концепции .

2. Чем он отличается от текущей ситуации. В чем разница между результатами двух решений. Есть ли более быстрый способ получить такой же или похожий результат. Почему то или иное изменение решит проблему? Сделайте еще несколько тестов, статистику, обновите ваши доказательства концепции.

3. Найдите способ осуществить требуемые изменения и только необходимые изменения, отбросьте все, что не является необходимым для этого изменения. Убедитесь, что вы не модифицируете ничего, что не было проблемы. Проверьте это, просмотрите изменения в коде, логике, структуре; и свести их к минимуму, если это возможно.

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

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

Answer 5

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

Это также подход TDD.

Answer 6

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

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