Или это наоборот?
Сегодня я пришел к двум осознаниям, обе удивительные и обе важные. Во время безобидной дискуссии об обзоре кода я внезапно обнаружил, что только несколько базовых идей лежат в основе всех моих решений, связанных с кодированием. Один из них: простое лучше, чем сложное. И примерно через три секунды я понял, что это не общеизвестная мантра и не та, которую можно быстро объяснить. Это убеждение, в которое вы перерастаете. Но как мне объяснить это своему товарищу по команде, не дожидаясь нескольких лет?
Для меня «простота важнее сложности» - это прагматичный ответ на самые разные вопросы, простая бритва Оккама. Это дает мне два преимущества:
- Это позволяет мне разделить проблему на часть, которую мне нужно решить сейчас, и часть, которую я могу отложить.
- Это вселяет в меня уверенность в моем решении, потому что оно подкреплено множеством других теорем, принципов, правил и указаний.
Так что вообще значит «простое лучше, чем сложное»?
Это руководство хочет, чтобы вы склонялись к более простым решениям. Вы должны часто спрашивать себя: можете ли вы упростить код и при этом добиться того же результата? Могли бы вы упростить дизайн и при этом достичь той же цели?
Это могут быть такие мелочи, как: Вы злоупотребляете мощными языковыми структурами? Вы получаете пользу от использования оператора try- except, или простой оператор if лучше вписывается в ваш поток?
Или это могут быть более крупные вещи, например: действительно ли вы поддерживаете 20 различных сценариев или можете добиться сопоставимого взаимодействия с пользователем, предоставив только три наиболее распространенных?
Это руководство побуждает вас проявлять бдительность в отношении сложности и требовать веских причин для ее увеличения.
Как сложность влияет на проект
В начале проекта нет кода, нет спецификаций. Будущее (то, что нам придется создавать) пугает, но прошлое (то, что мы создали) просто. Мы пока ничего не создали, и это было очень просто; это мог сделать кто угодно 🙃.
Теперь нам нужно что-то создать. Мы не можем создать все сразу; с чего начать?
Если мы доверяем быстро развивающейся сцене стартапов, прагматичный путь - начать с MVP. MVP означает минимально жизнеспособный продукт, продукт с достаточным количеством функций, необходимых для успешного выполнения своей основной задачи. Цель на этом этапе - снизить затраты на разработку проекта до тех пор, пока у нас не будет доказательств того, что мы разрабатываем правильные функции.
Принцип MVP - это просто разные выражения для выражения «простое лучше, чем сложное». Следует использовать самое простое решение, которое решает вашу проблему. Не увеличивайте сложность (т. Е. Затраты), пока у вас не появятся веские причины для этого.
Похожая концепция присутствует в принципе Парето, который также называется правилом 80/20 или законом немногих жизненно важных. Принцип Парето гласит, что для многих событий примерно 80% последствий происходят от 20% причин, то есть 80% сообщений об ошибках вызваны 20% ошибок; В 80% случаев используются 20% функций.
Принцип Парето зародился в статистике, в экономике, но был применен к широкому кругу вопросов. Он очень хорошо поддерживает нашу концепцию Простота важнее сложности. Зачем поддерживать все мыслимые рабочие процессы для нашего программного обеспечения, если 80% наших клиентов используют только 20% возможных рабочих процессов?
Таким образом, чтобы определить, какие функции следует разработать в первую очередь, мы должны быть придирчивыми. Все, что мы строим, нам тоже придется поддерживать какое-то время. Все, что мы добавляем к нашему программному обеспечению, будет иметь стоимость обслуживания и будет влиять на то, как и по какой цене мы можем создавать другие, совершенно не связанные, новые вещи.
Что является хорошей причиной для увеличения сложности?
На бумаге все вышесказанное кажется логичным. Но это тоже очень расплывчато. Нет ничего даже похожего на реальное определение сложности или простоты, ничего, что мы могли бы использовать в качестве практического правила, чтобы судить, какая функция стоит месяца усилий, какая шесть месяцев, а какая всего день. И здесь начинается туман, и споры становятся интенсивными.
Настоящая причина, по которой разработчики и менеджеры не обращают внимания на это руководство, заключается в том, что мы не согласны со значением слова "простой".
Если я на встрече и наш крупнейший клиент убеждает меня, что они уйдут из нашей компании, если мы не доставим X до конца квартала, то мне это будет казаться «нашим- company-is-on-the-line »- безумно хороший повод для увеличения сложности.
Если, однако, я новый разработчик в проекте и вижу, что программное обеспечение все испорчено неудачно прошедшими проектами, я мог бы также быть убежден, что, если мы не будем действовать сейчас и начнем платить за наши прошлые неверные суждения, тогда этот проект будет в любом случае обречены.
Так что же нам делать?
Планируем заранее.
Эта ситуация может оказаться неразрешимой. Самый эффективный способ решить эту проблему - избегать ее. Мы не хотим оказаться в положении, когда сложность настолько возросла, что у нас возникнут трудности с поддержанием этого проекта.
Пока проект прост, в него легко добавить больше людей и, что особенно важно, легко запомнить все сценарии, которые мы рассматриваем.
Чем сложнее проект, тем больше времени требуется новым людям, чтобы помочь им осмысленно. Проект становится все более и более зависимым от его первоначальных авторов, единственных, кто еще знает, какая сложность была добавлена, где и почему. Но проект также становится все более и более глючным из-за забытых функций и потоков. И по мере того, как он становится более глючным, он также использует гибкость. Значительное количество ошибок рано или поздно превращается в функции. Пользователи не знают, какие функции были предназначены, а какие нет. Они начинают полагаться на нарушенную функциональность, и каждое изменение с этого момента является нарушенным обещанием.
Интересно, что команды иногда используют тесты, чтобы решить эту проблему. Даже если что-то было непреднамеренным, пока это подтверждается тестом, это будет нас тревожить, если мы случайно изменим логику. Но я бы сказал, что это бесполезная защита. Очень немногие тесты правильно читаются, понимаются или обслуживаются. Такие испытания все равно что отправлять на границу вечных пьяных пограничников. Мы их видим, но не воспринимаем всерьез.
Все ли исключения - зло?
С другой стороны, когда мы пишем наш код, мы хотим, чтобы он использовался реальными людьми в реальных проблемах. А теперь покажите мне одну проблему природы, у которой есть чистое, простое решение без исключений! Таких нет. Жизнь сложна, и код тоже.
Только теоретически мы можем «игнорировать сопротивление воздуха в этой формуле физики».
И все же простота лучше
И все же нам нужно знать, что такое идеал. Нам нужно знать, к чему мы стремимся, чтобы знать, когда мы отклоняемся от этого, чтобы мы могли знать, почему мы отклонились от этого.
Нет волшебного решения; нет трехступенчатого руководства. Только позже станет ясно, был ли достигнут хороший баланс между простотой и сложностью. После принятия решение часто остается неизменным или требует больших затрат.
Но если мы планируем продолжить работу над каким-то проектом хотя бы немного дольше, мы должны подумать о самих себе в будущем, которым придется смириться с этим решением.
Действительно ли эта функция хороша в долгосрочной перспективе?
