Насколько сложным должен быть код?

Question

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

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

Answer 1

Я думаю, что важно отделить сложность домена от базовой технической сложности.

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

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

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

Так что, если ваши 150 строк if / else вещи "совпадают" с тем, как проблема выражена гораздо лучше, чем 20 умных строк, это гораздо более обслуживаемый и расходуемый фрагмент кода. Если вы берете долгосрочную перспективу, писать исполняемый код легко, он остается таким, что является настоящей проблемой ...

Paul.

Answer 2

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

Answer 3

Он должен быть настолько сложным, насколько это необходимо. То, чего не может быть, сложно, большая разница.

Answer 4

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

Answer 5

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

Answer 6

Зависит. Мне бы не хотелось поддерживать 150 строк операторов if-then-else, составляющих функцию, особенно если дерево решений плотное. 20 строк сложной математики могут быть или не быть лучше. Может потребоваться время, чтобы понять, но более длительное решение может потребовать еще больше времени для проверки.

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

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

Answer 7

Комплекс не обязательно означает больше или меньше строк кода для меня.

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

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

Если вы сделаете его слишком простым (и на 50–70% больше кода), у него могут возникнуть проблемы с производительностью.

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

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

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

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

Answer 8

Сложные алгоритмы хороши, только если действительно необходимо увеличение скорости или пространства. Не беспокойтесь о написании причудливого факториального алгоритма, который выполняется в O (1), потому что факториал около 25 практически никогда не будет использоваться. Однако, если код находится в самом внутреннем цикле и ускорение на 25% в этом коде улучшит все приложение на 20%, тогда сделайте это.