Мысли вслух про качественный код, рефакторинг, TDD и немного XP

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

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

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

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

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

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

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

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

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

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

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

Tags

.net .net-framework .net-framework-3.5 agile ajax ajax-control-toolkit ampq ansible apache asp.net asp.net-mvc axum bash benchmark blog blog-engine bootstrap buildout c# cache centos chrome ci cinder ckan cli cloud codeplex community debugger deface development-environment devstack devtime django dlr dns docker dockerimage dos easy_install elmah encoding environment-variables error event events exception exceptions fabrik firefox foreach forms gae gcc git github go google google-app-engine hack hacked hardware headless horizon html hugo iaas ienumerable iis internet iptables iron-python ironic iscsi java-script javascript jenkins jquery js kharkivpy kombu kvm kyiv lettuce libvirt linux lio loci logging mac-os mercurial microsoft microsoft-sync-framework mobile mono ms-office msbuild networking news nginx offtopic open-xml opensource openstack openvswitch os packages paraller-development patterns--practices php pika pip pnp podcast popup postgresql profiler project protocols pycamp pycharm pycon pykyiv pylint pypi python python-3 qcow quantum qumy rabbitmq rar react refactoring rfc rhel search-engine security selenium server shell silverlight socket source-control sourcegear-vault sql sql-server sql-server-express sqlalchemy ssh svg tests tgt tipfy tornado typescript uapycon ui uneta unit-tests usability virtualenv visual-studio vm vue.js vuejs web-development web-server web-service webpack windows windows-live word-press x32 x64 xcode xml xss xvfb интернет-магазин книги

Recent posts

Docker Image Collection

Not a DNS Server for Libvirt

Diskimage-builder in Docker

Everything as a Code

Vue.js, global variables and TypeScript


Archives

2019 (19)
2018 (2)
2017 (3)
2016 (2)
2015 (3)
2014 (5)
2013 (17)
2012 (22)
2011 (35)
2010 (25)
2009 (35)
2008 (32)
2007 (2)