Разработка, основанная на разочаровании — Навстречу DevOps, Lean, Clojure

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

Итак, как это относится к DevOps, непрерывной доставке, тестированию, единичному потоку, Lean Startup, Clojure? Это просто.

Build It Fast

Я забочусь о DevOps и Continuous Delivery, потому что они направлены на то, чтобы выпустить мои вещи как можно скорее. Я люблю строить и грузить, использовать его сразу после окончания. Сидя в очереди за работой — для проверки кода, тестирования, развертывания — это разочаровывает. Я хочу закончить, увидеть, как он работает, используется и работает хорошо, и убрать это из головы, чтобы я мог сосредоточиться на следующей вещи с ясным разумом. Вот почему также цельный поток звучит так привлекательно для меня. Если моя работа не развернута, не использована и, следовательно, подтверждена, что она в порядке и полезна, она не завершена. Это может вернуться из-за дефектов, и у меня нет никаких доказательств того, что это действительно стоило. Недостаток удовольствия, приносящего пользу и ценность, и умственной утраты наличия множества незаконченных вещей (см. Эффект Зейгарника ) разочаровывает.

Построить правильную вещь

По той же причине я забочусь о пользователях и создаю правильные вещи , то есть то, что они на самом деле будут использовать и извлекать выгоду, и в то же время делаю его максимально удобным для пользователя. Тесный контакт с пользователями / бизнесом, A / B-тестирование и другие методы Lean Startup, мониторинг пользователей — это некоторые из отличных инструментов и практик, которые помогают нам гарантировать, что мы действительно строим правильные вещи. Я очень скептический человек. История много раз показывала, что мы ужасно предсказываем, что нужно / нужно пользователям, поэтому я не верю в ценность продукта, пока не увижу данные, которые это подтверждают. Как сказала знаменитая Мэри Поппендик: «Покажи мне деньги!» Я убежден, что развитие — это прежде всего открытие — как ценное (для пользователей), так и техническое (проблемы и решения). Степень неопределенности может варьироваться, но она всегда есть. Огорчительно видеть, что проекты слепо следуют курсу, установленному «всезнающим» заинтересованным лицом / PM / архитектором.

Построить это правильно

Я также очень беспокоюсь о тестировании, TDD и «качестве сборки» в Lean. Я хочу донести плоды своей работы до пользователей, чтобы улучшить их жизнь как можно скорее, а затем удалить их из моего мозга. Но дефекты заставляют его возвращаться. Поэтому без хорошего качества я никогда не узнаю, закончил ли я на самом деле или нет. Переключение контекста и повторная загрузка предыдущей работы в мою голову психически утомительны . Кроме того, мне не нравятся этапы тестирования и заморозка кода, они являются препятствиями — не просто камнями, но горами — на пути от кода к значению. Следовательно, хорошее качество встроенных автоматических тестов и все методы непрерывной доставки имеют решающее значение.

Я жажду улучшения жизни людей (пользователей). Я хочу получить удовлетворение от этого моего препарата часто и быстро. Борьба с устаревшим кодом спагетти замедляет меня. Поэтому я забочусь о хорошей и простой архитектуре и дизайне (DRY, SRP и все такое). Я забочусь о рефакторинге; настоящий профессионал стремится к долгосрочному устойчивому быстрому развитию и быстрым исправлениям. Я слишком часто был в плохом конце: «Давайте взломать это быстро сейчас и заплатить цену позже».

Используйте лучшие инструменты

Моя любовь к созданию ценности для пользователей также объясняет, почему я перерос в неприязнь к Java и к Clojure (хотя это можно обобщить и на другие языки, например C # и F #). В Java очень бесполезно повторять себя из-за слабых абстракций и писать кучу шаблонного кода (все эти методы получения, компараторы и т. Д.). Clojure гораздо более мощный , с абстракциями, которые позволяют легко «сказать что-то один раз» таким как функции высшего порядка и мультиметоды, и податлив, чтобы соответствовать проблеме под рукой, как перчатка (благодаря макросам и т. д.). Java, с другой стороны, заставляет меня приспосабливать проблему к языку и писать множество шаблонного кода. Кроме того, в Clojure REPL обеспечивает действительно интерактивную и исследовательскую разработку с чрезвычайно коротким циклом обратной связи и, таким образом, помогает мне двигаться быстро. Мой любимый пример дихотомии Clojure-Java — это работа по сокращению карты, написанная с использованием библиотеки Clojure Cascalog, по сравнению с тем, как она выглядела бы в простой Hadoop Java. (Это небольшое сравнение с грушами и яблоками, но демонстрирует смысл 90% бизнес-кода против 90% стандартного кода ).

По тем же причинам, когда мне приходится использовать фреймворк или библиотеку, я предпочитаю тот, который на самом деле делает мою жизнь проще и не заставляет меня постоянно бороться с ней. (Так что нет JSF.)

Люди тоже важны

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

Несколько исторических примеров

Project Gnomes: Это был технически отличный проект с DevOps, полным контролем над всем, частыми выпусками. Все же это расстроило меня, потому что я не верил в ценность создаваемого продукта.

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

Почему бизнес должен заботиться?

Бизнес заботится о зарабатывании денег, а не о том, чтобы сделать меня счастливым. Так почему они должны заботиться о моем разочаровании? Почему они должны заботиться о том, чтобы начать получать прибыль от ИТ как можно скорее? О проверке того, что вложение ИТ-ресурсов действительно того стоит? О том, как избежать дефектов и простоев (а также потерянных клиентов и продаж)?

Эмм, мне нужно ответить?

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

Резюме

Для меня развитие — это, по сути, максимизация стоимости <=>, минимизация времени от идеи до «наличных». Это естественным образом приводит к DevOps, непрерывной доставке, методам бережного запуска и мышлению, «формированию качества», цельному потоку, и это определяет мой выбор инструментов и языков.

Психологически речь идет о максимизации удовольствия при одновременной минимизации умственной утечки, т. Е. Расходования умственной энергии.