О «достаточно хорошем» ПО

    Сегодня на ежедневном Stand-up'е я произнёс перед командой очень проникновенную речь о том, что мы пишем софт для людей и никого не интересует, насколько красиво код будет выглядеть изнутри, если пользователю будет неудобно с ним работать.

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

    И, конечно же, я сразу же вспомнил концепцию о достаточно хорошем (good enough) ПО. Итак, вот её основной постулат: мы не стремимся сделать идеально, мы не пишем как попало, мы делаем достаточно хороший продукт.

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

    Качество


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

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

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

    Архитектура и код


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

    Мы теряем день за днём, оттачивая своё лётное мастерство, но лететь никуда так и не собираемся. Мы не можем остановиться и сказать: «Всё! Теперь — можно лететь», потому что всегда находится ещё пара-тройка не до конца освоенных лётных приёмов: бочка, петля Нестерова и другие (столь же не нужные в гражданской авиации) трюки.

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

    Функциональность


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

    Тут я, конечно же, не говорю о продуктах, основной изюм которых – позволить пользователю «сделать всё». Такие тоже бывают. Например, один наших продуктов (не буду конкретизировать, чтобы меня не объявили в рекламе ;) основан именно на этом преимуществе.

    Посмотрите на Twitter. Его функциональность минимальна. Она достаточна для того, чтобы пользователи могли отправлять свои сообщения и читать чужие. Ни возможности добавлять в сообщения картинки («а как вообще можно без них», подумают многие), ни полноценной социальности (только Follow и reply), ничего лишнего.

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

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

    Несколько строк в завершение


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

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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 107

      +14
      Можно уложить в четыре слова — «не болейте синдромом рефакторинга».
        +4
        Так же добавить — «преждевременная оптимизация зло»
        • UFO just landed and posted this here
            +3
            Вы перепутали разработчика с администратором. Да и у разработчиков есть системы контроля ревизий и тесты.
            • UFO just landed and posted this here
          +1
          вообще-то в о одно слово: worse-is-better
            0
            У Вас одно слово почему-то из трех состоит )
              0
              Потому что отлито в граните, и пишется через дефис :-)
          0
          Если вы можете доказать пользователям что им не нужна данная функция — я вам завидую =)
            +5
            простое правило — «багфиксы — бесплатно, фичи — за $».
              0
              Это в большей степени характерно для заказной разработки. Я в статье говорю всё-таки про продуктовую.
                0
                Да и в этом случае сильно зависит от заказчика. Если заказчик хочет чтоб была одна кнопка «сделать красиво» то без багов не получится как не старайся, а если заказчик опытный админ/художник/итд (зависит от софта) то ему наоборот надо «автоматики» поменьше, а побольше «свободы действий». Например если заказывается сайт за которым будет будет следить опытный человек, то никакие wysiwyg-и ему не нужны, наоборот даже, чем меньше «наворотов» тем больше ему понравится.
              0
              хм… Я просто говорю им, что её не будет. Это нормально. Тут нет криминала.
                0
                Главное при этом — не потерять клиента.
              +1
              Можно подумать, программисты из одного только стремления к красоте шлифуют код.

              Можно представить себе, например, склад. Бизнес-задача кладовщиков — быстро и без потерь выдавать затребованное. Чтобы успешно выполнять эту задачу, они иногда переставляют контейнеры и стеллажи, проводят инвентаризации и т.д.
                +2
                И это правильно, черт возьми!

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

                  Приведу еще аналогию с шофером гендира. Его бизнес-задача очевидна. Но он не должен забывать о бензине и вообще о ТО, иначе он подведет гендира в самый ответственный момент.
                    +1
                    Опять же, этот шофер не должен это делать постоянно! Он должен делать во время простоев и по мере необходимости! Иначе возникнет такая ситуация:
                    — поехали к заказчику.
                    — не могу, я масло меняю!
                0
                Конечно не только из одного стремления к красоте. Разумный рефакторинг — это жизненно важный шаг в процессе разработки.

                Я говорю именно о «неразумном» шлифовании. Когда код пишется ради кода, а архитектура создаётся ради архитектуры. К сожалению, это встречается сплошь и рядом среди программистов. Особенно — среди хороших программистов с горящими глазами, которые увлечены своим делом.
                  0
                  Давненько я с такими не встречался, увы:(
                    +6
                    У нас на фирме таких двое (включая меня :-)

                    Я молодым программерам рассказываю такую байку о смене тенденций в программировании:

                    — в 80-е годы главное требование к программам было в малом размере кода

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

                    — в 90-е годы главное требование к программам было в высокой скорости работы кода

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

                    — в нашем веке главное требование к программам стало в высокой гибкости кода

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

                    Так что переписывание старого кода — не блажь, а необходимость. А «преждевременная оптимизация» — это нормально, если в более спокойные периоды программист тратит время на то, чтобы сэкономить его потом, когда будет срочная работа.
                      0
                      Совершенно согласен.
                        0
                        Согласен.

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

                        P.S. Это касается средних и крупных рефакторингов. Микро-рефакторинги должны выполняться во время разработки по мере необходимости.
                    +2
                    Должно быть чёткое определение, что такое «достаточно хороший код». Иными словами, «definition of done».
                    Например, код считается хорошим, когда он
                    * проходит все юнит-тесты (написанные исходя из ТЗ)
                    * не содержит хаков
                    * не нарушает общую архитектуру
                    * удовлетворяет общим требованиям к производительности

                    Имея подобное чёткое определение, известное каждому члену команды, работать становится намного проще.
                      +4
                      Это точно. Проблема, как всегда, в деталях:
                      * что такое «хак»?
                      * как определяется «общая архитектура»?

                      Ну и этих факторов, конечно же не достаточно. Но, в общем, критерии «достаточно хорошего кода» сильно бы помогли. Впрочем, выработать их — очень непростая задача и зависит от конкретного продукта / проекта.
                        0
                        Если после 2х недель работы новичок понимает как работает система и может делать изменения в любой ее части, то система замечательна.
                          +2
                          Я бы сказал, что в этом случае, вероятно, хорош код системы. Сама система, к сожалению, при этом может нещадно глючить и пугать пользователей отвратительным юзабилити.
                            0
                            Ну при прочих равных.
                              0
                              Не только сам код, но и его структура, позволю заметить.
                              Это как разница между стратегией и тактикой.
                            0
                            Разумеется, «проблема в деталях» и «зависит от конкретного продукта / проекта». Именно поэтому в моём предыдущем посте маячат слова «например» и "подобное определение" :)

                            Я описал лишь общий подход, а уж каждая конкретная реализация — на усмотрение ведущего проекта.
                            +1
                            По порядку важности:
                            1) Обеспечивает прохождение всех тестов
                            2) Не содержит дублирующего кода
                            3) Выражает намерения программиста
                            4) Использует минимальное количество классов и методов

                            Кент Бек.
                              –1
                              Вот это ближе к жизни.
                              Код считается хорошим, когда:
                              * Просто работает. Хотя бы иногда.
                              * Количество хаков меньше половины всего кода.
                              * Есть хоть какая-то архитектура. Ну хотя бы общая задумка.
                              * Если тормозит, то всегда можно что-то выкинуть, или повесить красивый прогресс-бар.
                                0
                                У кого как. У нас, к примеру, принят подход, очень близкий к тому, что я описал.
                                  0
                                  * Просто работает. Хотя бы иногда.
                                  * Количество хаков меньше половины всего кода.


                                  Такие критерии подходят для горе-программистов, но не для профессионалов.
                                    0
                                    Вы счастливый человек, если всю жизнь работали исключительно с профессионалами.
                                +4
                                Вспомнилась интересная статья про программистов «бортовой группы шаттла»:
                                Что действительно поражает, так это то, как хорошо это ПО работает. Это ПО никогда не падает. Оно никогда не требует перезагрузки. Оно не содержит ошибок. Оно совершенно, настолько совершенно, насколько человек смог этого достичь. Посмотрите на статистику: последние три версии этой программы – каждая по 420.000 строк кода – имели всего по одной ошибке в каждой. Последние 11 версии этого ПО имели в сумме 17 ошибок. Коммерческие программы, подобного уровня сложности имели бы 5.000 ошибок."
                                  0
                                  И опять же, помимо профессионализма тех ребят, в их работу вкладываются огромные деньги.
                                    0
                                    я бы сказал что в их работу вкладываются Жизни людей. Если в ПО складского учета цена ошибки это 10 минут (час, день) потерянного времени и может быть какая-то сумма денег, то там цена ошибки это чьято жизнь.
                                      0
                                      Это как минимум, а жизнь может быть не одна, плюс оборудование на много миллионов, а то и миллиардов. Я, на самом деле, тоже поражаюсь таким людям :)
                                      +1
                                      И там не такие жёсткие ограничения по времени.
                                      То есть, случаев когда за неделю до сдачи, какие нибудь маркетологи, попросили бы добавить «розовую кнопочку с цветочками» я себе представить не могу, там я думаю ТЗ сначала составляется, потом уточняется, а уже потом всё пишется. (А не как в коммерческом софте, каждую минуту приходят изменения «сверху»)
                                      0
                                      И тем не менее один раз получилось, что они cannot into метрическая система.
                                        0
                                        интересная статья про программистов «бортовой группы шаттла»
                                        За последние дни я более глубоко осознал суть работы этих парней (про них я знал давно), прочитав «2001: Космическая одиссея» Артура Кларка.
                                          0
                                          Разработка ПО для шаттлов — как раз хороший пример ПО, для которого понятие «достаточно хорошее» фактически сливается с понятием «идеальное». Как я уже говорил в тексте, при этом применяются совершенно другие подходы и методики (о чём, собственно, в приведённой статье и написано).
                                        • UFO just landed and posted this here
                                            +1
                                            Проблема в том, что зачастую решения первоначальной задачи (решение которой заняло, скажем, месяц) становится недостаточно и требуются новые фичи. Предлагаешь клиенту «за неделю я сделаю костыли, за две перепишу всё по новой с учётом новых задач» — выбирают «за неделю». Новая задача — «за две — костыли, за три по новой». Следующая «за четыре костыли, за пять -по новой»… И т. д. пока сам не понимаешь. что очередной костыль делать дольше, чем переписать по новой. При условии, что клиент не ушёл на стадии «но ведь это лишь одна лишняя строчка на экране, вы сделали их 100 500 за месяц, как ещё одна может требовать неделю».
                                            • UFO just landed and posted this here
                                                0
                                                Рефакторинг — это как раз способ не переписывать по новой. За две недели вы возможно и напишите 30 000 строк кода, но наверника не учтете все case-ы.
                                                Рефакторинг, как часть рабочего процесса и нужен, что бы не попадать в подобные ситуации.
                                                  0
                                                  Рефакторингом называют сейчас всё что угодно — от переименования переменной цикла до изменения архитектуры. Вы про какой? :)
                                                    0
                                                    Я о том, что заставляет вас делать костыли. Сомневаюсь что это имена переменных.

                                                    Если у вас появляется необходимость еще и в видоизмененном варианте какого-то алгоритма (выбираемым например по параметру из config-а или базе) можно действовать двумя способами:
                                                    1. Вставить пару тройку if-ов
                                                    2. Выделить логику в отдельную стратегию (рефакторинг) и создать еще одну стратегию с видоизмененной логикой.

                                                    Второй вариант в первый раз займет в два раза больше времени. Зато во второй раз эти затраты примерно сравняются.

                                                    Все как вы сказали
                                                      0
                                                      К стати интересная мысль. Затраты на внесение изменений с рефакторингом надо сравнивать не с изменениями без него. А со следующими изменениями без рефакторинга. :)
                                                  0
                                                  Есть два типа приложений.

                                                  1) Прототип. Изначально пишется для того, чтобы показывать в качестве демки. Не предполагает поддержки, расширения и т.д. Допускает наличие косяков, недочетов и т.д. Может падать. Главная цель — наглядно показать, как будет работать система, чтобы можно было на ранних стадиях как можно лучше зафиксировать требуемый функционал. Как правило реализуется заранее фиксированным набором людей в относительно короткие сроки.

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

                                                  То, что Вы описываете — это первый пункт. Поскольку у первого и второго пунктов координально разные цели, постепенное превращение первого во второе сулит существенные затраты как по бюджету, так и по времени. И стоимость ошибок, допущенных при первом подходе, при переходе во второй очень сильно возрастает.
                                                  • UFO just landed and posted this here
                                                  +4
                                                  если кто-то захочет, это можно доказать чисто математически

                                                  Очень интересно, сделайте же это.
                                                    0
                                                    Любой код, исправляющий ошибку потенциально может содержать новую ошибку. Т.е. вероятность появления новой ошибки всегда больше нуля. Получается предел — количество ошибок стремится к нулю. Идеал недостижим.
                                                      +3
                                                      Ваше рассуждение было бы верным, если бы код был бесконечно делим. Но исходный код — дискретное множество. В пределе мы приходим к некоторой единице кода — если она содержит ошибку, мы просто исправляем её. Эта единица кода не может быть верна на сколько-то процентов, поэтому процесс исправления ошибок обязательно завершится.
                                                        0
                                                        Ок. Согласен что математически показатель 0 ошибок в НЕ бесконечном объеме кода когда-нибудь будет достигнут. Не из-за дискретности множества команд, а из-за конечности суперпозиций — вариаций комбинации команд.
                                                        На практике же объем кода действительно стремится к плюс бесконечности: появляются новые фичи, исправляются старые ошибки.
                                                          +1
                                                          Было бы здорово, если это было бы правдой, но КОД ПИШУТ ЛЮДИ :-)
                                                          0
                                                          Кроме того, существуют методы написания гарантировано безошибочного кода. Насколько я помню, доказательство идёт по индукции. Сначала доказывается корректность одной простейшей команды, потом корректность суперпозиции простейших команд и т.д.
                                                          Нам на эту тему читали вводную лекцию сотрудники ИСП РАН, у них там ведётся большая работа на эту тему. К сожалению, сходу не могу найти ссылку.
                                                            0
                                                            С огромным уважением отношусь к таким исследованиям. Но исключительно с академической точки зрения. Выражения «при стремлении времени разработки к бесконечности число ошибок стремится к нулю» меня как практика ну совершенно не устраивают :).
                                                            +1
                                                            Это вовсе не значит, что на практике действительно возможно исправить абсолютно все ошибки. Даже у NASA, насколько я знаю, есть какая-то норма на тыс. строк кода.
                                                            Но ни о каком математическом доказательстве, по-моему, речи быть не может.
                                                              +7
                                                              А Ахиллес никогда не догонит черепаху, да.
                                                                +6
                                                                Это не математическое доказательство. Это псевдоматематическое рассуждение по индукции
                                                                  +1
                                                                  Та же теория вероятности допускает создание безошибочного кода с первого раза, в котором не потребуется вносить ошибки. Любой, сколь угодно маловероятный исход может наступить при первом испытании.
                                                                    +1
                                                                    Согласен, такая вероятность не нулевая. Пойду обрадую коллег.
                                                                      0
                                                                      Ага, а ещё, если посадить бесконечное число обезьян с печатными машинками, то у одной из них обязательно получится «Война и мир» ;)
                                                                        0
                                                                        Именно, хотел написать, но и так капитанский коммент получился :)
                                                                      0
                                                                      Только в том случае, если бы сложность структуры всегда возрастала.
                                                                      Если же сложность не превысит некоторой константы, то возможно исправление ошибки без внесения новых. Таким образом, занимаясь только исправлением ошибок (без расширения функционала системы), которые не приводят к бесконечному увеличению сложности, можно исправить все подобные ошибки.
                                                                      Конечно, остается открытым вопрос наличия ошибок, приводящих к бесконечному увеличению сложности. Здесь можно ответить, что наличие подобных ошибок может быть вызвано лишь попыткой реализовать то, что впринципе нельзя реализовать.
                                                                    +5
                                                                    Посмотрите на Google. Он так и не сделал категории, которые в то время были у всех поисковиков и сложно было представить, как вообще «можно без них».

                                                                    Сюрприз
                                                                      +1
                                                                      Непонятно, почему нельзя добиться безбажности продукта. Я не говорю о потенциальных ошибках, или об ошибках, о которых знаете только вы, я говорю об ошибках, которые видны пользователю. Если пользователь сообщил вам об ошибке, вы не будете ее фиксить? Вы, конечно, можете возразить, что вот мол, жизни не хватить исправить все ошибки. Не знаю, зависит от сложности и объема системы, наверное. Но и не только.

                                                                      Из собственной практики: только что завершили новый продукт на работе. Тестировать его начали практически одновременно с разработкой. В какой-то момент количество багов было пугающим, но постепенно пофиксили все. Все, что нашли тестеры. Теперь на очереди выборочное тестирование у пользователей. Найдут новые баги — пофиксим и их тоже. И те, которые потом найдут реальные пользователи. Почему не?

                                                                      Красивый код, кстати, подразумевает легкость выявления, локализации и устранения ошибок. Так почему бы не писать красивый код? (Я не имею в виду идеальный код, но просто хорошо структурированный, хорошо документированный, оттестированный, в меру отрефакторенный и т.д.)
                                                                        0
                                                                        Красивый код — это, на мой взгляд, один из основных критериев «живучести» ПО. Действительно, чёткая архитектура и аккуратный код обычно ведут к лёгкому пониманию и критическому увеличению скорости исправления ошибок и добавления новых функций.

                                                                        Но это говорит не о том, что ошибок нет. Это говорит о том, что большинство ошибок легко исправить.

                                                                        > Если пользователь сообщил вам об ошибке, вы не будете ее фиксить?
                                                                        Не всегда, к сожалению. Мир не идеален и очень часто приходится выбирать между исправлением мелкой и незначительной ошибки и добавлением нужной функции, например. IRL очень часто из двух зол приходится выбирать меньшее.
                                                                          0
                                                                          Если ошибка незначительна, почему ее нельзя поправить? Почему надо обязательно выбирать между исправлением ошибки и добавлением новой функциональности? В нормальных конторах одно другому не мешает — лишь выставляются приоритеты, скажем мы делаем новую функциональность и попутно исправляем баги — если баг мелкий, фиксим не больше одного в неделю (грубо говоря).
                                                                            0
                                                                            Может быть, я неправильно выразился. Мелкой и незначительной с точки зрения влияния на продукт, но достаточно объёмной с точки зрения объёма работы. Я ни в коем случае не говорю, что ошибки исправлять вообще не нужно :).

                                                                            А приоритеты — обязательны. Без них просто нельзя организовать нормальную работу. Собственно, я говорю о том, что иногда приходится жертвовать исправлением мелких недоработок в пользу движения продукта вперёд. У меня создалось впечатление, что мы с Вами как раз говорим об одном и том же. Нет?
                                                                              0
                                                                              Примерно. Но беда в том, что ваш пост, для нас с вами понятный, и очевидный — может быть воспринят молодыми разработчиками как призыв плевать на рефакторинг, на красивость кода, и даже на баги. А это уже не есть гуд.
                                                                                0
                                                                                Ну, я надеюсь, что у таких молодых и горячих голов найдутся здравые и трезвые руководители, которые, собственно, за проект отвечают, и которые смогут донести настоящие ценности. Впрочем, всякое, конечно, бывает в жизни. Бывают, к сожалению, и «самоорганизующиеся» команды. Причём — далеко не самым лучшим образом.
                                                                                0
                                                                                Рано или поздно продукт стабилизируется, и требований новых фич становится все меньше и меньше. Соответственно, появляется время на исправление старых ошибок, и их число начинает уменьшаться. Единственный вопрос, что кончится раньше: ошибки или поддержка продукта.
                                                                            0
                                                                            пиши красивый, никто не мешает. но главное — «вам шашечки или ехать»?
                                                                              0
                                                                              В данном случае, боюсь, что без шашечек далеко вряд ли уехать удастся… Другое дело — сколько времени на эти шашечки уйдёт.
                                                                                +1
                                                                                Нет, в данном случае это неправильно. Потому что вопрос будет не про шашечки, а «вам вообще доехать надо?» или «как предпочитаете — с нормальным мотором или вот тут у меня баг — выхлопная труба имеет выход в салон...?»
                                                                                +1
                                                                                > Непонятно, почему нельзя добиться безбажности продукта.

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

                                                                                Мне лично чаще приходится бороться не с багами в моей программе, а с тем «окружением», в котором работает моя программа (j2me-программирование на мобилах). Счиать ли багом то, что программа не работает по причине банальной нехватки оперативки? Считать ли багом программы если она не смогла сохранить данные по причине нехватки места на флешке? Считать ли багом программы невозможность соединения с сервером если у юзера банально не настроен доступ в интернет на телефоне? Для пользователя — это баг. А для разработчика — это головная боль

                                                                                Грубо говоря — можно ли считать notepad.exe бажной программой если он не может открыть файл в 100 мегабайт (по нынешним временам — не так уж много)? Можно ли писать баг-репорт в Адобе если вы не смогли открыть файл размером 100500x100500?
                                                                                  0
                                                                                  Баг — это не отсутствие некоторых возможностей программы, или ограничения, а неадекватная реакция программы на попытку выйти за пределы этих ограничений.

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

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

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

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

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

                                                                                  И вообще, как это для разработчика баг может быть головной болью? Это наш хлеб, в конце концов! :)
                                                                                  +1
                                                                                  > Красивый код, кстати, подразумевает легкость выявления, локализации
                                                                                  > и устранения ошибок. Так почему бы не писать красивый код? (Я не имею
                                                                                  > в виду идеальный код, но просто хорошо структурированный, хорошо
                                                                                  > документированный, оттестированный, в меру отрефакторенный и т.д.)

                                                                                  Потому что «красивый код» — это не объективный критерий, а функция от многих переменных, в том числе от t (то есть от времени). То что красиво вчера — будет некрасиво сегодня и безобразно завтра. Меняется остальная часть программы, меняется среда в которой эта программа работает. Мне, право же, трудно приводить примеры, которые нельзя было бы оспорить, но по-моему такое встречается сплошь и рядом. Если сейчас свежим взглядом посмотрть, допустим, на рендеринг сцен в каком-нибудь DOOM? Неужели програмист, который владеет DirectX оценит тот код начала 90-ых годов и скажет «вах, красиво, Вася!»

                                                                                    0
                                                                                    Думаю, если код действитльно аккуратный и понятный — да, оценит
                                                                                  –1
                                                                                  И инженера спокойно терпят ежедневные политинформации? Или им приплачивают?
                                                                                    –1
                                                                                    плюсанул.

                                                                                    красава.

                                                                                    разделяю точку зрения.

                                                                                    практики поддержат, теоретики — поднимут вой и хай
                                                                                      +1
                                                                                      Полностью согласен с автором. У меня есть код, который я писал 11 лет назад, когда только осваивал Перл. Этот код ужасен. Но он работает так, как задумано. Уже 11 лет подряд, круглосуточно в системе для одного GSM-провайдера. И не думаю, что до конца жизни проекта его кто-то будет переписывать.
                                                                                      Как написали выше — практики поймут, а теоретики начнут холивар :)
                                                                                        +1
                                                                                        По-моему, статья совсем о другом. И холивар тоже о другом. У меня тоже есть продукт, который был написан почти 10 лет назад, и код был ужасен, и архитектура была ужасна (да и не было там по сути никакой архитектуры), и он, так же, как и ваш, работает тем не менее. Никто не говорит о том, чтобы перелопачивать и переписывать старый уродский код. Но теперь, когда вы старый матерый волк, теперь-то вы уж стараетесь сделать ваш новый код покрасивее, правда? И не спешите написать его как можно скорее, «лишь бы работало»?
                                                                                          –1
                                                                                          А вот это уж зависит от того, для чего нужен код. Если это одноразовый парсер, который требуется ровно один раз, чтобы перегнать один формат в другой — то почему бы не написать а-ля «поток сознания» вместо того, чтобы писать всё красиво? Экономится куча времени, которое можно посвятить тому же Хабру :)
                                                                                          Очень часто в мире программирования есть сроки. И если стараться всегда вписываться в сроки — то не всегда получается вписываться в «красивость».
                                                                                          Но, разумеется, если есть время — то у меня есть куча кода, который переписывался раз 3-5, но даже после пятого раза всегда можно к чему-нибудь придраться. Идеал недостижим :)
                                                                                            +2
                                                                                            Когда написание красивого, структурированного кода войдет у вас в привычку, вы даже одноразовый код будете делать хорошо. Я не имею в виду, что надо городить кучу классов и сложную иерархию, когда можно обойтись без классов вообще, но скажем, выделить в отдельные методы (функции) повторяющийся код, не использовать магические числа, давать функциям осмысленные имена и тому подобные мелочи, которые делают код красивым — все это как минимум поможет сделать даже одноразовый код правильным. Ведь вам надо убедиться, что код отпарсил и сконвертировал все правильно? Возможно, придется написать парочку простых тестов. И кто знает, вдруг вы захотите использовать этот код в дальнейшем? Или использовать его для конвертирования других форматов?

                                                                                            Опять же, речь вовсе не о переписывании идет, а о написании хорошего кода с нуля. И дело не в том, чтобы комар носа не подточил, а в том, чтобы этим кодом потом можно было воспользоваться дальше, чтобы он не имел багов только потому, что написан по-уродски и т.д.
                                                                                              +1
                                                                                              Ну разумеется, речь не идёт о том, чтобы изначально писать уродский код — с этим спорить как минимум глупо.

                                                                                              Но и рефакторинг ради рефакторинга _рабочего_ кода — тоже не следует проводить :)
                                                                                        +1
                                                                                        В общем то все правильно. Только вот некоторые части системы (к примеру, касающиеся безопасности) лучше отдать делать параноику-перфекционисту.
                                                                                          +3
                                                                                          Уточню что хотел сказать.

                                                                                          Для разных систем (и даже более — для разных частей одной системы) — требуется разный уровень «шлифовки».
                                                                                          +1
                                                                                          Чрезмерная шлифовка ~~ онанизм.
                                                                                            +1
                                                                                            Я вот иногда, когда вырисовывается необходимость добавления в продукт нового функционала, дёргаю всех имеющих к нему отношение людей (программистов, тестеров, руководство, клиентов), обрисовываю ситуацию и спрашиваю, в каком объёме нужно реализовать задачу.
                                                                                            А дальше:
                                                                                            20% самых масштабных ответов выбрасываю — это перфекционисты, нам с ними не по пути
                                                                                            20% самых коротких ответов выбрасываю — это леняи, аналогично

                                                                                            Из оставшегося берём среднее арифметическое и добавляем 20%. Вот это и есть идеальный план. Чаще всего такой план высказывается специалистами, ответственными за внедрение разработки на объекте заказчика. Они очень хорошо понимают, что ни полностью идеальный продукт через 10 лет, ни детская поделка через 2 дня никому нафиг не нужны.
                                                                                              0
                                                                                              Мое маленькое имхо-лично я код пишу не для галочки, не для начальника или еще кого-я пишу код для себя. Пишу и правлю какой-то код ровно до тех пор, пока он не начинает мне нравится, когда я понимаю что в этот раз я лучше уже не напишу. Вот когда я это понимаю-я пишу что-то другое. Не хочу идти на какие то компромисы по принципу-я что нито напишу, не на полную силу, не идеально, типа сойдет. Я уже давно отказался от этого, потому что пишу свой софт в первую очередь для пользователей, а тут предельно важно, чтобы пользователь был доволен. Для меня довольный пользователь гораздо важнее довольного начальника или довольного тестера, потому что они всего лишь прослойка между пользователем и мной.
                                                                                                0
                                                                                                У вас по работе наверно бывает оч много конфликтов?
                                                                                                  0
                                                                                                  бывает но мало
                                                                                                  0
                                                                                                  А сроки на разработку той или иной фичи Вы сами указываете? Вы их как-то обосновываете? Почему-то кажется, что в вашем случае это реальная проблема. Я прав?
                                                                                                    0
                                                                                                    сроки это результат договоренности с заказчиком. он называет что ему надо, я говорю сколько на это потребуется времени. если его не устраивают сроки, мы переносим какие то фичи на следующие релизы. сроки являются реальной проблемой когда они спускаются разрабтчикам сверху менеджерами, которые имеют слабое понимание процесса разработки ПО. Бывает, что и разработчики, пытаясь угодить начальству, называют или заранее нереальные сроки, или сроки, взятые с потолка на глазок. Это не наш метод и мы такие случаи даже не рассматриваем
                                                                                                      0
                                                                                                      Получается, что Вы сами взаимодействуете с заказчиком? Т.е. сами себе ПМ? В этом случае я могу только пожелать Вам удачи в поисках заказчиков, которые соглашаются на ваши сроки. Это — главное.
                                                                                                        0
                                                                                                        естественно сам. не люблю испорченных телефонов в виде менеджеров, заместителей директора и прочих вторичностей. спасибо за пожелание
                                                                                                          0
                                                                                                          Не, ну уж насчёт испорченных телефонов Вы перегнули :). Если Вы работаете один над каким-то только вам известным проектом — это нормально. Но более-менее серьёзный проект тяжело без ПМа вести. Хороший руководитель проекта — это член команды разработки, а не очередная цепочка в бюрократии.
                                                                                                    0
                                                                                                    пользователь никогда не увидит кода, ему главное чтобы работало так, как он ожидает от софта.
                                                                                                      +1
                                                                                                      но мне зато этот код потом модифицировать, фиксить, расширять… ну или не мне а другому девелоперу. гораздо приятнее и эффективнее работать с хорошо написанным кодом, чем с помойкой
                                                                                                        +1
                                                                                                        ну или вот-вы скажем конструктор и делаете автомобиль. покупателю все равно, что там под капотом и под брюхом, вы можете там какую угодно кашу из проводов и деталей сделать, но если что-то сломается, то вам или вашим коллегам придется в эту кашу залезать, чтобы исправить проблему. Поэтому гораздо более разумно под капотом привести все в полный порядок
                                                                                                      0
                                                                                                      Простите, но «сведение количества ошибок к нулю. Да это и невозможно (если кто-то захочет, это можно доказать чисто математически)»
                                                                                                      противоречит
                                                                                                      «ошибок в жизненно важных частях бизнес логики быть не должно»
                                                                                                      И это вполне по силам заметить на слух. Так что подозреваю, что «очень проникновенная речь» не получилось. Возможно так же что немного уменьшился авторитет в глазах некоторых участников команды.

                                                                                                      Что же до сабжа — я тоже думаю, что уже давно наступила эпоха «наивных реализаций», но не все себе ещё в этом признались.
                                                                                                        0
                                                                                                        Зря подозреваете, не уменьшился ни капли :). Ели бы авторитет меняется от таких мелочей, значит руководитель так себе.
                                                                                                        +1
                                                                                                        ИМХО для оценки «достаточности» можно воспользоваться правилом Парето: например уделять особое внимание 20% наиболее важной функциональности, 20% наиболее критических ошибок и т.п. Естественно, что это может быть не 20%, а где-то рядом, и, естественно, что я не призываю забить на остальные 80% функционала и ошибок.

                                                                                                        Для реализации всего-то необходимо: оценка важности чего-то (функции, ошибки и т.п.) и мониторинг ситуации в реальном времени.

                                                                                                        Only users with full accounts can post comments. Log in, please.