0,0
рейтинг
1 февраля 2013 в 13:08

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

Думаю, никто не будет спорить, что программный код должен быть чистым и «не пахнуть» (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, что ввело в ступор начальство (ну и меня тоже, т.к. сдавать продукт нужно было мне). Но за счет контроля с самого начала проекта все доработки заняли максимум день.

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

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

Спасибо за внимание и белоснежного вам кода!
Краковецкий Александр @sashaeve
карма
435,2
рейтинг 0,0
CEO DevRain Solutions
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (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
    «Заставьте себя написать хотя бы один проект «правильно», и потом вы просто не сможете это делать по другому ;-)»
    Голая правда!
  • +2
  • +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
      Истину глаголите
  • 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 часа, после чего его удаляем, и результат для коллектива не принципиальный — то можно делать как угодно — за это время особо не наговнакодите. Ну всмысле — совсем уж страшно.

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

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