Я изучаю алгоритмы, которые могут помочь мне написать меньший, но более сложный код. Вместо того, чтобы писать 150 строк инструкций if-else, я могу разработать алгоритм, который делает это в 20 строках. Проблема в том, что многие из этих алгоритмов могут быть сложными и требуют много математики для их понимания. Я тоже один, кто их понимает.
Для удобства использования кода было бы лучше просто написать код, как это делают все остальные, или лучше использовать алгоритмы?
Как сказал Эйнштейн:
Сделайте все как можно проще, но не проще.
Он применяется как к коду, так и к физике.
Используйте свое мнение - будет ли его легче поддерживать? Часто, уменьшая большие беспорядки if/else во что-то меньшее, вы удаляете угловые случаи, которые не должны быть там, предотвращая ошибки, которые могут появиться в будущем. Разумеется, уменьшая четкий набор условий в неясное завихрение логической логики, которое только срабатывает, вы можете сделать вещи намного сложнее для поддержания, когда что-то изменится.
EDIT:
В случае, которое вы указали, если формула будет работать, то это, вероятно, лучший вариант - вы даже можете оставить комментарий со ссылкой на источник. Однако вполне возможно, что формула была там раньше, но была отброшена, чтобы разрешить конкретный случай. Это то, что комментарии в вашем репозитории версий должны помочь.
Поскольку никто еще не добавил ссылку, здесь описание алгоритма PID, на который он ссылается.
Код записывается один раз и читается 10 раз. Поэтому вы должны попытаться сделать это максимально понятным.
Кроме того, отладка гораздо сложнее, чем написание кода. Итак, как вы можете отлаживать свой код, когда вы уже вложили весь свой мозг в сложный код?
Просто попробуйте следовать Три закона развития программного обеспечения:
Роберт К. Мартин использует этот комикс как введение в свою книгу "Чистый код":
Помните, что код должен в первую очередь понимать люди... компиляторы заботятся о том, чтобы понять компьютер.
Уровень "сложного" здесь может быть немного рискованным, но до тех пор, пока алгоритм не требует решения кандидатской диссертации по математике,
Я бы сказал, продолжайте использовать алгоритмы. Не забудьте разместить достойный уровень документации о названии алгоритма и, возможно, краткое описание того, как он работает, или ссылку на документ об этом.
Он сохранит объем кода, надеюсь, даст немного дополнительной производительности для приложения, и он, мы надеемся, побудит нескольких программистов вокруг вас изучить некоторые новые вещи, чтобы добавить их в свой репертуар. Плюс всегда есть шанс, что программист, который действительно знает эти вещи, не придет позже.
Хорошая старая цитата....
Любой дурак может написать код, который компьютер может понять. Хорошо программисты пишут код, который люди могут понимать
Я не могу поверить, что кто-то думает, что 150 строк ничего проще, чем 20 строк.
Пойдите с 20 линиями и защитите своих коллег следующим образом:
Документируйте каждый инвариант структуры данных и любой нетривиальный инвариант цикла. Документируйте это не в комментариях, а в фактическом коде, который проверяет инварианты. Проверка может быть отключена во время производства.
Если вы используете математические формулы в своем коде или извлекаете код, включать ссылки в комментарии (или статические строки). В идеале должны быть две ссылки: веб-ссылка, которая может быть доступна в считанные секунды, и хорошо расцененный учебник, который долгое время остается в печати и может быть найден в университетских библиотеках.
Если понимание вашего кода требует специальной экспертизы (понимание дифференциальных уравнений с частными производными, степень в области физики, теория Галуа, вы называете это), то, чтобы защитить себя, вы можете обратиться к своему руководству и сказать: "У меня есть эта специальная экспертиза что позволяет мне писать код, который меньше (и, следовательно, быстрее, надежнее и проще в обслуживании), но когда вы должны меня заменить, вам придется нанять кого-то с подобным опытом. делать?" Будет полезно, если вы сможете сообщить своему руководству, как легко получить такой опыт. Например, многие люди с инженерными степенями могут изучать дифференциальные уравнения с частными производными, но теоретики Галуа довольно тонкие на местах.
P.S. Вот пример комментария от хобби проекта, чтобы я мог отлаживать свой собственный код позже:
/*
* Compute the position of a point partially along the geodesic from
* pt1.lat,pt1.lon to pt2.lat,pt2.lon
*
* Ref: http://mathworld.wolfram.com/RotationFormula.html
*/
Так сложно, как и должно быть, и не более.
Это действительно зависит от того, что означает комплекс. Если ваш "простой" алгоритм - это 150 строк почти того же кода, мои глаза будут глазуроваться, и я не смогу его понять. Если вы помещаете эти условия в матрицу или что-то еще, а ваш код - это цикл для чтения матрицы и принятия решений, я пойму это лучше, хотя цикл может быть менее "простым", а затем связкой операторов if/else.
Если в основном вы говорите о программе Perl, в которой вы делаете все в одной строке, используя огромное значение переменной по умолчанию $_, я бы сказал, что вы используете более длинную более подробную версию.
Если есть принятая формула для чего-то, вы можете использовать принятую формулу. Если существует простая алгебраическая формула, которая принимает 3 или 4 строки и существует комплексное дифференциальное уравнение, которое берет одну строку, вы должны использовать простую алгебраическую формулу. В случае, упомянутом в комментариях, я думаю, что PID-алгоритм "проще", чем 150 строк кода if/else. Я не думаю, что вы используете алгоритм, чтобы что-то скрывать, но вы используете стандартные методы в области проблемы. Просто не забудьте прокомментировать это и, возможно, даже включите ссылку на веб-страницу, описывающую формулу.
Нахождение пути через 100 строк операторов if/else часто (на мой взгляд) сложнее настойчивости сопровождающего, чем тратить то же время на понимание лучшего алгоритма (который должен быть объяснен или связан с комментариями), и, наконец, просто проверяя, что 20 строк реализации действительно выполняют этот. Он также имеет преимущество образования на работе, что делает его гораздо более интересным (в положительном смысле), а часто и лучшим профилем выполнения (за вычетом использования ресурсов).
Умение, которого вы должны избегать, заключается в "умных хаках", которые злоупотребляют языком без реальной выгоды. Умение, которое вы должны принять, всегда использует лучший алгоритм для работы.
edit: Что касается примера PID: мне очень сложно представить, что функциональность PID может быть заменена кучей инструкций if-else. Решение if-else всегда будет работать хуже (менее плавные переходы), будет очень сложно поддерживать и очень сложно настроить (настройка частей PID очень важна для достижения желаемого поведения). Я хотел бы добавить, что понимание PID не слишком сложно, даже если вы не знаете математику, которую можно легко найти.
Упрощение обычно лучше. Помните, что другим людям, вероятно, придется поддерживать их когда-нибудь.
Напишите код таким образом, который проще всего поддерживать и понимать для среднего программиста, который работает над вашим кодом.
Интересно, что одним из наиболее распространенных мер сложности кода является глубина гнездования. Ваше решение "If-then-else" может быть классифицировано как более сложное с помощью автоматизированного анализатора кода, чем ваш шаблонный.
Однако, я видел достаточно "WTF"? что вы описываете, что я обычно буду использовать для подхода if-then-else. Но рассмотрите это; можно использовать более сложный, формульный подход, но разделить особенно сложные компоненты на хорошо известные методы? Если вы можете это сделать (возможно, даже рефакторинг для устранения избыточности), вы сможете избежать худших аспектов вашего алгоритма, избегая при этом многоуровневой структуры if-then-else.
Zen of Python неплохо справляется с этой проблемой:
...
Простой лучше, чем сложный.
Комплекс лучше, чем сложный.
...
Если реализация трудно объяснить, это плохая идея
...
Другими словами (и, как говорили другие), самый простой алгоритм, который выполнит работу под наложенными ограничениями (время, память и т.д.), является лучшим. Очевидно, что более простой алгоритм, который не выполняет свою работу, недостаточно хорош. Если ваш код короче, потому что он использует сложные идеи, он сложный. Если никто другой не может понять ваш код, это сложно, и если вам сложно объяснить это им (даже если они поймут его с учётом кандидата наук по математике), это плохая идея.. p >
...
Особые случаи не являются достаточно сложными, чтобы нарушать правила.
Хотя практичность превосходит чистоту.
...
Часто часто возникает специальный код случая, который заходит в первоначально "чистый" код за всю свою жизнь. Вы должны бороться с этой сложностью здания, но примите его, когда это необходимо.
Необработанная сложность всегда плохая. Да, может быть интересно написать блестящий один лайнер, который выполняет работу функции 200 строк. Но помните, что вы должны поддерживать код. И короткий комплексный код - ад для поддержки.
Другой риск сделать код проще, так это то, что вы попадете в кучу средних кодеров. Строка, которую вы ищете, является читаемым/нечитаемым кодом. Если вы можете вернуться через неделю и все еще легко прочитать код, я бы сказал, что он достаточно прост.
Я видел очень оптимизированный код, выполняемый очень медленно, и неоптимизированный код запускается быстро, и это потому, что компиляторы знают, как компьютер хочет работать, а авторы компиляторов сосредоточены на простом оптимизации кода.
Возможно, ваш 150-строчный алгоритм компилируется во что-то намного быстрее во время выполнения, чем ваша 20-строчная версия. Ваш 20-строчный алгоритм может оказаться медленнее, потому что компилятор не знает, как его оптимизировать.
Я также предположил бы, что вы захотите поместить версию if-else в блок комментариев над версией алгоритма с 20 строками (или наоборот), чтобы сопровождающие могли понять, что пытается сделать ваша сложная версия. Наличие их обоих в коде упрощает тестирование производительности обоих (и как только вы набрали их обоих, нет причин для удаления другого). Это также позволит легко перейти на другие языки/платформы/компиляторы в будущем. Вы можете не ожидать этого, но если код работает, он, вероятно, будет жить в течение десятилетий и увидеть множество разных компиляторов и платформ.
Попробуйте и попробуйте "более сложную" версию, прочитанную другими, через несколько недель после того, как вы ее написали. Оцените сложность того, насколько сложно вам читать и объяснять это другим, и их реакцию на код.
Риск его усложнения состоит в том, что никто его не поймет. В этом случае четко прокомментируйте это и укажите некоторые источники, которые помогут кому-то узнать и понять его.
Риск упрощения заключается в том, что кто-то не захочет это понимать, потому что он длинный.
Я думаю, что вопрос: лучше ли сложный код? Это быстрее, надежнее? Цель состоит в том, чтобы написать лучшие программы, если сложный код является лучшим решением, тогда вам просто нужно писать лучшие комментарии, чтобы ваш преемник мог управлять кодом в будущем. В принципе, код должен быть как можно более простым в любой ситуации.
Если вы можете сделать это на 20 строках, а затем правильно прокомментировать эти строки, я бы сказал, пойдите для этого. Вы не только упрощаете поддержку, имея меньше кода для поддержки, но также помогаете сделать своих коллег-программистов умнее.
Предварительная оптимизация и умные взломы - это одно, а умные алгоритмы - это и всегда была честной игрой.
Но сохраните эти алгоритмы в своих собственных функциях и не забудьте объяснить входные и выходные переменные!
Обязательная цитата:
"Сложность управления - это суть компьютерного программирования" (Брайан Kernigan)
Я думаю, что важно отделить сложность домена от базовой технической сложности.
Некоторые специфичные для домена функции, для которых вы хотели бы использовать компьютер, по своей сути сложны, а некоторые нет. Например, проблемы бухгалтерского учета полны странных правил, но большинство вычислений довольно просты. Оценка финансовых ценных бумаг, с другой стороны, в зависимости от типа, может включать в себя чрезвычайно сложные математические формулы и много-много симуляций. Большинство компьютерных систем действительно просто собирают большие объемы данных, но многие из них имеют несколько лежащих в основе сложных алгоритмов.
Технология, с другой стороны, часто накладывает свою собственную сложность. Написание большой программы на С++ для ПК может быть проблемой. Написание веб-приложения для Интернета может быть намного хуже. Попытка обеспечить отказоустойчивость, производительность или безопасность часто вызывает большую сложность. Каждая другая технология помогает или препятствует системе.
То, что мы действительно хотим сделать, выражает код в нем простейшую возможную форму, которая ближе всего к ее присущей домену или технической спецификации. Если вы пишете операционную систему, то C - это более простой язык для использования. Если вы разрабатываете комплексные вероятности риска для страхования, то более подходящим является матрично-ориентированный язык, такой как APL. Если вы просто создаете массивные отчеты, лучше всего выбрать что-то с простым синтаксисом, ориентированным на отчетность.
Итак, если ваши 150 строк if/else "совпадают" с тем, как проблема выражается намного лучше, чем 20 умных строк, это гораздо более удобный и одноразовый бит кода. Если вы возьмете долгосрочную перспективу, писать код можно легко, так как это делает реальную проблему...
Павел.
Он должен быть настолько сложным, насколько это необходимо. То, что это не может быть сложным, большая разница.
Ну, код может быть довольно трудно понять и поддерживать только из-за огромного объема, если он становится достаточно большим (см. большинство Java-кода). Если все остальное (производительность и т.д.) Равно, и разница в длине между простым и сложным алгоритмом действительно радикальна, я всегда буду идти сложным, но кратким и элегантным алгоритмом над простым, но подробным. Предполагая, что оба алгоритма оказались правильными, тот, у кого меньше операторов if и меньше общего кода, с меньшей вероятностью будет иметь тонкие ошибки в реализации и, следовательно, менее вероятно, когда-либо потребует обслуживания. Если бы я был сопровождающим, я бы скорее потратил свое время на изучение нового алгоритма, чем на то, как кто-то реализовал какой-то смехотворно длинный, но скучный алгоритм.
Зависит. Я бы не хотел поддерживать 150 строк операторов if-then-else, составляющих функцию, особенно если дерево решений плотно. 20 строк сложной математики могут быть или не быть лучше. Это может занять время, чтобы понять, но более длительное решение может потребовать еще больше времени для проверки.
В идеале вы найдете способ сделать это в меньших и более простых строках, но не все функции работают таким образом.
Если вы используете 20 строк, используйте некоторые из 130 строк, сохраненных в комментариях, чтобы объяснить, какой алгоритм вы используете. Если вы не можете это объяснить, перейдите к 150-строчному решению.
Комплекс не обязательно означает более или менее строки кода для меня.
Идеальная система никогда не строится в первый раз. Все, что вы можете сделать, это не делать слишком много сложных решений, которые связывают вас с тем, что вы делаете в одном направлении.
По этой причине мне нравится сохранять сложность низкой во время начальных версий любого проекта. Причина, по которой вы построили что-то (новая гибкость), сильно затронута. Если вы сделаете это как можно более сложным, люди поймут это вначале. Это может быть хорошим или плохим.
Если вы сделаете это слишком простым (и на 50-70% больше кода), это может привести к проблемам с производительностью.
По мере того, как система стареет и созревает, сложность, похоже, происходит за счет повторного факторинга. К тому времени вы можете достичь точки, когда какой-либо код никогда не будет затронут снова, и если вы когда-нибудь это сделаете, затраты на понимание сложности будут ниже из-за более низкой частоты касания.
Мне нравится решать сложные задачи с помощью простых шагов. Там, где это невозможно, сложность увеличивается соответственно. В другом вопросе был вопрос о знании, когда он "достаточно хорош". Иногда немного больше кода (5-20%) может значительно компенсировать сложность, что может быть более дорогостоящим для повторного изучения или понимания кем-то.
Необходимость лучшего алгоритма, как правило, является хорошей проблемой, потому что это означает, что ваш материал используется, а новые требования должны быть рассмотрены.
Это та же самая сложность, которая применима к абстракции базы данных для меня, вы должны знать, когда сделать ее более гибкой, и когда ее простоту и ее наилучшие знания можно было бы собрать, построив ее, вы пишете одну строку.
Сложные алгоритмы хороши только в том случае, если скорость или ускорение пространства действительно необходимы. Не утруждайте себя написанием фантастического факториального алгоритма, который работает в O (1), потому что факториал около 25 в принципе никогда не будет использоваться. Однако, если код находится в самом внутреннем цикле, и ускорение на 25% в этом коде улучшит все приложение на 20%, а затем перейдите к нему.
Я признаю знание и симпатию математики и алгоритмов, но для меня 150-строчный if/else беспорядок является более сложным и трудным для поддержания, чем все, что может быть четко выражено в 20 строках. Документируйте код правильно и помещайте ссылки на документы, книги или Википедию.