Часто кажется, что на стековом потоке люди (особенно программисты) имеют тенденцию чрезмерно усложнять решение проблемы, где решение намного сложнее, чем исходная проблема? Я ни в коем случае не эксперт, но часто я пытаюсь использовать самое простое решение, которое работает (и, очевидно, это не работает ВЕЗДЕ), но у меня был довольно хороший успех, предлагая простые решения на работе, которые кажутся людям упускать НАМНОГО более сложные решения?

Это как нормальная вещь для программистов ..... или я просто не думаю в правильной перспективе.

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

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

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

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

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

Я видел много кода, который был более сложным, чем нужно, и почти всегда по этим трем причинам:

1) Чрезмерно спроектированный из-за преждевременного обобщения или попытки предвидеть будущие потребности, которые никогда не возникали

2) Разработчики хотели изучить / поэкспериментировать с новым шаблоном дизайна или технологией, которые они не использовали ранее, и включили их в действие, даже если это было излишним. Они делают это, потому что это делает их работу более интересной, и они узнают что-то новое.

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

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

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

Я не думаю, что это нормально для всех программистов, но я определенно видел, как многие программисты делают это.

Я думаю, что некоторые люди считают, что некоторые люди видят, как сделать что-то очень простое «слишком легко», и что это не является хорошей демонстрацией их навыков. Поэтому им приходится принимать большое, сложное решение, в котором есть способ сказать: «Посмотри, что я могу сделать!», Хотя это может быть не лучшим решением для рассматриваемой проблемы.

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

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

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

Другими словами, во многих случаях простое - в глазах смотрящего.

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

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

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

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

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

Отсутствие ясности будет препятствовать способности людей удалить все лишнее.

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

Лично я никогда не пытался сделать программное обеспечение более сложным. Тем не менее, я кое-что закончил и подумал: «Вау, это слишком сложно!», Вернулся к этому и провел рефакторинг. Некоторые люди могут видеть это и просто думать, что это работает, и это достаточно хорошо, а не рефакторинг.

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

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

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

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

Может быть, проблема классической ошибки?

30. Застройщик позолота.

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

• Стив Макконнелл, Rapid Development.

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

ДА ... и я заплатил цену слишком много раз.

Моя доска теперь имеет звездочку в самом верху, которая гласит:

«Если это не просто, это не правильно»

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

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