Привет, Хабр!
Предлагаю вашему вниманию перевод статьи "Simple Hickey" автора Robert C. Martin (Uncle Bob).
Рич Хики выступил с отличной лекцией в «Strange Loop» под названием «Простое, сделанное легко». Я настоятельно рекомендую вам потратить час и послушать её. Это выступление стоит каждой потраченной секунды.
В этой лекции будут некоторые вещи, с которыми вы не согласитесь. Когда это произойдет, остановитесь и подумайте — подумайте серьезно — на самом ли деле вы не согласны. Возможно не стоит думать, что это так.
Например, Рич говорит некоторые, казалось бы, пренебрежительные вещи о TDD и Agile и Refactoring — священных коров Agile Community. Если вы приверженец этого сообщества, вы можете среагировать отрицательно. Не надо. Рич не пренебрегает практикой. Он пренебрегает религией — безрассудством — легкомыслием.
Рич сравнивает модульные тесты с защитными рельсами. Тогда он делает очень хорошее замечание. Он говорит, что, когда у вас есть ошибка, то эта ошибка прошла ваши тесты. И что теперь? Теперь вы должны найти ошибку. И если система не простая, это будет нелегко. (Обратите внимание, что я использовал здесь слова просто и легко. Начало выступления Рича связано с разными определениями, которые имеют эти слова. Я предлагаю вам остановиться на этом месте и послушать первые десять минут его выступления, а затем вернуться к этому абзацу снова.)
Рич подчеркивает, что спринтеры бегают быстро, но не долго. Затем он говорит, что Agile «решил» эту проблему, просто стреляя из стартового пистолета снова и снова в быстрой последовательности. Он ухмыляется, а зрители смеются. Затем он продолжает говорить, что непрерывный спринт не обязательно делает системы простыми, а простота — это ключ к скорости.
Конечно, он прав. Об этом же говорил Мартин Фаулер в своей статье «Flaccid Scrum ». И это то, что многие из нас в Agile сообществе высказывали. Такие короткие итерации без надлежащей технической практики не приводят к быстрому развитию. Скорее, это приводит к беспорядку.
Рич смеется над идеей, что набор тестов позволит вам изменить код. Он говорит, что тесты-это подстраховка, не более того. Мы, TDDers, знаем, что набор тестов необходим, если мы хотим бесстрашно изменить код. Но Рич прав насчет подстраховки. Система безопасности может помочь вам упростить систему, если она уже проста. Но система безопасности под большим комком грязи будет иметь незначительную помощь в распутывании беспорядка. О, не поймите меня неправильно. Мне нужны эти тесты! Но работа будет не из легких. (опять это слово).
Вот еще один доклад от Рича: Hammock Driven Development, в котором он призывает нас думать, а не просто писать кусочки и кусочки кода.
Итак, вот в чем дело. Рич обеспокоен, и это справедливо, тем, что у нас сложилась сложная культура. Когда перед программистами ставится задача, они бегут вперед и пишут массу запутанного кода, используя «простые» фреймворки и инструменты, не придавая проблеме должного значения. Что мы путаем легкость, с простотой. (Например, Rails — это легко, но это не просто.) Его жалоба на тесты состоит в том, что мы использовали их, чтобы заменить мысль. Что нам хорошо, потому что мы написали тесты, но на самом деле мы не уделили достаточно времени проблеме, которой она заслуживает. Мы не упростили проблему. Мы только сделали то, что было легко.
Итак, по правде говоря, сообщество Agile и все сообщество программного обеспечения заражены этой болезнью. Слишком часто мы делаем то, что легко, за счет того, что просто. И поэтому мы устраиваем беспорядок. Но это не является ценностью гибкого развития сейчас и не будет когда-либо. И это, конечно же, не является ценностью мастерства работы с программным обеспечением! Действительно, делать то, что просто, в отличие от того, что легко, — одна из определяющих характеристик мастера программного обеспечения.
В конце концов, я думаю, что восприятие TDD Рича искажено тем, что он видит в отрасли. Честно говоря, я думаю, что он упустил некоторые детали. И я думаю, он бы понял, что эта практика оказалась бы для него такой же полезной, как и для меня. Не как способ избежать размышлений и броситься в беспорядок, а как дисциплинированный способ быть подробным, осторожным и продуманным.
Теперь спросите себя, что для вас значит TDD. Является ли TDD дисциплиной, которую вы используете, чтобы сделать вещи легкими? Или это дисциплина, которую вы используете, чтобы быть вдумчивыми, осторожными и не усложнять?
Предлагаю вашему вниманию перевод статьи "Simple Hickey" автора Robert C. Martin (Uncle Bob).
Рич Хики выступил с отличной лекцией в «Strange Loop» под названием «Простое, сделанное легко». Я настоятельно рекомендую вам потратить час и послушать её. Это выступление стоит каждой потраченной секунды.
В этой лекции будут некоторые вещи, с которыми вы не согласитесь. Когда это произойдет, остановитесь и подумайте — подумайте серьезно — на самом ли деле вы не согласны. Возможно не стоит думать, что это так.
Например, Рич говорит некоторые, казалось бы, пренебрежительные вещи о TDD и Agile и Refactoring — священных коров Agile Community. Если вы приверженец этого сообщества, вы можете среагировать отрицательно. Не надо. Рич не пренебрегает практикой. Он пренебрегает религией — безрассудством — легкомыслием.
Рич сравнивает модульные тесты с защитными рельсами. Тогда он делает очень хорошее замечание. Он говорит, что, когда у вас есть ошибка, то эта ошибка прошла ваши тесты. И что теперь? Теперь вы должны найти ошибку. И если система не простая, это будет нелегко. (Обратите внимание, что я использовал здесь слова просто и легко. Начало выступления Рича связано с разными определениями, которые имеют эти слова. Я предлагаю вам остановиться на этом месте и послушать первые десять минут его выступления, а затем вернуться к этому абзацу снова.)
Рич подчеркивает, что спринтеры бегают быстро, но не долго. Затем он говорит, что Agile «решил» эту проблему, просто стреляя из стартового пистолета снова и снова в быстрой последовательности. Он ухмыляется, а зрители смеются. Затем он продолжает говорить, что непрерывный спринт не обязательно делает системы простыми, а простота — это ключ к скорости.
Конечно, он прав. Об этом же говорил Мартин Фаулер в своей статье «Flaccid Scrum ». И это то, что многие из нас в Agile сообществе высказывали. Такие короткие итерации без надлежащей технической практики не приводят к быстрому развитию. Скорее, это приводит к беспорядку.
Рич смеется над идеей, что набор тестов позволит вам изменить код. Он говорит, что тесты-это подстраховка, не более того. Мы, TDDers, знаем, что набор тестов необходим, если мы хотим бесстрашно изменить код. Но Рич прав насчет подстраховки. Система безопасности может помочь вам упростить систему, если она уже проста. Но система безопасности под большим комком грязи будет иметь незначительную помощь в распутывании беспорядка. О, не поймите меня неправильно. Мне нужны эти тесты! Но работа будет не из легких. (опять это слово).
Вот еще один доклад от Рича: Hammock Driven Development, в котором он призывает нас думать, а не просто писать кусочки и кусочки кода.
Итак, вот в чем дело. Рич обеспокоен, и это справедливо, тем, что у нас сложилась сложная культура. Когда перед программистами ставится задача, они бегут вперед и пишут массу запутанного кода, используя «простые» фреймворки и инструменты, не придавая проблеме должного значения. Что мы путаем легкость, с простотой. (Например, Rails — это легко, но это не просто.) Его жалоба на тесты состоит в том, что мы использовали их, чтобы заменить мысль. Что нам хорошо, потому что мы написали тесты, но на самом деле мы не уделили достаточно времени проблеме, которой она заслуживает. Мы не упростили проблему. Мы только сделали то, что было легко.
Итак, по правде говоря, сообщество Agile и все сообщество программного обеспечения заражены этой болезнью. Слишком часто мы делаем то, что легко, за счет того, что просто. И поэтому мы устраиваем беспорядок. Но это не является ценностью гибкого развития сейчас и не будет когда-либо. И это, конечно же, не является ценностью мастерства работы с программным обеспечением! Действительно, делать то, что просто, в отличие от того, что легко, — одна из определяющих характеристик мастера программного обеспечения.
В конце концов, я думаю, что восприятие TDD Рича искажено тем, что он видит в отрасли. Честно говоря, я думаю, что он упустил некоторые детали. И я думаю, он бы понял, что эта практика оказалась бы для него такой же полезной, как и для меня. Не как способ избежать размышлений и броситься в беспорядок, а как дисциплинированный способ быть подробным, осторожным и продуманным.
Теперь спросите себя, что для вас значит TDD. Является ли TDD дисциплиной, которую вы используете, чтобы сделать вещи легкими? Или это дисциплина, которую вы используете, чтобы быть вдумчивыми, осторожными и не усложнять?
