Об идеальном коде и суровой реальности

    Думаю, никто не будет спорить, что программный код должен быть чистым и «не пахнуть» (code smell), а паттерны проектирования и TDD должны стать верными спутниками любого мало-мальски грамотного разработчика на протяжении его нелегкой, но продуктивной карьеры. Все также знают, что цена ошибки в продакшине возрастает в десятки раз, а также то, что хорошие программисты оптимизируют код, а плохие — покупают новые сервера, а еще то, что 9 женщин не родят одного ребенка за месяц.



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

    Аутсорсерам выгодно писать говнокод


    Что уж тут скрывать — большинство успешных компаний, работающих на локальных рынках — аутсорсеры, которые, как все знают, зарабатывают на оказании сервисных услуг внешним заказчикам. Если fixed price — ок, еще есть надежда, что код будут писать грамотно, но если time & materials…

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

    Знаю случаи, когда разработчики умышленно в системе делали баги, чтобы потом получить дополнительно заказ на поддержку. А в одной из прошлых компаний товарищ назвал свою роль в компании как «bug maker»! Он этим очень гордился, т.к. не давал расслабиться еще 3 разработчикам и 2 тестерам :-)

    Пишете хороший код — вас могут уволить!


    Звучит совсем чудовищно, но вам не показалось. Хороший разработчик и сильный архитектор — всегда (?) ценный сотрудник, но в некоторых случаях (например, во фрилансе или если вы подрядчик) от вас могут избавиться, как только вы сделаете всю сложную работу и обучите индийских обезьянок методически раскрашивать код в нужном порядке. Шучу? Нет.

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

    Рефакторинг ради рефакторинга


    Пожалуй, проблема всех хороших (или потенциально хороших) разработчиков. Выбросить все и написать сначала! Добавим еще синдром «Not invented here» и получим полный набор проблем… для начальства и заказчика. Ведь разработчики во главе с тимлидом не бизнес проблему решают, а играют в игру под названием «идеальный код».

    Писать говнокод иногда нужно


    Например, если вы пишите прототип, проверяете идею, занимаетесь Research & Development. В таких случаях идеальный код с трехуровневым ООП поверх TDD с эджайлом — скорее враг, чем помощник. Т.к. задача — проверить гипотезу, догадку, сэкономить время в будещем на исправление архитектурных или функциональных косяков.

    Почему все-таки считается, что нужно писать идеальный код?


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

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

    Вторая проблема — постоянная неудовлетворенность разработчика своим кодом. Месячный код хочется сжечь, полугодичный — съесть, из-за кода, написанного 3 года назад, хочется кого-то убить. Не дайте Астронавтам Архитектуры вас запугать!

    Не нужно писать говнокод умышленно


    Только по расчету!

    В одном проекте для очень именитого заказчика в начале работы не было требований по поводу code conventions. Собственно, не поддавшись на такую халяву, в команде были установлены вполне конкретные жесткие правила + регулярный код ревью. В итоге за неделю до сдачи проекта заказчики таки раздуплились и выкатили code conventions, что ввело в ступор начальство (ну и меня тоже, т.к. сдавать продукт нужно было мне). Но за счет контроля с самого начала проекта все доработки заняли максимум день.

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

    Заставьте себя написать хотя бы один проект «правильно», и потом вы просто не сможете это делать по другому ;-)

    Спасибо за внимание и белоснежного вам кода!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 101
    • +75
      Видел уже такое…
      image
      • +9
        Думаю, что сотрудники многих компаний уже сделали что-то подобное.
        • +1
          Так вот почему они меня не взяли!
          • 0
            Из-за вашего хабр-ника? :)
        • +25
          По-поводу прототипа. Почти всегда прототип после того как он себя оправдал тут же превращается в продукт. И когда разработчика пытаются убедить что нужно писать быстро и абы как, а потом напишем нормально. Это наглая ложь!
          • +3
            Как вариант: писать прототип на языке/платформе, которые в продакшен не пойдут с очень большой вероятностью.
            • +2
              т.е. например наняли несколько java/ruby/.net программистов, а прототип им писать на php?
              • +8
                Написали прототип на Ruby, утвердили и сделали на PHP.
                • +3
                  Смешно.
                  • +5
                    Реальное использование. RoR удобен для прототипирования, проработки концепций и т. п., но для продакшена у него есть недостатки (прежде всего экономического плана).
                    • –3
                      Просто надо знать область применения. Для клепания сайтов в конвейерном режиме не подходит, для средних приложений — идеально. Не знаю о чем вы, про «экономический план».
                      • 0
                        Посмотрите любой холивар PHP vs Ruby.
                        • 0
                          Ну про какие-то недостатки RoR не я сказал, но если простое уточнение рискует перерасти в холивар — я пас.
                          • +4
                            В общем у PHP есть преимущества для бизнеса. Проще говоря, поддержка будет дешевле.
                            • –4
                              На разницу зарплат? Так нормальные специалисты стоят одинаково плюс-минус, а если «х*як-х*як и в продакшн» тогда конечно, тут такого нет.
                              • +4
                                Специалистов среднего уровня заметно больше.
                                • +2
                                  Ребята пхп-шники, спасибо за минусы и слитую карму :) Но лучше вы бы высказали аргументы.
                                  • +1
                                    «Смешно» — это аргумент?
                                    • 0
                                      Какой комментарий — таков ответ. Я думал, вы реальные недостатки RoR обрисуете, раз уж высказались в таком ключе. А вы отделались общими фразами «читайте холивары» и «стоимость поддержки».
                                      • 0
                                        В тех самых холиварах всё неоднократно обсасывалось вплоть до таких нюансов как сколько возьмёт админ-фрилансер за разворачивание и администрирование Ruby-приложения, а сколько за PHP.
                                  • +6
                                    Это в рельсах-то нет «х*як-х*як и в продакшн»?!
                                  • 0
                                    А производительность?
                                    • 0
                                      Вроде одного порядка, что у Ruby, что у PHP (с кэшером), что у Python например.
                            • +1
                              А Пи Джи Хайетт-то и не в курсе. Или github еще не вышел в продакшн?
                              • 0
                                Предполагаю, что для них недостатки несущественны или компенсируются достоинствами. Всё от бизнес-задач зависит, в том числе от их масштаба.
                                • 0
                                  Ну вот другое дело. «Каждый язык удобен для своего класса задач». Тут не поспоришь.
                                  А то сразу «для прототипирования хорош, но для продакшена плох».
                                  • –1
                                    «Плох» я не говорил. Просто PHP лучше :) Особенно если в ТЗ стоит «платформа LAMP».
                                    • 0
                                      Я берусь только за ТЗ на «платформе LAMER» (LAM + Enterprise Ruby).
                                      • –2
                                        А я только за LAMP, поскольку приложение на Ruby администрировать и поддерживать не возьмусь.
                        • +1
                          Писать прото на JS :)
                        • +1
                          ну это возможно, если цель прототипа — показать заказчику, как это будет выглядеть на экране. кнопочки, окошечки.

                          а в наше неспокойное время частенько компании хватаются за проекты, в которых требуется использовать неизвестные им технологии (но кто ж в этом признается, когда вот они, деньги!) и тут уже прототип больше нужен самим программистам, чтоб опробовать новый стек, слепить из 10 туториалов и заметок на стековерфлоу нечто, напоминающее систему.
                          • +1
                            Не столько показать, сколько получить фидбэк, проверить юзабилити и т. п.
                            • 0
                              это тоже, но всё равно — упор на интерфейс, а не на начинку.
                              • 0
                                А у меня другая проблема:
                                я им говорю: я не понимаю, что вы хотите получить. пожалуйста, накидайте хоть на бумажке схему того, как все должно работать, я сделаю рабочий вариант.
                                Но мне говорят: мы сами не знаем, сделайте как-нибудь, а потом переделаем!

                                В результате:
                                они говорят — ты сделал плохо, мы вообще просили не так.
                                я говорю — (написал говно), все переделывать заново.

                                В результате, не вижу средств, как с этим бороться, кроме смены места работы.
                                В итоге такой код я называю «энтерпрайз», с пометкой «нет ничего более постоянного, чем временное».
                                • 0
                                  Знакомо. Выход — каждую идею о том, как должно быть реализовано та или иная часть, быстренько прототипировать, показывать, переделывать если «мы просили не так», а когда всё «так», то писать уже нормально. Но при этом, пока заказчик не скажет «всё так», он должен понимать, что это прототип, который будет выкинут. Как вариант — серьезно доработан, и необходимость доработки должна быть очевидна даже (вернее особенно) для не разбирающегося в разработке человека. Хорошо работают, скажем, использование in-memory хранилищ, а не нормальных БД на стадии прототипирования или вывод всякой отладочной информации, игнорирование возможности кэширования, использование заведомо неэффективных алгоритмов или запросов к БД. В общем под шумок «полировки» переделать чуть более чем полностью.
                            • 0
                              О! В свете давно читаемых мной на Хабре споров на тему, стоит выбрасывать или развивать прототип, интересный приём…
                              • 0
                                Собственно да, чтобы соблазна оставить не было :)
                            • +2
                              Задача грамотного лидера разработки убедить подопечных, что быстро писать можно будет только если код будет чистым. Тогда и не будет идеологического противостояния с бизнессом.

                              А вот избыточную архитектуру в прототипах — часто действительно не нужно городить. был сведетелем, когда приходилось переписывать прототипы, после того, как они стали продуктом. Но главное было то, что прототип успешно приносил деньги. А значит — свою задачу выполнил.
                              • 0
                                Не только прототип, есть множество всяких «временных» заглушек. Но нет ничего более постоянного чем временное…
                              • +33
                                Ребят, есть идеальный код, а есть просто хорошо структурированный.

                                Так вот, идеальный код — практически не возможно писать (но можно стремиться). При пересмотре через месяц — всегда придумаешь как его можно было бы улучшить, или решить проблему более гибко/элегантно.

                                Структурированный, чистый, читаемый код — это код, который может быть «тупым», но легко понимаемым и читаемым. Возможно он не даст гибкости, но он позволит быстро найти ошибку в логике программы. И исходя из этого посыла НЕ СУЩЕСТВУЕТ причин, не писать хорошо структурированный код.
                                • +8
                                  «Заставьте себя написать хотя бы один проект «правильно», и потом вы просто не сможете это делать по другому ;-)»
                                  Голая правда!
                                    • +3
                                      хорошие программисты оптимизируют код, а плохие — покупают новые сервера

                                      Вот с этим бы не согласился, такое верно далеко не всегда. Оптимизированный код как правило стоит дороже неоптимизированного, и его сложнее читать и модифицировать. Поэтому я считаю допустимым лечить проблемы с вырастающей нагрузкой подконтрольным улучшением железа для многих ситуаций. А уж если неоптимизированный код и так потребляет три процента ресурсов, так тем более незачем его менять.
                                      • +1
                                        Абсолютно верно. Если код масштабиуется и проблемы производительности решаются докупкой серверов — это просто прекрасно. Железо стоит намного дешевле, чем труд квалифицированных специалистов.
                                        • 0
                                          Не так дорого железо, как его содержание, по этому горизонтальная масштабируемость — это прекрасно, но и о приложении тоже нужно думать.
                                          Я не говорю о микрооптимизациях, за исключением разве что векторизации кода для современных CPU в некотором классе задач, а о алгоритмических оптимизациях, которые, если хорошо подумать над алгоритмами, могут существенно отсрочить необходимость закупки и содержания дополнительного оборудования.
                                        • 0
                                          А уж если неоптимизированный код и так потребляет три процента ресурсов, так тем более незачем его менять.

                                          Раз стоит проблема покупать новые сервера или оптимизировать то явно потребляет больше 3-х процентов ресурсов.

                                          Кроме того есть разные уровни оптимизации:
                                          Можно оптимизировать путем внедрения низкоуровневых оптимизаций и т.д. — такой подход действительно может ухудшить читаемость.
                                          Но на самом деле самые важные оптимизации это как правило структурные (закешировать результат тяжелых вычислений, минимизировать обращения к БД, удаленным обьектам, убрать дублирование логики) и на мой взгляд такие оптимизации только улучшат читаемость.
                                          Если код на 1 полезное действие выполняет 100500 бесполезных операций но при этом хорошо масштабируется добавлением железа то этого железа достаточно никогда не будет
                                          • 0
                                            Мой комментарий был настолько общий, насколько это вообще возможно. Оптимизация кода — сложная и разносторонняя дисциплина, можно приводить много примеров как легких и полезных оптимизаций, так и сложных и ненужных. Да и перед разработчиками ПО задачи самые разные стоят. Одно дело программировать по четкому ТЗ, зная характеристики целевого железа, видя всю архитектуру и взаимосвязи компонентов перед глазами и рассчитав предварительно нагрузки, а другое дело — для себя по ночам новомодный стартап писать, не зная, выстрелит он, или вы так и останетесь его единственным пользователем.
                                            • 0
                                              В общем, да — само убирание со всех уровней дублирования логики и дублирования данных — это то, что приводит к улучшению читаемости и к улучшению надежности. Также дает возможность потом оптимизировать.

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

                                              Не так. Закешировать — это продублировать. Это никогда не улучшает читаемость. Кеширование — это дублирование данных. Появляются новые проблемы — проблемы синхронности данных. Нужно создавать механизмы, проверяющие актуальность кеша, или обновляющие кеш при изменении главного источника данных. Есть БД — значит там главный источник данных.
                                              Кеширование — это уже оптимизация. Т.е. низкоуровневая оптимизация. Ее не надо делать в процессе разработки, только в конце.
                                              Вот почему я пишу, что хорошие программисты покупают сервера. Если программисты оптимизируют все время, то в коде появляются монстроидальные конструкции, дублирующие данные. Появляются неявные зависимости. И тогда добавить сервера и решить проблему железом просто не получится.

                                              Один из замечательный приемов оптимизации — писать как можно проще. Это дает больше возможностей в дальнейшем распараллелить работу. Между потоками, между процессами, между серверам и как угодно.
                                            • –4
                                              Даже совсем наоборот: хорошие программисты покупают сервера, а плохие оптимизируют.
                                            • +4
                                              В одной из компаний перед тем как садиться писать оценку проекта и комерческое приложение, я (в обход начальства) всегда спрашивал у заказчика...


                                              Вас за это не уволили? Мне кажется, мало кому из начальства такое может понравиться.
                                              • +2
                                                Правда в том, что процент заказчиков, с которыми мы подписывали договор, значительно увеличился, а время на подготовку маркетинговых материалов и написание оценок — уменьшился. В убыток, естественно, не работали, но и счета аля «Студия Лебедева» не выставляли.
                                              • +4
                                                Не дайте Астронавтам Архитектуры вас запугать!

                                                Да-да, мне тоже в свое время очень понравился этот пост Спольски.
                                                • 0
                                                  Я ещё до того, как увидел дату, понял, когда оно написано. Оно, конечно, выражает достаточно трезвую мысль, но подаётся в очень специфическом ключе, весьма субъективно. Я бы сказал — однобоко.
                                                • 0
                                                  Тема раскрыта не до конца. Рассматривается только суровая реальность написания кода для стороннего заказчика.
                                                  Если заказчик — сама компания в которой ты работаешь (например, какой-нибудь SAAS) и поддерживать код и архитектуру, которую ты пишешь сейчас тебе предстоит годами, то я думаю вопрос о возможности говнокода, отказа от TDD и хороших практик тут вообще стоять не должен.
                                                  • 0
                                                    Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра, и хотим собрать прототип, неким образом обрабатывающий его данные. Скажем — строит какието стат. графики.

                                                    Второй вариант: К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.

                                                    Я в упор не вижу смысла в этих случаях заморачиваться с гибкой архитектурой, или заставлять людей переучиваться на TDD.
                                                    • 0
                                                      > Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра

                                                      В этом случае проблем не вижу, в песочнице на дев-сервере попробовать можно и без TDD.
                                                      Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?
                                                      Как вы об этом узнаете? От клиентов? Как раз-таки в этом случае стороннего API без нормальной архитектуры и TDD вы далеко не уедете.

                                                      > К некой дате нужно выпустить некий промо(викторина/розыгрыш), который день покрутится, а после будет забыт и удалён.

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

                                                      PS. Во всем нужен здравый смысл и мера
                                                      • +1
                                                        >>Хотя, я не понимаю как вы убедитесь что оно работает как вы ожидаете. Ручками будете API методы вызывать и сверять с ожидаемым результатом? А если завтра обновленное API партнера вместо ожидаемого графика вам пришлет котиков?

                                                        Собственно зачастую прототипы и проверяются в ручную — есть график или нет. даже если он немного не точен — то свою задачу, проверить, возможно ли что-то сделать или нет — он выполнил. А завтра — нам API может уже и не понадобиться. Опять таки — прототипы, как правило, клиентам не показываются. А если и показываются — то тщательно тестируются вручную, или автоматизированными тестами. И самое главное — прототип=далеко не едем.

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

                                                        Викторина к 8 марта — ну всемы понимаем, что это не вечный проект, правда? :)

                                                        И да, чуть не забыл — xkcd.ru/i/292_v1.png (картинку вставить не могу, уж извините)
                                                        • 0
                                                          Ну да, главное чтобы все понимали что это только прототип. И не надо его завтра выкладывать в продакшн, хоть он и работает на первый взгляд =)

                                                          А вообще, суровая реальность в том, что хороший проект делается со второго раза, ну или уж точно не с первого. Первый вариант — обкатка идеи, сбор требований и анализ ошибок. Потом все переписывается правильно.
                                                          • +2
                                                            Суровая реальность в том, что хороший проект делается со второго раза при том, что обычно всё рассчитано на то, что обойдётся без второго раза.
                                                          • 0
                                                            А викторина к 8 марта — это ж вечный проект. 8 марта каждый год внезапно случается). Или каждый год новую писать? )
                                                        • 0
                                                          Допустим мы хотим проверить, насколько удобно воспользоваться API некого, возможного партнёра, и хотим собрать прототип, неким образом обрабатывающий его данные. Скажем — строит какието стат. графики.


                                                          А Вам не кажется, что решение этой задачи и сводится к TDD в чистом виде?

                                                          А если разговор идёт о том, что людям на TDD придётся переучиваться… не понимаю, продакшн всё ещё без автоматического тестирования? Или дело дальше прототипов никогда не доходило?

                                                          TDD вообще начинается в тот момент, когда изучаешь новый для себя язык программирования или фреймворк — пишешь различные helloworld'ы, которые тебе показывают, как реально система реагирует на твой код. И этому в общем-то не нужно много учиться, можно только повышать уровень мастерства — систематизируя тесты и налаживая их автоматическую работу, используя межпроектные библиотеки тестов.
                                                          • 0
                                                            TDD всё же проверка, что система ожидаемо реагирует на код. Для изучения вообще непонятного API анализ дампов или просто вывода всё же предпочтительней.

                                                            И тесты на перед деплоем на продакшен ещё далеко не для всех норма.
                                                            • 0
                                                              Эх, старый разговор )
                                                              Но я, собственно, к чему про хелловорлды? У меня подобных тестов для стандартных библиотек и самого языка прилично. Как оказалось не зря — поведение меняется, да и сам бывает забываешь тонкости, можно тест посмотреть.
                                                              А в остальном да — чего уж спорить — в очердной раз сталкиваюсь с этим и грустно становится…
                                                        • 0
                                                          НТП сейчас такими скачками прыгает, что «код и архитектура, поддерживаемые годами» автоматически превратятся в говнокод и устаревшие практики. Почти с гарантией.

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

                                                          • 0
                                                            Разве код крупных проектов, используемых по всему миру постоянно переписывается с нуля?
                                                            Согласен, что определённые практики и представления об «идеальном» устаревают, но вот поддерживать иные вещи действительно приходится в течение нескольких технологических «волн». Разумеется, это не касается сайтов, которые не перерастают даже виртуальный хостинг.
                                                            • 0
                                                              Нет, конечно. Я, вероятно, не слишком внятно выразился.

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

                                                              Не опускаться ниже уровня «хорошо» и постоянно подтягивать до своего уровня, — разумеется, необходимо.
                                                              • 0
                                                                А во что превращаются «так себе» практики?
                                                                • 0
                                                                  А они как раз — тот самый середнячок, крепкий орешек, на котором держится чуть не бо́льшая половина всего кода.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                          • 0
                                                            Вот допиливать потом на перекурах плохая практика, потом начинает появляться практика допиливать плохой проект работа по 9-10 часов. Так быстро выгораешь и теряется удовольствие от работы, В последствии может упасть продуктивность труда. И хороший менеджер должен это дело мониторить и вовремя предотвращать
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                          • 0
                                                            >Ментальная ошибка в том, что чаще всего код не нужно поддерживать или нужно будет поддерживать не вам.

                                                            Бинго! Почему-то это все время замалчивают.

                                                            Весь фокус в том, что все конторы разные. Нужно понимать где ты работаешь и что нужно конторе.
                                                            • 0
                                                              Ну не знаю, сталкивался с ситуацией когда в продакшен молча отправляют заведомо глючный код (код который не обрабатывает edge cases) с мотивировкой «нужно быстрее всё сделать» либо с просто молчаливым игнорированием проблемы.

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

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

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

                                                                Если вам не нравится поддерживать плохой код, то почему вы его пишете?
                                                                • +1
                                                                  Меня тоже очень раздражает такой подход. Для меня писать максимально качественный код (в рамках имеющегося бюджета и ресурсов) вопрос профессиональной гордости.
                                                                  А говорить что можно писать плохо т.к. поддерживать все равно не вам это все равно что наложить кучу соседу под дверь — убирать то все равно не вам. Просто однажды вы найдете такую же кучу и под вашей дверью.

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

                                                                  Качественно обычно и бывает быстро просто это становится заметно ближе к концу проекта.
                                                                  • 0
                                                                    Может потому, что поддерживать не тебе? Или потому, что менеджмент ценит такое «геройство»? (я не про себя, просто пытаюсь найти объяснение)
                                                                  • +2
                                                                    Статья про какой-то странный мир, в котором только один разработчик и отсуствует конкуренция. Работая как фрилансер с почасовой оплатой и создавая проекты которые практически не нуждаются в суппорте никогда не жаловался на недостатки этого метода, если у клиента отлично работает один проект он обязательно найдет еще один и вдобавок друзей приведет, которым другие говнокода понаписали и просят денег за поддержку.
                                                                    • +1
                                                                      «Темой статьи является применение методов управления качеством в производстве программного обеспечения»…

                                                                      Чтоб адекватно писать говнокод, надо уметь писать хороший код и иметь большой опыт написания хорошего кода. По крайней мере, очевидных «запахов» типа длинных методов и повторного использования переменных будет меньше. Нужно иметь за спиной этап, на котором качественный код является вопросом профессиональной гордости.
                                                                    • 0
                                                                      Если fixed price — ок, еще есть надежда, что код будут писать грамотно, но если time & materials…

                                                                      Откуда, интересно, у вас такое мнение? Зачем писать код грамотно, если можно написать быстро и получить в итоге больше денег за меньше времени и трудозатрат? Не говоря уже о случае, когда сроки превышены, и исполнитель начинает работать себе в убыток. Думаете, его будет заботить качество кода в такой ситуации?
                                                                      • –2
                                                                        По моему опыту, если качество кода даётся дёшево (для чего и служат использование Eclipse с рефакторингом и Java), то писать качественнее получается быстрее.
                                                                      • 0
                                                                        У кода есть два аспекта: чистота и работоспособность. Другими словами, надо стремиться к «чистому коду, который работает правильно». От баланса между этими двумя аспектами и зависит подход к разработке. Когда пишутся прототипы, то основная цель — сделать работающий код. Чистота его на тот момент не нужна. Но для поддержки кода в будущем, исправления найденных в нем дефектов, адаптации его под новые задачи без огромных затрат времени нужно заботиться и об аспекте чистоты.

                                                                        В XP (eXtreme Programming) специально выделяется практика написания spike. Это специальный формат задачи (технической истории), цель которой уменьшить неопределенность и технологические риски при реализации основной задачи. По правилам код, написанный во время реализации spike, не может быть перенесен в основную ветку. Поэтому его можно писать, не заботясь о поддержке в будущем.

                                                                        В целом, от баланса между указанными двумя аспектами и зависит решение, стоит ли писать чистый код в том или ином случае. Но люди, которые привыкли писать чистый код, потом просто не могут иначе… :)
                                                                        • 0
                                                                          >>От баланса между этими двумя аспектами и зависит подход к разработке
                                                                          Простите, вы хотите сказать, что чистый код менее работоспособный, или работоспособный — менее чистый? Это ведь бред.

                                                                          >>Когда пишутся прототипы, то основная цель — сделать работающий код.Чистота его на тот момент не нужна.

                                                                          Почему? Попробуйте писать чистый код, и Вы увидите, что писать стало БЫСТРЕЕ (а ведь мы хотим писать прототипы быстрее). Ошибки (которые надо устранять и в прототипах) — исправляются много быстрее.

                                                                          Каждый раз, когда Вы пишете грязный код, Вы гадите себе в проф. качества. Да, в данном конкретном случае Ваш код не помешал. Но на подсознательном отложилась возможность писать кривой код. И это ОБЯЗАТЕЛЬНО вылезет Вам боком. Так что чистый код — писать нужно в любом случае.
                                                                          • –1
                                                                            Простите, вы хотите сказать, что чистый код менее работоспособный, или работоспособный — менее чистый? Это ведь бред.

                                                                            Это два независимых аспекта кода. Я как раз это и написал.
                                                                            Почему? Попробуйте писать чистый код, и Вы увидите, что писать стало БЫСТРЕЕ (а ведь мы хотим писать прототипы быстрее). Ошибки (которые надо устранять и в прототипах) — исправляются много быстрее.

                                                                            Дело в том, что часто для проверки какой-то идеи не надо создавать хорошего, поддерживаемого дизайна, использовать шаблоны проектирования, следить за размером методов и классов. Можно даже использовать не рекомендуемые в обычной жизни вещи: статику, прямое обращение к файловой системе, базе данных и т.д. И это будет реально быстрее.
                                                                            Каждый раз, когда Вы пишете грязный код, Вы гадите себе в проф. качества. Да, в данном конкретном случае Ваш код не помешал. Но на подсознательном отложилась возможность писать кривой код. И это ОБЯЗАТЕЛЬНО вылезет Вам боком. Так что чистый код — писать нужно в любом случае.

                                                                            Я как раз сторонник чистого кода. Уже 6 лет работаю строго по TDD, на каждом проекте применяется 100% ревью кода, парное программирование на сложных задачах и статические анализаторы (очень грамотно настроенный Sonar). Но ничего не мешает мне пробовать идеи без всех этих техник, чтобы потом выбросить этот код и написать хорошее решение. Нет смысла вкладывать в качество того, что может не справиться с задачей, поставленной требованиями.
                                                                            • 0
                                                                              >>Это два независимых аспекта кода. Я как раз это и написал.
                                                                              Когда мы говорим о независимых аспектах — не нужно добиватся баланса. Они же независят.

                                                                              Для проверки идеи — хорошобы использовать подходящий дизайн :). Но тем не менее, код всё равно нужно оставлять чистым. пусть Вы используеете статику, не проверяете переменные и так далее — но не нужно всё запихивать в одну 1000-строковую функцию. Вы же через неделю сами там потеряетесь.

                                                                              Очень часто, если Вы проверяли идею, и нашли её плохой, то коллеги захотят перепроверить Ваш код — просто чтоб удостоверится, что Вы проверяли идею правильно. И если Ваш код будет нечитаем — им придётся потратить кучу времени чтоб разобраться в нём. Так зачем такое делать? К тому же, если код будет чистым, Вы сможете использовать если не весь прототип, так его части в рабочем проекте.

                                                                              И да, самое главное — писать чистый код ничуть не медленее чем грязный. А вот работать с ним в дальнейшем — намного быстрее.

                                                                              >>Нет смысла вкладывать в качество того, что может не справиться с задачей, поставленной требованиями.
                                                                              Не в качество, а в понятность и чистоту. Возможно нет смысла, использовать ОРМ для проверки идеи, но если Вы выделите обращения к базе в отдельный «класс» функций/методов — то Вам не захочется повеситься, когда коллега попросит Вас сменить СУБД и повторить эксперемент. Замедлит ли это Вашу работу? Ну, если Вы тратите 90% времени на кодинг — то да. Иначе — разницы Вы не заметите.
                                                                              • –1
                                                                                И да, самое главное — писать чистый код ничуть не медленее чем грязный.


                                                                                Всё же медленнее.

                                                                                Не в качество, а в понятность и чистоту.


                                                                                Никому не нужную в прототипе или эксперименте.
                                                                                • 0
                                                                                  >>Всё же медленнее.
                                                                                  Почему Вы так считаете? Ещё раз обращу внимание — архитектурные изыски и чистота кода — РАЗНЫЕ вещи.

                                                                                  >>Никому не нужную в прототипе или эксперименте.
                                                                                  Самые важные качества эксперимента — достоверность и повторяемость. Без чистого кода проверить это сложно.

                                                                                  И самое главное — писать чистый код даже в самых черновых наработках — так же важно, как и всключать сигнал поворота на пустой дороге: это вырабатывает привычку. И возможно однажды дорога окажется не такой пустой, как Вы думали, а эксперемент — пойдёт в продакшн.
                                                                                  • 0
                                                                                    Почему Вы так считаете?

                                                                                    Один из признаков чистого кода — давать семантические имена переменным, функциям, классам и методам. Над этим надо думать, зачастую в словари лезть, в грамматические справочники и т. п., а в прототипе я просто буду использовать буквы алфавита по порядку :) Это и многие другие подобные вещи отнимают время капля за каплей.

                                                                                    Самые важные качества эксперимента — достоверность и повторяемость.

                                                                                    Эксперимент я имел в виду не в научном смысле слова, а в смысле «научного тыка». Посмотреть, а что будет если…

                                                                                    а эксперемент — пойдёт в продакшн.

                                                                                    Выше я где-то писал, что чтобы исключить это использую различные платформы для прототипов/экспериментов (за редким исключением) и продакшена.
                                                                                    • 0
                                                                                      >>Это и многие другие подобные вещи отнимают время капля за каплей.
                                                                                      Если не секрет, какое соотношение времени для Вас между обдумыванием решения и кодингом?
                                                                                      Знаете, вся эта ерунда про «отнимает время» — просто отговорки. И я их раньше тоже повторял. Пока не нахватался граблей по самое немогу :). Тем более, что подобрать правильное имя для переменной гараздо проще, чем потом вспоминать, как же я там назвал результат выполнения вычеслений — толи CR, толи просто C, толи просто r… особенно в языках типа PHP, где пременную можно создать без предварительного обьявления.

                                                                                      >>Посмотреть, а что будет если…
                                                                                      Но после того, как результат получен — всё таки хорошо бы понять, что результат получен не случайно.

                                                                                      • 0
                                                                                        50/50 где-то на не до конца понятных задачах (эксперименты отношу к кодингу).

                                                                                        У меня просто не бывает «потом» с прототипами. Прототип — что я сделал, как сделал — не важно.
                                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                                  • 0
                                                                                    К сожалению, вы читаете сквозь строки и не хотите прислушаться к тому, что я вам пытаюсь донести. Аспекты независимые, но каждый из них отнимает определенное время. Решение = уровень первого аспекта + уровень второго аспекта. Вот и идет речь о балансе, когда не надо в обоих аспектах добиваться максимума.

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

                                                                                    С кодом прототипа никто работать не будет. В этом и особенность. Именно поэтому и открывается возможность снизить планку качества кода на нем. В вашем примере, если коллега попросит сменить СУБД и повторить эксперимент, то я вынесу эти методы автоматизированными рефакторингами моей IDE. А если не попросит? Зачем тратить на это время? Алгоритм прост: сделал чтобы работало -> проверил идею -> задумался будут ли доработки -> выбросил код или привел в порядок. :)
                                                                                    • 0
                                                                                      >>Вот и идет речь о балансе, когда не надо в обоих аспектах добиваться максимума.
                                                                                      Но ведь без разумного минимума — невозможно, правда? :)
                                                                                      Я к тому, что на самом деле, писать код чисто — не требует вообще дополнительного времени. К тому же, это даёт гарантию что код работает нужным образом а не «как то там работает».

                                                                                      Вот простой пример из жизни: Сделали быстренько рефакторинг функции, чтоб проверить идею. Работает! Потом прадва оказалось, что ничего не работает, данные как брались напрямую из базы, так и продалжали оттуда браться. Просто сервак был незагруженный, и этого небыло видно.
                                                                                      А ведь будь код более читаемым(а не вывод в поток, в перемешку со сбором данных и всё в одной функции) — ошибка была бы видна сразу.

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

                                                                                      Поэтому мой посыл очень прост — если код Вашего прототипа может посмотреть другой человек, и быстро понять его — отлично, всё в порядке. Если для другого человека, становится загадкой, что тут вообще происходит — то наверное с кодом проблемы.
                                                                                      • 0
                                                                                        У Вас достаточно альтернативный подход к понятию «чистоты». Ну вот есть код, смотря на который, я прекрасно понимаю, что он делает, он прост как дважды два. Но в продакшн я его не пущу, поскольку SQL запросы выполняемые из шаблона с потенциальной уязвимостью к инъекциям — это не то, что я называю чистым кодом )
                                                                                        Но для прототипирования — никаких нареканий — нормальный код и даже более приемлемый, чем разнесение его на несколько файлов по две три строки. Хотя в целом, разумеется, всё зависит от целей и конкретного случая.
                                                                                    • 0
                                                                                      Вы используеете статику, не проверяете переменные и так далее — но не нужно всё запихивать в одну 1000-строковую функцию

                                                                                      Почему не нужно? Разница между прототипом и не прототипом — не следование в первом случае ТДД. Т.е. не покрывается тестами и не рефакторится. Поэтому в прототипе, 1000 строк в методе — да без проблем. Если это единственный логический кусок. Лезет напрямую в базу? Да тоже без проблем. Это просто отдельный большой логический кусок.
                                                                                      Фокус в том, что потом рефакторить такой один метод вполне не сложно, если прототип останется. Но разбиение на небольшие методы, и написание тестов — замедляет разработку, хотя не сильно. А если прототип не выстрелит, как идея вообще? Стоит ли тратить время на тесты и на постоянный рефакторинг?
                                                                                      Потом, сам прототип призван что-то показать. Его можно будет оставить, если только он вообще делает что нужно, а не имитирует. Например, я делал прототип. Чтобы не тратить время, хотел набросать быстро на MS-SqlServer. Логично. На SQL можно гораздо быстрее что-то набросать. Задача прототипа — всего лишь увидеть, работает ли предложенная мат-модель на реальных данных или нет. Т.е. дает нужный результат или нет. Оказалась засада — не выдержал сервер работы с деревьями. Хотя, меня скорость совершенно в прототипе не интересовала. Но он как-то совсем не мог работать. Пришлось перенести частично в процедуры на дотнете. Начал прототип дышать и работать.
                                                                                      Но на чистовик нужно было переписывать совершенно другое. Модель только оставить. А само хранение данных, обработка, алгоритмы, — совсем другие.

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

                                                                                      Если уже не хочется тратить время на написание кода два раза, то выбирают функциональный язык, который хорошо работает с любыми данными и позволяет даже в прототипе соблюдать лаконичность кода.
                                                                                      • 0
                                                                                        >>Поэтому в прототипе, 1000 строк в методе — да без проблем.
                                                                                        Проблема в том, что в этих 1000 строках Вы потеряетесь. И если прототип с первого раза не запустится (да, расскажите как Вы пишите 1000 строковые методы без ошибок) — прийдётся удалять, и переписывать всё с начала (О да, и такое было :))

                                                                                        Абсолютно не понимаю Выши рассуждения на тему TDD. Чистый код, можно и нужно писать независимо от того, применяете Вы TDD или нет. Просто если Вы TDD не применяете — возможно код будет содержать больше ошибок. И нужно будет больше потратить время на проверку после рефакторинга.

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

                                                                                        Какие это правила? Читаемые и адекватные названия методов/переменных/классов и так далее, лаконичность функций (попробуйте ограничить размер метода хотя бы 10 строками).
                                                                                        • 0
                                                                                          Я вас вполне понимаю и только за — писать чистый код. И тоже считаю, что это быстро. Также, если сильно долго думать, то код может стать нечистым. Как раз желание писать быстро порождает необходимость в лаконичности.

                                                                                          Но мы про прототипы. Применяю я ТДД или нет — сильно влияет на чистоту. Имею ввиду постоянный рефакторинг. Чтобы соблюдать чистоту, нужно на каждом шаге рефакторить (и как это без тестов делать? с ошибками разве что). Если не рефакторить, то значит «планировать заранее» — а это уже никаким боком не относится к прототипированию. Знали бы, что получится, то не нужно было бы прототип писать.
                                                                                          Рефакторинг замедляет разработку. Может и ускорить местами, поэтому в прототипе тоже делается, но от случая к случаю.
                                                                                          Потом, чистота кода — это немного неоднозначное явление. Из большого метода в 1000 строк легко в нормальном IDE буквально почти мышкой сделать маленькие — повыносить методы, классы и т.д. А вот из порезанного кода не всегда получается перекроить что-то совсем новое. Вы при рефакторинге смотрите не повторяющиеся куски, выносите, думаете, какое имя дать более правильное. Но тем не менее, такое улучшение кода дает увеличение производительности где-то только в перспективе. В близкой перспективе может оказаться, что код, разбитый на куски, имеет неявные зависимости между разными частями. И как только стукнет в голову изменить ход работы прототипа кардинально — сразу возникают проблемы.
                                                                                          Делать методы маленькими, заботиться о чистоте — это хорошо для большого процесса и «ленивого» создания архитектуры. Т.е. в том случае, когда это не прототип и вы имеете время. И после каждого шага любуетесь кодом и сглаживаете неровности.

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

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

                                                                                          А вообще, мы спорим сейчас о двух крайностях. Я с одной стороны (и другие), вы с другой. Да, недорогие рефакторинги можно в прототипе и проводить — менять имена например. С выносом методов не так очевидно. Тоже можно, но так, чтобы не откатываться если что. В прототипировании нет правил — цель — что-то проверить и как можно с меньшими потерями. Качество, количество багов не так интересует, как «показать результат побыстрее».
                                                                                          • 0
                                                                                            Вообще то я не про рефакторинг. Я о том, что бы заранее держать минимально необходимую структуру. Это не сложно, отнюдь.

                                                                                            ПРоблема 1000-строкового метода не в том, что его сложно рефакторить. Проблема в том, что тяжело понять, что там происходит :). да и дописывать его — ещё то удовольствие — приходится постоянно скролить, чтобы вспомнить названия переменных/ключей. И всё это — действительно сильно замедляет разработку прототипа.

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

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

                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.