Есть большая разница между принципом и хорошей практикой.
Лучшие практики — субъективны и зависят в основном от контекста, в то время как принципы — вечны и универсальны.
После написания статьи «Чем больше я знаю, тем меньше я знаю» (англ.), я получил несколько писем о том, что существуют некоторые практики, которым нужно следовать абсолютно в любом процессе разработки ПО.
Я давно хотел написать про принципы, и вот вышесказанное заблуждение дало мне ясно понять, что необходимо четко понимать разницу между принципами и практиками. Мы не хотим выливать воду из ванной вместе с ребенком.
Для начала давайте посмотрим на некоторые лучшие практики в разработке ПО, а потом сравним их с принципами для большего понимания идеи.
Одна из наиболее популярных практик это конечно же юнит тестирование. Я уже писал про свои сомнения (англ.) насчет того, что нужно слепо следовать лучшим практикам, но должны ли мы им следовать или нет (англ.) это не то, что я хочу рассказать сейчас.
Юнит тестирование зависит от контекста. Что я подразумеваю под этим, это что каждый согласится, что существует некий набор обстоятельств, который дает ценность юнит тестированию.
Если вы работаете в среде, где юнит тесты забирают много времени на выполнение, или же у вас waterfall подход, при котором вы имеете длинный список того, что необходимо реализовать с подробными требованиями, то в этих условиях юнит тесты начинают терять свою ценность.
Но вместо того, чтоб спорить где юнит тесты имеют наименьшую ценность, давайте лучше поговорим о том, где они имеют наибольшую ценность. В этом вопросе мы быстрее сойдемся.
Юнит тестирование имеет наибольшую ценность в гибких методологиях, с быстрыми и частыми изменениями в требованиях к разрабатываемому продукту и частым рефакторингом. Также его польза возрастает, когда есть возможность действительно быстрого написания и выполнения тестов, потому что эта обратная связь облегчает итеративный процесс написания тестов, что особенно важно в TDD.
Существует куча других хороших практик, например комментирование как документация к коду или же документирование с помощью UML диаграмм, но в них контекст все так же играет роль в определении ценности этих практик.
Когда большинство разработчиков называли переменные и методы короткими названиями, тогда комментирование такого кода было важно. Пока agile практики не стали преобладающими, было критичным предоставление детальных требований к продукту до начала его разработки.
Да, вы правы, большинство лучших практик действительно широко применимы и полезны в большом количестве контекстов.
Например, считается хорошей практикой пользоваться системами контроля версий, и сложно представить себе ситуацию, где это могло бы навредить.
Это ли не конкретное правило или принцип?
Нет, оно все еще слишком специфично, чтоб применять его во всех случаях и факт нахождения вашего кода в системе контроля версий не делает ничего для улучшения вашего продукта.
Если бы вы следовали лучшим практикам, но не открывали бы принцип лежащий в их основе, вряд ли вы бы получили с этого какую-либо пользу.
Дело в том, что большинство лучших практик происходят из универсальных применимых принципов, которые никогда не меняются. Поэтому большинство таких практик и лучшие.
Проблема в том, что использование практик вовсе не гарантирует вам пользу от принципов, лежащих в их основе.
Все больше и больше я встречаю команды, которые:
Но они получают выгоду от этого стремящуюся к нулю. Всего лишь больше головной боли и лишних телодвижений. А причина проста…
Принципы везде. Мы их встречаем везде и всегда в своей жизни. Вы не сможете прожить и дня, чтоб не столкнуться раз 100 с различными принципами, которые влияют на вашу жизнь, например закон притяжения.
Гравитация — отличный пример для понимания принципов. Насколько нам сейчас известно, это универсальная сила, которая действует всегда и везде. Невозможно избежать гравитации, куда бы вы ни попали, она там будет и будет действовать на вас.
Принципы — это как законы природы, только еще шире. Принципы скорее можно назвать законами реальности. Может быть вы даже не можете полностью описать их или же понять как они работают, но они всегда работают.
Возьмем к примеру «закон урожая». Большинство людей знакомы с этим принципом. В общем, он звучит как:
Насколько универсальна эта истина? Можно ли избежать этого принципа? Как часто вы участвовали в ситуации с этим неизбежным законом?
Многие лучшие практики в разработке ПО базируются на этом принципе. Подумайте о лучших практиках, которые заставляли вас прилагать усилия для улучшения вашего продукта на ранних стадиях.
TDD (или для незнающих Test Driven Development) — действительно замечательная практика. Базовый принцип TDD — ввести качество в процесс разработки как можно раньше, в результате чего окончательный продукт получается лучше.
Если вы применяете TDD без понимания его принципов, вы просто симулируете TDD без получения какой-либо выгоды.
Если вы не можете понять на каком-то уровне, что смысл TDD в посеве хороших зерен, которые вы потом пожнете позднее, то вы не сможете написать хороших тестов.
Нет ничего сложного в написании тестов перед кодом, но есть кое-что ценное в намеренном инвестировании в первичное качество продукта, с конечной идеей собирания большего урожая от этого инвестирования в нужный сезон.
Вот почему я люблю книгу Боба Мартина «Принципы, паттерны и методики гибкой разработки на языке C#», он рассказывает о многих принципах в разработке ПО, которые вечны. Книги вроде этой и книга, которую я упомянул раз 10 в своем блоге «Как заводить друзей и влиять на людей» полны принципами.
По сути, я вам сейчас рассказал, что же такое Agile. Думая о принципах, можете почитать Agile манифест. Он никогда не рассматривался как подробное описание процесса разработки или же список лучших практик, скорее как признание набора принципов, которые руководят процессом разработки.
Так что не забывайте, когда будете спорить с кем-либо по поводу лучших практик или думать включать ли какую-либо практику в свой проект, то если вы не понимаете принципа, на котором практика базируется, то никакое количество обрядов, процедур, танцев с бубнами из этой практики вам не поможет.
Источник: agile.dzone.com/articles/principles-are-timeless-best
От переводчика: извиняйте, опубликовать в хаб «Переводы» не получилось, не хватило принципа на букву «К».
Лучшие практики — субъективны и зависят в основном от контекста, в то время как принципы — вечны и универсальны.
После написания статьи «Чем больше я знаю, тем меньше я знаю» (англ.), я получил несколько писем о том, что существуют некоторые практики, которым нужно следовать абсолютно в любом процессе разработки ПО.
Я давно хотел написать про принципы, и вот вышесказанное заблуждение дало мне ясно понять, что необходимо четко понимать разницу между принципами и практиками. Мы не хотим выливать воду из ванной вместе с ребенком.
Взглянем-ка на некоторые лучшие практики
Для начала давайте посмотрим на некоторые лучшие практики в разработке ПО, а потом сравним их с принципами для большего понимания идеи.
Одна из наиболее популярных практик это конечно же юнит тестирование. Я уже писал про свои сомнения (англ.) насчет того, что нужно слепо следовать лучшим практикам, но должны ли мы им следовать или нет (англ.) это не то, что я хочу рассказать сейчас.
Юнит тестирование зависит от контекста. Что я подразумеваю под этим, это что каждый согласится, что существует некий набор обстоятельств, который дает ценность юнит тестированию.
Если вы работаете в среде, где юнит тесты забирают много времени на выполнение, или же у вас 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
От переводчика: извиняйте, опубликовать в хаб «Переводы» не получилось, не хватило принципа на букву «К».
