В июле EuroPython 2013 прошел во Флоренции, Италия, в третий раз подряд. Немного о себе: я итальянец и программист на Python, поэтому мне очень приятно поделиться своим опытом участия в EuroPython. У Python замечательное сообщество, состоящее из одних из самых умных и вдохновляющих людей в индустрии ИТ. После участия в этом сообществе семь лет, я могу честно сказать, что конференции Python – это всё о людях. Именно люди делают это сообщество великим.
Одним из таких вдохновляющих людей является Алекс Мартелли, старший инженер компании Google и член Фонда программного обеспечения Python. В этом году он презентовал основной доклад на EuroPython под названием “Достаточно хорошо” это достаточно хорошо! или, как он сказал, цитируя Ричарда Габриэля: подход Нью-Джерси, также известный как “Хуже – это лучше” против “подхода Массачусетского технологического института/Стэнфорда, также известного как “Правильное решение”. Я не был уверен, о чем он будет говорить, но название было интригующим. И одно, чему я научился из докладов Мартелли за последние семь лет, это то, что когда он говорит, лучшее, что вы можете сделать, это слушать, учиться и делать заметки. И это именно то, что я и сделал.
Доклад рассмотрел два разных подхода к выпуску программного обеспечения. Первый, “Правильный подход”, рекомендует стремиться к совершенству (соглашаться на выпуск программного обеспечения, которое ниже уровня “идеального”, считается нежелательным компромиссом). Второй, “Хуже — это лучше”, говорит о том, чтобы держать всё просто, достаточно хорошо, запускать рано, часто выпускать обновления, получать много отзывов (это “подход Нью-Джерси”, потому что Unix — хороший пример, и он был написан в Нью-Джерси).
Martelli объяснил, как Ричард Гэбриел определил четыре основных ценности, которые общие для обоих подходов: простота, корректность, согласованность и полнота. Он продолжил объяснение тем, что действительно важно, это приоритет, отдаваемый этим ценностям. Выводы Гэбриела можно резюмировать этими двумя цитатами:
Философия правильного подхода основана на том, чтобы позволить экспертам делать свою экспертную работу
продвигать вещь до конца, прежде чем пользователи получат к ней доступ.
Worse-is-better использует естественные преимущества инкрементного
разработка. Постепенное улучшение удовлетворяет некоторые потребности людей…
Он пошел еще дальше, указывая на то, что интерпретация Габриеля близка к тому, что описал Эрик Рэймонд в своей книге «Собор и базар», в которой он описал две различающиеся модели разработки программного обеспечения: собор, где всё контролируют эксперты и где основное внимание уделено работе экспертов, в отличие от базара, который является продуктом коллективной работы и хаоса, где власть в руках толпы, включая людей, которые непосредственно участвуют в процессе, но также и тех, кто просто помогает, потому что им нужен продукт базара для выполнения несвязанных задач.
Очевидно, что Рэймонд фокусировался на ошибках и считал, что миллион глаз ускорит процесс обнаружения ошибок – и в этом вся суть. Чтобы миллион человек смотрел на это, нужно выпустить код. Нужно вывести его в реальный мир и дать людям им пользоваться. Как сказал Мартелли, если вы хотите выпускать только «Совершенство», если вы хотите, чтобы эксперт занимался экспертными вещами, тогда вам нужен «Большой Дизайн на Переднем Плане», идеальное определение требований, идеальная архитектура, идеальный дизайн, идеальные реализации и т.д. И это займет вечность! Но что еще более важно, реальная жизнь обычно не сотрудничает.
Перефразируя Мартелли, «Реальная жизнь не склонна сотрудничать». Требования меняются, а вместе с ними и архитектура, дизайн и реализация. Итеративная разработка — это путь к успеху. Разверните что-то, исправляйте ошибки, совершенствуйтесь, используйте системы контроля версий, код-ревью, стиль кодирования, тестирование (если вы не тестируете, вы рискуете) и, наконец, четко документируйте все, что вы сделали.
Это не означает, что мы должны снижать свои ожидания. Как указал Мартелли, «наша мечта должна оставаться великой, но лучший способ достичь этих мечтаний — это ранний и частый выпуск». Он продолжил, приводя примеры идеальных архитектур, которые так и не были реализованы, выпущены или проиграли битву своим несовершенным соперникам, включая Xanadu против WWW, TCP/IP против ISO/OSI, MIT ITS против UNIX.
Видео ключевого доклада длится около часа, но я настоятельно рекомендую всем, кто занимается разработкой программного обеспечения, посмотреть его. Даже если вы не согласны с выводами, это отличный источник информации. Запись ключевого доклада: http://www.youtube.com/watch?v=gHG9FRSlPxw
Мой главный вопрос после презентации был: «Когда «достаточно хорошо» действительно достаточно хорошо?» Когда наступает этот момент, когда вы находитесь в середине процесса разработки, когда можно сказать: «Пора!» К счастью, ответ на мой вопрос уже содержался в презентации Мартелли, просто ожидая, чтобы его заметили.
Подсказка: вот отрывок из статьи Эрика Риса, автора книги «Бережливый стартап», Достаточно хорошо никогда не бывает (или бывает?). Это его определение «минимально жизнеспособного продукта».
“Минимально жизнеспособный продукт — это версия нового продукта, которая позволяет
команда для сбора максимального количества проверенных знаний с минимальными усилиями.
Вот оно! Вот ответ, который я искал. Реализуйте что-то, что улучшит жизнь кого-то, что-то, что решит реальную проблему мира. Сделайте это, как только это будет в состоянии, позволяющем вам и вашей команде учиться на реальных взаимодействиях с пользователями, собирать реальные данные и получать реальные отзывы. Научитесь справляться с тем фактом, что пользователи живут в реальном мире – и этот мир несовершенен. Но альтернатива хуже; если вы просто будете ждать, пока ваше программное обеспечение дорастет до совершенства внутри собора, вы никогда его не выпустите.
Совершенство – это процесс, а не состояние. Перефразируя Эдуардо Хьюза Галеано, утопия подобна стремлению достичь горизонта, которого никогда не достигнешь, но это заставляет нас продвигаться вперед.
