Принципы — вечны, практики — иллюзорны

Есть большая разница между принципом и хорошей практикой.

Лучшие практики — субъективны и зависят в основном от контекста, в то время как принципы — вечны и универсальны.

После написания статьи «Чем больше я знаю, тем меньше я знаю» (англ.), я получил несколько писем о том, что существуют некоторые практики, которым нужно следовать абсолютно в любом процессе разработки ПО.

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




Взглянем-ка на некоторые лучшие практики


Для начала давайте посмотрим на некоторые лучшие практики в разработке ПО, а потом сравним их с принципами для большего понимания идеи.

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

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

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

Но вместо того, чтоб спорить где юнит тесты имеют наименьшую ценность, давайте лучше поговорим о том, где они имеют наибольшую ценность. В этом вопросе мы быстрее сойдемся.

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


Существует куча других хороших практик, например комментирование как документация к коду или же документирование с помощью UML диаграмм, но в них контекст все так же играет роль в определении ценности этих практик.

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

Но большинство лучших практик действительно хороши!


Да, вы правы, большинство лучших практик действительно широко применимы и полезны в большом количестве контекстов.

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

Это ли не конкретное правило или принцип?

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

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

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

Проблема в том, что использование практик вовсе не гарантирует вам пользу от принципов, лежащих в их основе.

Все больше и больше я встречаю команды, которые:
  • Пишут юнит тесты
  • Используют continuous integration
  • Используют системы контроля версий
  • Проводят Scrum митинги
  • Практикуют парное программирование
  • Используют IoC контейнеры

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

Эффективна не практика, а принцип, лежащий в ее основе


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


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

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

Возьмем к примеру «закон урожая». Большинство людей знакомы с этим принципом. В общем, он звучит как:

--> Что посеешь, то пожнешь <--


Насколько универсальна эта истина? Можно ли избежать этого принципа? Как часто вы участвовали в ситуации с этим неизбежным законом?

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

TDD (или для незнающих Test Driven Development) — действительно замечательная практика. Базовый принцип TDD — ввести качество в процесс разработки как можно раньше, в результате чего окончательный продукт получается лучше.

Если вы применяете TDD без понимания его принципов, вы просто симулируете TDD без получения какой-либо выгоды.

Если вы не можете понять на каком-то уровне, что смысл TDD в посеве хороших зерен, которые вы потом пожнете позднее, то вы не сможете написать хороших тестов.

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

Вот почему я люблю книгу Боба Мартина «Принципы, паттерны и методики гибкой разработки на языке C#», он рассказывает о многих принципах в разработке ПО, которые вечны. Книги вроде этой и книга, которую я упомянул раз 10 в своем блоге «Как заводить друзей и влиять на людей» полны принципами.

По сути, я вам сейчас рассказал, что же такое Agile. Думая о принципах, можете почитать Agile манифест. Он никогда не рассматривался как подробное описание процесса разработки или же список лучших практик, скорее как признание набора принципов, которые руководят процессом разработки.

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

Источник: agile.dzone.com/articles/principles-are-timeless-best
От переводчика: извиняйте, опубликовать в хаб «Переводы» не получилось, не хватило принципа на букву «К».
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 10
  • 0
    Ну да, народ часто пытается решить проблему «Как?», хотя не думают о «Зачем?».
    Хотя статья (не перевод), на мой взгляд, бестолковая — ожидал большего, когда ставил в закладки.
    • –1
      Я в общем-то понимаю, что ничего нового не рассказывает статья, но проблема в том, что до многих не доходит с первого раза, поэтому надо брать измором. Чем больше расскажешь об одном и том же, тем быстрее поймут. Вся реклама на этом принципе и держится :)
    • +1
      Что посеешь, то пожнешь

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

          Да, я не спорю, что помогают, но далеко не всем. Многие будут выполнять практики «потому что им сказали». Сам таким страдал, когда джуниором еще был. Ну сказали старшие, значит так правильнее, и старшие не удосуживались обьяснять толково.
          • 0
            У многих джуниоров (а также иногда просто у упрямцев :) ) есть тенденция отрицать практики. Ну типа «Комментарии — для тех кто не умеет программировать! У меня код чистый и я и так всё помню!». С этим иногда приходится бороться.

            С другой стороны, мне хочется, чтобы джуниоры учились думать самостоятельно, и не боялись оспорить мои мнения. Поэтому я говорю им: делаем так-то и так-то, поскольку во-первых это правильно (следует объяснение), а во-вторых, потому что я говорю, что так надо. Хочешь делать по-другому? Переубеди меня.

            Иногда переубеждают :)
            • 0
              Хе, у меня наоборот была тенденция заоверинженирить все вокруг. Просто исходя из личной выгоды, чтоб выучить технологию, а не принести пользу проекту.
        • 0
          Ну да, так тоже бывает :) И что самое смешное — одно другому не мешает. Классика — использовать модные технологии, но комментарии при этом не писать, поскольку лень и неинтересно :)
          • 0
            А вот мне интересно было, если я понимал, что это модно. Всякие StyleCop, FxCop любил.

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

          Самое читаемое