Мысли вслух про качественный код, рефакторинг, 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 automation axum babel bash benchmark blog blog-engine bootstrap buildout c# cache centos chrome ci cinder ckan cli cloud code-review codeplex community config debugger deface dependencies development-environment devices devstack devtime disks django dlr dns docker dockerimage dos easy_install elmah encoding environment-variables error event events everything-as-a-code exception exceptions fabrik firefox flask foreach forms fstab gae gcc gerrit git github go google google-app-engine grep hack hacked hardware headless horizon hound html hugo iaas ienumerable iis internet iptables iron-python ironic iscsi java-script javascript jenkins jquery js jsx kharkivpy kiss kombu kvm kyiv lettuce libvirt linux lio loci logging loopback losetup lvm mac-os macos mercurial microsoft microsoft-sync-framework mobile mono ms-office msbuild networking news nginx npm npx offtopic oop open-source open-xml opensource openstack openvswitch os packages paraller-development patterns-practices performance php pika pip plugins pnp podcast popup postgresql profiler project protocols proxy pycamp pycharm pycon pykyiv pylint pypi python python-3 qcow quantum qumy rabbitmq rar react reactjs refactoring rfc rhel search-engine security selenium server shell silverlight socket software-engineering source-control sourcegear-vault sources sql sql-server sql-server-express sqlalchemy ssh static-site sublimetext svg tests tgt tipfy tornado typescript uapycon ui uneta unit-tests upgrades usability vim virtualenv visual-studio vitrage vm vue.js vuejs web-development web-server web-service web_root webpack webroot windows windows-live word-press x32 x64 xcode xml xss xvfb интернет-магазин книги


Archives

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