Как тренировать себя, чтобы не писать «умный» код? [закрыто]

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

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

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

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

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

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

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

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

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

Иногда рецензирование - это лучший способ получить представление о своей работе.

Лучше всего помнить изречение Брайана Кернигана:

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

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

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

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

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

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

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

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

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

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

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

Моя точка зрения заключается в том, что «умный» код ДОЛЖЕН быть подозрительным, но мы не должны идти против него, потому что он может задушить творчество и инновации.

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

Если 20% (ваш% может отличаться) или больше ваших добавленных строк должны быть документацией - пришло время отступить и переосмыслить .

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

Я не могу устоять перед попыткой чего-то умного.

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

Когда новинка изнашивается - проблема решена.

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

Если бы я дал распечатку этого кода кому-то, кто никогда не работал над этим проектом / кодом, смогут ли они прочитать его и описать мне, что делает функция (после краткого контекста)? Если нет, то сколько объяснений мне придется сделать? Как бы я объяснил это кому-то, принимающему CS101?

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

1) Обожгитесь этим раньше, чтобы вы знали, что это плохо. Попытка отладить что-то давно написанное умно - это очень весело. Я думаю, что вы это покрыли.
2) Прокомментируйте свой код, объясните, что вы делаете перед каждым разделом кода.
3) Если вам трудно объяснить это или вы чувствуете необходимость вставить диаграмму, то то, что вы только что сделали, слишком умно и, вероятно, может быть сделано более чисто.

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

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

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

Существуют фреймворки для внедрения зависимостей с открытым исходным кодом, для работы с которыми нужно просто получить Expressionзнания об уловках, есть F # и замечательный набор задач, которые можно попробовать.

Если вы увлекаетесь математикой (и это не зависит от языка ), для вас найдется Project Euler .

Наконец, что не менее важно, в мире .NET существует Mono Project, в котором есть много областей, требующих внимания разработчиков , некоторые из которых довольно сложны. Как насчет участия в работе статического анализатора кода .NET с открытым исходным кодом ? Там есть некоторый анализ IL, а также материал высокого уровня. Jb Evain всегда работает над чем-то интересным, будь то библиотека отражений Cecil, Expressionподдержка или декомпилятор .NET.

Если ничего не подходит, просто запустите свой собственный фальшивый фреймворк :-)

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

нет

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

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

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

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

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

Кроме того, комментарии могут выступать в роли sidenotes в книге, когда нам нужно объяснить процесс обоснования претензии в основном тексте, не нарушая ее.

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

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

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

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

Редактировать в свете -1:

Много лун назад я был в той же ситуации - у меня был один босс, который каждый раз сжимался, когда я использовал указатель в Delphi или «с конструкцией», другой, который угрожал уволить меня, если я не перестану замыкать все мои логические выражения с 0-1 и использование однобуквенных переменных везде.

Я узнал, потому что я спросил, почему, и они попытались объяснить, потому что они думали, что я могу что-то значить - LOL ....

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

Также осознайте, что, сосредоточившись на функциональном программном обеспечении, которое своевременно и легко поддерживается, вы получите признание, которое ищете. Опытные разработчики придут к вам и скажут: «Человек, который вы написали, модуль был хорошо спроектирован. Мне нужно было реализовать только один компонент, чтобы подключить его к моему проекту». в отличие от «Мне пришлось переделывать весь этот модуль, который вы написали, просто чтобы использовать его в другом компоненте? Вы когда-нибудь слышали о Бобе Мартине или Уорде Каннингеме?»

ТЛДР: Вы не одиноки. Признание навыка лучше всего достигается как побочный продукт умного решения проблем.

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

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

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

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

В дополнение к хорошим советам, данным до сих пор (обзор кода, отладка, подход TDD), вы должны (пере) время от времени читать (лучшие книги imho) о хороших методах кодирования:

• Прагматичный программист
• Код завершен
• Чистый код

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

Просто помни ЯГНИ - Тебе это не нужно .

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

YAGNI - принцип, лежащий в основе практики XP: «делай самое простое, что могло бы сработать» (DTSTTCPW). Он предназначен для использования в сочетании с рядом других практик, таких как непрерывный рефакторинг, непрерывное автоматизированное модульное тестирование и непрерывная интеграция. Использование без постоянного рефакторинга может привести к грязному коду и массивной переработке ...

По мнению тех, кто защищает подход YAGNI, соблазн писать код, который не нужен в данный момент, но может возникнуть в будущем, имеет следующие недостатки:

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