Споры по поводу качества кода никогда не прекращались. Все знают, что код должен быть качественным, но что такое качественный код никто точно сказать не может. По моему мнению - это достаточно субъективное понятие, которое зависит от многих факторов. Такими факторами могут быть: читабельность, наличие комментариев, количество изменений, необходимых для реализации новых фич и/или фиксов багов. Немаловажную роль играет и проект, который находится в разработке: в одном что-то может считаться отличным кодом, а в другом - этот же код будет просто ужасным. Но я хотел поговорить немного о другом...

А должны ли мы всегда писать код, который можно назвать качественным? Я считаю что нет. И прежде, чем что-то возразить, выслушайте меня до конца.

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

  • время создания прототипа должно быть минимальным;
  • желательно, весь код прототипа выкинуть и не использовать в готовом продукте;
  • для достижения предыдущего пункта прототип можно писать на другом языке программирования (например, вы пишете на C#, а прототип - на Java или Python).

Исходя из вышесказанного принципа, становится понятно,что в таком прототипе просто не может быть “качественного кода”, но такой код/подход всё-равно будет очень полезным. Главное, не забыть избавится от кода прототипа в финальном варианте.

Посмотри теперь что нам предлагает методология XP: постоянный рефакторинг, постоянное написание тестов перед написанием кода (TDD - Test Driven Develepment), быстрое создание архитектуры. При таком на первых стадиях/итерациях проекта невозможно добиться качественного кода. Код будет рабочим (привет TDD), но будет ли он качественным? Не всегда. А постоянный рефакторинг? Это ещё один признак того, что код не идеален. Только не сделайте вывод, что если применять XP - не получится писать качественный код. Просто надо понимать, что это самое качество будет всегда повышаться благодаря рефакторингу и unit-тестам.

Всё вышесказанное больше похоже на теорию. А как у нас обстоят дела на практике?

А практика нам показывает, что писать так хорошо, как нам хочется, не всегда можно. Сразу оговорюсь, я имею в виду написание кода на работе: мы пишем код (делаем свою работа), нам платят за это деньги. Программирование, в большей степени - это бизнес. А как известно в бизнесе: время - деньги. У кого не было ситуации, когда прибегает Project Manager или заказчик и требует что сделать эту фичу / пофиксить этот баг нужно было ещё вчера. В лучшем случае - не вчера, но через два часа всё должно быть готово. И кто в таком случае будет думать об архитектуре и качестве кода? Нужно смотреть правде в глаза: в таких случаях всем ясно, что главное выполнить требование, а качество уходит на задний план. Мы поставим комментария вида “TODO: refactor it after …” и отправим код в репозитарий. А что будет дальше с этим кодом - это уже отдельная история.

Ещё, как пример из практики, хочу привести такой случай: команда получила на аутсорс проект, который до этого разрабатывался другой командой разработчиком. У другой команды могут быть другие критерии качества кода, банально, может быть другой профессиональный уровень. Но вы ведь не будет переписывать все? Такое желание есть, но нет возможности: заказчик не выделяет на это времени, денег, говорит что этот код ещё саппортится его разработчиком и поэтому всё должно быть именно так, как есть. Вот и приходится писать в том же стиле, в котором написан проект или пытаться дописывать новые вещи уже по своим стандартам качественного кода...

Подводя итог скажу следующее:

Я не призываю вас писать некачественный код. Я, всего-лишь, призываю вас смотреть правде в лицо: говонокод пишут все. Некоторые больше, некоторые меньше. Всё дело в том, что бывают ситуации, когда это нужно. Главное, не делать этого всегда.


Comments

Slava Russia

Sunday, December 5, 2010 3:42 PM

Slava

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

Restuta Ukraine

Friday, December 10, 2010 2:14 AM

Restuta

Экий холивар ты затеял =)

Прототипирование
Я признатся никогда не учавствовал в подобном. Т.е. в написании прототипа на одном языке и приложения на другом. Мало представляю как это возможно в рамках одной команды. Я не могу быть равно-производительным на двух платформах. Хотелось бы всё таки узнать источник, где ты это прочитал.

XP
"При таком на первых стадиях/итерациях проекта невозможно добиться качественного кода." - согласен, но заложена основа для его _безопасного_ улучшения. И как ты подметил оно идёт постоянно, а это залог успеха, наверное эволюция своего рода. Ничего ведь не создаётся сразу. XP is all about constant improvement.

Профессионализм
"но через два часа всё должно быть готово. И кто в таком случае будет думать об архитектуре и качестве кода?"  - здесь я всегда провожу такую аналогию: "К врачу прибегают и говорят, нужна срочная операция или пациент умрёт, на что он отвечает: "Хорошо, только мне нужно вымыть руки и одеть перчатки..." Ни за что на свете врач не выполнит операции не вымыв руки и без перчаток, иначе он может угодить в тюрьму, погубить пациента. Почему же я как разработчик должен поступать непрофессионально? Потому что мне не угрожает уголовная ответственность? Потому что я не рискую жизнью человека? А чем я рискую? По большому счёту, задача, которую можно сделать за 2 часа не требует особых размышлений и архитектурных решений, а лишние 20 минут (или боже упаси час) потраченные на написание хорошего кода позволят сохранить лицо.

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


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

e0ne United States

Friday, December 17, 2010 12:45 AM

e0ne

Наконец-то добрался до блога. Постараюсь дать как можно более развернутые ответы.

Slava, отличное уточнение, это именно то, что я имел в виду! Smile

Restuta, комментарий тянет на отдельный пост или, минимум, на хороший холливар Smile.

На счет источника идеи о прототипировании я не ошибся - С.Макконнелл, "Совершенный код". У меня бумажная версия русского издания. Глава 5 "Проектирование при конструировании", раздел 5.4 "Методики проектирования", подраздел под названием "Эксперементальное прототипирование" (http://cc2e.com/0599). К сожалению, прототипирование на другом языке еще не приходилось применять. Использовал только быстрое прототипирование на том же языке, на котором пишется проект с последующим выбрасыванием кода прототипа - иногда помагает, если сильно не увлекаться разработкой прототипа.

Про  ХР полностью согласен и считаю данный подход одним из главных преимуществ методологии.

Лично мне не нравятся аналогии с другими професиями - программирование, на мой взгляд, слишком отличается от других. Да, оно, частично, похоже на другие инженерные дисциплины, но прямые аналогии, imho, не корректны. Иногда просто нет лишних 20 минут, не говоря уже о часе-другом. Когда код в production или перед отгрузкой его заказчику нашли баг, который полностью ломает всю работу приложения и можно забить гвоздь с пометкой "TODO: refactor after release", то далеко не каждый менеджер готов/может принять решение отложить "релиз" на 20 минут, час, день или неделю. Время - деньги. И с этим ничего не сделаешь.

"Смена работы/команды" - это, конечно, решение проблемы, но очень радикальное, не всегда подойдет.

"со всей ответственностью заявляю - я его никогда не пишу" - могу сказать что тебе очень повезло. Были бы у всех такие проекты/команды/менеджеры - были бы все щасливы Smile. Мне с текущем проектом повезло меньше.

Comments are closed