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

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

РЕДАКТИРОВАТЬ: Этот комбинатор синтаксического анализатора является примером того, что я считаю умным кодом. Я скачал это и просмотрел это в течение приблизительно получаса. Затем я шагнул по макрокоманде на бумаге и увидел свет. Теперь, когда я это понимаю, он выглядит намного элегантнее, чем комбинатор синтаксического анализа Haskell.

Простые решения лучше для длительного обслуживания. И это не всегда только из-за знания языка. Сложная линия (или линии) требует времени, чтобы понять, даже если вы являетесь экспертом в данном языке. Вы открываете файл и начинаете читать: «Хорошо, просто, просто, понял, да, WTF ?!» Ваш мозг замирает, и теперь вам нужно остановиться и расшифровать сложную линию. Если не было измеримой, конкретной причины для такой реализации, она «слишком умна».

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

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

Принцип поцелуя

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

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

Брайан Керниган

Дураки игнорируют сложность; прагматики терпят это; эксперты избегают этого; гении удаляют это. - Алан Перлис

Лучшее решение не всегда самое умное решение. Иногда простые решения одинаково хороши.

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

Процитирую Брайана Кернигана:

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

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

«Умный», когда применяется к коду, почти всегда является просто эвфемизмом для «ненужно сложного».

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

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

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

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

1. Никто не может понять это, не говоря уже о поддержке / отладке.
2. Человек, который написал, даже не знает, что делает.
3. На самом деле это может быть не так уж и блестяще
4. и т.д....

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

1. Кто-то слишком умный, чтобы использовать чужие решения. Зачем искать то, что сделали другие люди, когда вы можете изобрести собственный способ снятия шкур с той же кошки?
2. Кто-то, кто думает, что изобрел самое крутое решение проблемы, часто отказывается принимать какие-либо предложения.
3. Никому не позволим модифицировать «свой» код, даже если есть очевидные проблемы или необходимо простое изменение.
4. С другой стороны, они думают, что они умны, и им нужно использовать «новейшую» технику, чтобы доказать, насколько они умны, но им не удается получить хороший контроль над этим ни в личных проектах, ни в непроизводственном коде, прежде чем свернуть его в критические части. система.

Мы все виноваты в том, что иногда слишком много эго, но когда это мешает команде, это проблема.

Хороший Умный - высокое соотношение между умными строками кода и строками в неумной альтернативе. 20 строк кода, которые спасают вас от написания 20000 - это очень хорошо, умно. Good Clever - это спасение работы.

Bad Clever - низкое соотношение между написанными строками кода и сохраненными строками кода. Одна строка умного кода, которая избавляет вас от написания пяти строк кода, - это Bad Clever. Плохо умный о "синтаксической мастурбации".

Просто чтобы заметить: Bad Clever почти никогда не называют «Bad Clever»; он часто путешествует под псевдонимами «красивый», «элегантный», «лаконичный» или «лаконичный».

Я должен задаться вопросом об определении каждого умного.

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

Я чувствую себя умно, когда во время проверки кода мой рецензент говорит: «Ух ты, это было проще, чем я думал, что это будет», в отличие от «Уфф это все…»

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

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

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

Иногда я был настолько умен, что ошибался.

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

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

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

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

Перефразировать:

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

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

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

На мой взгляд, ум как таковой не является проблемой. Обычно мы можем путать «умный» (без сарказма) и «проницательный» код. Что я вижу в качестве проблемы, так это тот факт, что обычно «умный» (с сарказмом) код содержит неявные невидимые требования, что усложняет его отладку и сопровождение с течением времени.

Есть несколько известных алгоритмов, которые являются умными. Быстрая сортировка одна, ИМО.

«Умный» (с сарказмом) код обычно делает предположения об установленных переменных и состояниях системы, которые фактически отключены от «умного» кода (как файлы, открытые ранее, сетевых подключений, баз данных и т. Д.).

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

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

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

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

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

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

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

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

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

Я склонен быть умным , но стараюсь быть элегантным .

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

Это мое понимание проблемы, основанное на моем опыте и других ответах:

1. Код, который требует умения писать, но который читается и поддерживается, не считается вредным. Однако большинство разработчиков не назвали бы такой код «умным»; они могут использовать другой термин, как «элегантный». Могут или не могут быть некоторые дебаты о том, существует ли такой кодекс.
2. Рабочий код, который требует значительного времени и усилий для понимания даже опытным разработчиком, знакомым с языком, является «умным» и считается вредным для всех.
3. Производственный код, который требует значительных затрат времени и усилий неопытных разработчиков, считается вредным для некоторых. Я видел ответы в любом случае, и я работал с разработчиками, которые прямо сказали, что они предпочли бы оставить все "наименьшим общим знаменателем".

Я знаю парня; он, наверное, самый блестящий человек, которого я когда-либо встречал. Он определенно невероятный кодер, возможно, лучше, чем я когда-либо буду за всю свою жизнь, с точки зрения простого программирования. Он пишет код, как будто он набирает текстовый документ, и может перевернуть связанный список, как вы не поверите. Если вы хотите поговорить о написании какого-то серьезно сложного кода, он ваш человек, и если я сталкиваюсь с невероятно сложной проблемой, я всегда обращаюсь к нему. Тем не менее, работа над проектом с ним в условиях команды является мучительной. Он не может напрямую нацелить бизнес-проблему и предложить логичное, эффективное и краткое решение. Для него листинг кода в 1000 строк был бы лучше, чем 100. Вместо того чтобы использовать инструменты, предоставленные ему через IDE или среду, он выпустит свой собственный супер-оптимизированный инструмент.

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

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

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

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

Я помню, что однажды я использовал 1 список вместо 3 и создал одну большую функцию, которую было очень сложно поддерживать / изменять.

в современном мире мы не должны жертвовать ясностью кода для производительности (кроме c ++, они не должны, но они будут).

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

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

Повторное цитирование для контекста и облегчения понимания:

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

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

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

Свертка:

A thing that is complex and difficult to follow.

Умная:

Showing intelligence or skill; ingenious

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

Из-за популярности этой цитаты и того, что Брайан Керниган является довольно популярным в отрасли, это неправильное употребление этого слова оказывает негативное социальное воздействие, и я искренне хотел бы видеть, что этот вопрос адресован самим человеком. Перед тем, как написать эту статью, я попытался выяснить, могу ли я просто отправить ему электронное письмо, но я не смог найти контактную информацию по электронной почте, которую я понял :(.

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

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

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

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

• Доклад Гвидо Ван Россума о циклах событий и о том, как он их понял
• Сотрудник GitHub, который заявил, что избегает нанимать умных людей на Y-Combinator
• Многое из обсуждения и изучения, которое происходит в сообществе Python. Сообщество Python особенно критично относится к новым идеям, но не отвергает новые идеи, которые они не понимают из-под контроля, и вы, как правило, можете видеть функции, которые на первый взгляд выглядели сложными, в свете дня как базовая языковая функция / пакет.
• Мой собственный опыт и профессиональное мнение основаны на моих 10000-футовых наблюдениях. Хотя я не могу понять специфику просветления от всего этого :( Надеюсь, ваш опыт и наблюдения скажут вам то же самое, и кто-то еще может прокомментировать ниже, чтобы дать этому ответу некоторую ценность.

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

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

Это не ум. Это знание.

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

Умный разработчик - это хорошо.

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

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