У липні EuroPython 2013 відбувся в Флоренції, Італія, вже третій рік поспіль. Трохи про мене: я італієць і програміст Python, тому я дуже радий поділитися більше про свій досвід участі в EuroPython. У Python чудова спільнота, повна деяких з найрозумніших і найнатхненніших людей у ІТ-індустрії. Після семи років участі у цій спільноті я можу чесно сказати, що конференції Python – це все про людей. Люди роблять цю спільноту великою.
Однією з таких надихаючих особистостей є Алекс Мартеллі, старший інженер компанії Google та член Фонду програмного забезпечення Python. Цього року він представив ключову доповідь на EuroPython під назвою “Достатньо добре” є достатньо добрим! або, як він сказав, цитуючи Річарда Габріеля: підхід Нью-Джерсі, відомий як “Гірше є кращим” проти “підходу МІТ/Стенфорд, відомого як “Правильне рішення.” Я не був впевнений, про що він буде говорити, але назва була інтригуючою. І одне, що я вивчив з доповідей Мартеллі за останні сім років, це те, що коли він говорить, найкраще, що ви можете зробити, це слухати, вчитися та робити нотатки. Отож, саме це я і зробив.
Основна доповідь розглянула два різні підходи до випуску програмного забезпечення. Перший, “The Right Thing”, рекомендує прагнути до досконалості (задовольнятися релізом програмного забезпечення, який є нижче “ідеального”, є шкідливим компромісом). Другий, “Worse is Better”, каже тримати все простим, достатньо добрим, запускати рано, запускати часто, отримувати багато відгуків (це “підхід Нью-Джерсі”, тому що Unix є гарним прикладом і був написаний у Нью-Джерсі).
Martelli пояснив, як Річард Габріель визначив чотири основні цінності, які мають спільні обидва ці підходи: простота, правильність, узгодженість та повнота. Він продовжив пояснення тим, що насправді має значення пріоритет, наданий цим цінностям. Висновки Габріеля можна підсумувати цими двома цитатами:
Філософія правильної речі базується на дозволі експертам робити те, в чому вони є експертами
річ до самого кінця, перш ніж користувачі отримають до неї доступ.
Worse-is-better використовує природні переваги інкрементного
розробка. Поступове вдосконалення задовольняє деякі людські потреби…
Він пішов ще далі, зазначивши, що інтерпретація Габріеля близька до того, що Ерік Реймонд описав у своїй книзі «Собор і базар», де він описав дві розходжені моделі розробки програмного забезпечення: собор, де керують експерти та все зосереджено на експертній діяльності, проти базару, який є колективним і хаотичним, де керує натовп і включає людей, які безпосередньо залучені, але неминуче навіть люди, які просто допомагають, є там, оскільки їм потрібна продукція базару для непов’язаних робіт.
Очевидно, що Реймонд зосереджувався на помилках і вірив, що мільйон очей зробить процес виявлення помилок швидшим – і це саме те, про що йдеться. Щоб мільйон людей на це дивилися, ви маєте випустити код. Ви маєте випустити його у реальний світ та дозволити людям ним користуватися. Як сказав Мартеллі, якщо ви хочете випускати лише “Досконалість”, якщо ви хочете, щоб експерт робив роботу експерта, тоді вам потрібен “Великий дизайн спочатку”, ідеальне визначення вимог, ідеальна архітектура, ідеальний дизайн, ідеальні реалізації тощо. І це займе вічність! Але ще важливіше, реальне життя часто не співпрацює.
Цитуючи Мартеллі знову, «Реальне життя зазвичай не співпрацює». Вимоги змінюються, а разом з ними і архітектура, дизайн та реалізація. Ітеративна розробка – це той шлях, який треба обрати. Розгортайте щось, виправляйте помилки, вдосконалюйте, використовуйте контроль версій, рецензування коду, стиль кодування, тестування (якщо ви не тестуєте, ви просите про неприємності) і, нарешті, чітко документуйте те, що ви зробили.
Це не означає, що ми повинні знижувати свої вимоги. Як зазначив Мартеллі, “наша мрія повинна залишатися великою, але найкращий спосіб досягти цих мрій – це ранній реліз, часті релізи.” Він продовжив, показуючи приклади ідеальних архітектур, які так і не були реалізовані, випущені, або які програли битву своїм не таким досконалим конкурентам, включаючи Xanadu vs WWW, TCP/IP vs ISO/OSI, MIT ITS vs UNIX.
Відео презентації триває близько години, але я дійсно рекомендую всім, хто розробляє програмне забезпечення, подивитися його. Навіть якщо ви не згодні з висновками, це чудове джерело інформації. Запис презентації: http://www.youtube.com/watch?v=gHG9FRSlPxw
Моє велике запитання після промови було: «Коли “достатньо добре” є достатньо добрим?» Коли настає цей момент, коли ви знаходитесь посеред процесу розробки, і можете сказати: «Гей, настав час!» На щастя, відповідь на моє запитання вже була у промові Мартеллі, просто чекала, щоб її помітили.
Підказка: ось уривок зі статті Еріка Ріса, автора “Стартап за методом Lean”, Достатньо це ніколи не є (чи це так?). Це його визначення “мінімально життєздатного продукту”.
“Мінімально життєздатний продукт — це та версія нового продукту, яка дозволяє
команда для збору максимальної кількості перевірених знань з мінімальними зусиллями.
Ось воно! Це та відповідь, яку я шукав. Розгорніть щось, що зробить життя когось кращим, щось, що вирішує деякі реальні проблеми. Зробіть це, як тільки воно буде у стані, що дозволяє вам та вашій команді вчитися з реальних взаємодій користувачів, збирати реальні дані та отримувати реальні відгуки. Навчіться справлятися з тим, що користувачі живуть у реальному світі – і цей світ недосконалий. Але альтернатива гірша; якщо ви просто будете чекати, поки ваше програмне забезпечення досягне досконалості всередині собору, ви ніколи його не випустите.
Досконалість – це процес, а не стан. Перефразовуючи Едуардо Х’юза Галеано, утопія – це як намагання дістатися до горизонту, якого ти ніколи не досягнеш, але це змушує нас рухатися вперед.
