Как вы предотвращаете сложные решения или проекты?

Ответ 1

Привлечение кого-то нового, чтобы посмотреть на него.

Ответ 2

Если его слишком сложно проверить, ваш дизайн слишком сложный. Это первая метрика, которую я использую.

Ответ 3

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

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

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

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

Ответ 4

Вот некоторые идеи, чтобы упростить дизайн:

• прочитайте некоторые книги и статьи по программированию, а затем примените их в своей работе и напишите код
• прочитайте много кода (хорошего и плохого), написанного другими людьми (например, проекты с открытым исходным кодом) и научитесь видеть, что работает, а что нет
• постройте безопасные сети (модульные тесты), чтобы включить эксперименты с вашим кодом.
• используйте управление версиями, чтобы включить откат, если эти эксперименты ошибочно меняются.
• TDD (разработка, основанная на тестах) и BDD (поведение, управляемое развитие)
• измените свое отношение, спросите, как вы можете это сделать, что "он просто работает" (может быть, может помочь встреча с конфигурацией, или спросить, как Apple это сделает)
• практика (например, джазовые игроки - варенье с кодом, попробуйте Code Kata)
• написать один и тот же код несколько раз, с разными языками и через некоторое время прошло
• изучать новые языки с новыми концепциями (если вы используете статический язык, изучайте динамический, если вы используете процедурный язык, изучайте функциональный,...) [один язык в год примерно соответствует]
• попросите кого-нибудь просмотреть ваш код и активно спросить, как сделать код более простым и элегантным (, а затем сделать его)
• получить годы под вашим поясом, делая вещи выше (время помогает активному разуму)

Ответ 5

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

Ответ 6

Прочитайте "Эффективно работая с устаревшим кодом" Майкла С. Перья.

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

Ответ 7

Использование Test Driven Development и после Robert C. Martin Три правила TDD:

• Вам не разрешено писать какой-либо производственный код, если только он не сделает провал unit test.
• Вам больше не разрешается писать unit test, чем достаточно для отказа; а сбои компиляции - сбои.
• Вам не разрешено писать код производственного кода, чем достаточно, чтобы передать один сбой unit test.

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

Ответ 8

Тест сначала может помочь здесь, но он не подходит для всех ситуаций. И это все равно не панацея.

Начать небольшую - еще одна отличная идея. Вам действительно нужно набить все 10 шаблонов дизайна в эту вещь? Попробуйте сначала сделать это "глупым способом". Не совсем режет? Хорошо, сделайте это "немного менее глупо". Etc.

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

Использовать скудный язык. Языки, такие как Java, или иногда С++ иногда, похоже, поощряют неприятные, запутанные решения. Простые вещи, как правило, охватывают несколько строк кода, и вам просто нужно использовать 3 внешние библиотеки и большую структуру для управления всем этим. Рассмотрите возможность использования Python, Ruby и т.д. - если не для вашего проекта, то для частного использования. Он может изменить ваше мышление в пользу простоты и быть уверенным в возможности простоты.

Ответ 9

Это неизбежно, как только вы были программистом, что это произойдет. Если вы серьезно не оценили усилия или столкнулись с проблемой, когда ваше решение просто не работает, прекратите кодирование и поговорите с вашим менеджером проектов. Мне всегда нравится принимать решения со мной на встречу, проблема в A, вы можете сделать x, который займет 3 дня или мы сможем попробовать y, который займет 6 дней. Не делайте выбор самостоятельно.

Ответ 10

• Поговорите с другими программистами на каждом шагу. Чем больше глаз присутствует на дизайне, тем скорее вероятность того, что сложный аспект обнаружен раньше, прежде чем он станет слишком окостененным в кодовой базе.
• Постоянно спрашивайте себя, как вы будете использовать то, над чем работаете в данный момент. Если ответ заключается в том, что вы не уверены, прекратите переосмысливать то, что вы делаете.
• Я нашел полезным придумать мысли о том, как потенциально упростить то, над чем я сейчас работаю. Таким образом, как только я на самом деле работаю, вам легче вернуться и рефакторировать или переделать по мере необходимости, вместо того, чтобы возиться с чем-то, что еще не работает.

Ответ 11

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

Несколько методов, которые я считаю полезными:

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

В том же ключе есть кто-то другой, от которого вы можете отбросить идеи. Убедитесь, что вы можете объяснить им, почему сложность оправдана!

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

Ответ 12

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

Это следует из Bendazo post-simplify, пока оно не станет легким.

Ответ 13

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

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

Ответ 14

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

Спросите мнение людей, которые получают свои удары от простых и простых решений.

Используйте только те концепции, которые необходимы текущему проекту (желание для будущей проверки или общих систем делает ваш дизайн раздутым).