Уроки, которые я взял на POODNYC

На этой неделе я провел 3 дня в Бруклине, программировал, учился и пил пиво с Сэнди Мец и 30 новыми замечательными друзьями.

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

Погодите, кто такой Санди Мец и что такое POODNYC?

Sandi Metz является автором Практического объектно-ориентированного дизайна в Ruby (ласково именуемого рубистами POODR).

POODNYC был курсом объектно-ориентированного дизайна, который преподавали Сэнди, Авди Гримм (из Ruby Tapas) и Том Стюарт в Нью-Йорке с 31 октября по 2 ноября.

Сэнди и Катрина Оуэн также пишут книгу на основе этих курсов, которая сейчас находится в стадии бета-тестирования: 99 бутылок ООП. Я настоятельно рекомендую прочитать книгу, посетить будущий курс или и то, и другое! 👌

Что я выучил

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

Дублирование - это не ЭТО зло

Программисты очень рано понимают, что дублирование - корень всех зол. Мы учимся сохранять наш код СУХИМ. Не повторяйся - это мантра, которую мы повторяем сами себе.

Итак, мы СУХИМ наш код. И это становится немного труднее понять. Затем появляется требование и - я не знаю, давайте просто вставим туда if/else. ОСУШИТЕ его немного. Потом следующее изменение, и следующее. Боже, эти условные выражения усложняются. Потом больше изменений и косвенных указаний. Более сухой. И ... надеюсь, это ничего не сломает. Почему мне нужно открыть шесть файлов, чтобы понять, что делает этот класс? Подождите, этот модуль только включает три других модуля ?!

Как все пошло так плохо?

«Мы убиваем себя СУШКОЙ слишком рано».

Когда вы СУХИВАЕТЕ свой код, вы берете на себя обязательство абстракции. Мы надеемся торговать простым процедурным кодом, чтобы раскрыть основные концепции и назвать эти идеи. Но если вы недостаточно знаете о своем домене, то ваши абстракции, скорее всего, неверны. В конечном итоге вы теряете понятность без реальной выгоды взамен.

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

Бесстыдный зеленый

Если преждевременная СУШКА вредна, а неправильная абстракция обходится дорого, тогда когда мы отправим наш код?

Когда недостаточно информации, чтобы раскрыть лежащую в основе абстракцию, стремитесь к S безвкусному зеленому. Shameless Green - дешевое решение, дешевое для понимания и дешевое для изменения.

  1. Недорого писать. Ваш код позволяет пройти тесты и не более того. Просто сделайте его зеленым. Он не должен быть умным, СУХИМ или чем-то еще. Писать быстро и легко, и это работает.
  2. Понять дешево: здесь нет необходимости в объектно-ориентированном дизайне. Код простой, понятный и даже процедурный. Не добавляйте сложности, пока это не потребуется. Смысл в том, чтобы максимально поверхностно понять, что происходит, и не беспокоиться о лежащих в основе идеях. Может быть, где-то там есть скрытая концептуальная модель или алгоритм, но если никто об этом не спросит, кого это волнует?
  3. Изменения дешево: О, как мы любим предсказывать будущее, но у нас это плохо получается! Мы предвзяты из-за того, что один или два раза нам повезло, и игнорируем десятки раз, когда мы ошибались. Не ждите изменений. Вместо этого код должен быть хорошей отправной точкой для каждого изменения (если оно вообще произойдет).

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

«Я верю в то, что чувствуется в программировании».

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

Почему мне нужно быть умным?

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

Сложность, которую мы понимаем, заставляет нас чувствовать себя умными. Мы должны быть настолько умными, чтобы создавать из ничего такие сложные системы. Конечно, это чувство эфемерно. Через пару месяцев вы будете набирать git blame, чтобы узнать, кто несет ответственность за такой нечитаемый код, и обнаружите, что это были вы все это время.

Мы боимся выглядеть глупо. Во время проверки кода дублирование - это невысокий плод. Его легко заметить и легко критиковать. Большинство из нас считало, что запрос на извлечение Shameless Green будет полностью разорван на части во время проверки.

«Я думаю, вы были загрязнены DRY».

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

Shameless Green позволяет нам все это обойти. Значит, я могу гордиться дешевым рабочим кодом.

Абстракции найдены, а не созданы

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

«Ваши проблемы не новы!»

Это богатый гобелен знаний, тщательно сплетенный воедино такими людьми, как Мартин Фаулер, Кент Бек, Майкл Фезерс, которые сами стоят на плечах гигантов с такими именами, как Барбара Лисков и Алан Кей. Вместо того, чтобы вытягивать наши решения из одной ткани, мы можем учиться на работе других.

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

Абстракция от возникновения

Итак, как именно найти подходящую абстракцию?

Он начинается с реализации Shameless Green и нового требования - новых знаний о системе. Вы задаете себе два вопроса о текущей реализации:

  1. Открыт ли код для изменений (например, открыто / закрыто)?
  2. Вы знаете, как открыть его?

Скорее всего, ответ будет отрицательным для обоих. Следующий шаг - найти запах кода, который является наиболее простым и понятным, и удалить его с помощью лечебного рефакторинга с небольшими атомарными изменениями. Это повторяется до тех пор, пока вы не ответите «да» на приведенный выше вопрос.

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

Тестирование, когда не нужно

После того, как Сэнди совершил чудо рефакторинга на наших глазах - когда большой, тупой оператор switch волшебным образом сам по себе превратился в узкую неглубокую иерархию наследования - произошел следующий обмен:

Class: "We didn't write any tests. Should we have TDD'd it?"
Sandi: "Yea... I wouldn't test it."
Class: [audible gasps] 😳

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

«TDD накажет вас, если вы не разбираетесь в дизайне».

Тестирование может стимулировать разработку с самого начала при условии понимания требований системы и ее внешнего API. Он может привести вас к Shameless Green и сказать, когда вы закончите. Когда вы проведете рефакторинг, он будет вам полезен.

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

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

Это лишь некоторые из уроков, которые я извлек из опыта Сэнди, Авди и Тома в POODNYC. Есть также множество других советов и интересных моментов по объектно-ориентированному программированию, тестированию и рефакторингу, о которых я надеюсь написать в будущем.

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

В общем, потратить несколько дней на то, чтобы пообщаться в Бруклине, завести новых друзей и получить бомбы знаний, стоило того.

🤔 💣 😵