Пользователь
0,4
рейтинг
15 апреля 2013 в 23:08

Разработка → Минифест (манифест разработчиков-минималистов) перевод

От переводчика

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

Снова прошу прощения за отсутствие перевода словосочетания “computer science”.


Кратко


  • Боритесь за закон Парето, следите за тем, чтобы 20% вашего труда давало вам 80% результата;
  • Расставляйте приоритеты, ведь минимализм нужен для того, чтобы делать то, что нужно, а не распыляться по мелочам;
  • Лучшее — враг хорошего: сначала просто сделайте, потом сделайте правильно, потом сделайте лучше;
  • Убивайте в зародыше, не бойтесь начать всё сначала. Чем быстрее ошибётесь, тем быстрее научитесь;
  • Повышайте свою ценность. Постоянно думайте о том, чем можно помочь команде, — и развивайтесь в этом направлении;
  • Сперва основы. Мыслите последовательно, ориентируясь на лучшие практики мира Computer Science;
  • Посмотрите с разных сторон. Простое получается тяжелее, чем сложное, поэтому включайте воображение;
  • Синтаксис — основа взаимодействия. Мы пишем код для людей, а не для машин;
  • Не запутывайте. Старайтесь проектировать слоями, по мере возможности не зависящими друг от друга;
  • Вычищайте оставленное-на-всякий-случай. Минимализм борется с отвлекающим от основного.


Боритесь за закон Парето


Закон Парето гласит, что восемьдесят процентов результата достигаются двадцатью процентами реализованных возможностей вашего приложения. Держите это в голове, когда планируете следующий цикл «спринт/цели».
Лучшие инженеры — те, кто может прикинуть затраты на реализацию выставленных требований  так, чтобы оставить 80% усилий на будущее.

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

Худший код, который вы когда-либо можете написать — это код, который не используется. Для этого есть аббревиатура YAGNI (You Are Not Gonna Use It) [дословно — «вы его не будете использовать»; здесь приведено дословно в соответствии с оригинальным текстом, прим. переводчика].

Лучший код, написанный вами ­— это код, который вы не напишете. Просто потому, что он не может быть ошибочным.

Расставляйте приоритеты


Есть способ исправлять ошибки, который я называю «осаждение». Это когда ошибка исправляется накоплением других ошибок. Есть ещё один способ, который я называю «эрозия». Это когда заказчик передумал. Те самые примеры, в которых расстановка приоритетов и выдержка оградят вас от ненужной работы.
Ведь минимализм — не способ выполнить работу. Минимализм — это способ сфокусироваться на важном.

Лучшее — враг хорошего


Ищите совершенства, но не прямо сейчас. Итерация — ваш друг, который даёт вам правильные советы в правильное время.
Сначала просто сделайте, потом сделайте правильно, потом сделайте лучше.

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

Относитесь ко всему, как к промежуточной стадии вашей работы. Не напрягайтесь, когда что-то пока работает не так, как нужно — помните закон Мошера, который гласит: «Если всё работает так, как надо, вы остаётесь без работы».

Убивайте в зародыше


Уничтожайте. Чем быстрее, тем лучше. Не бойтесь выбрасывать в мусорку то, над чем вы работали несколько месяцев.
Когда вы начинаете с нуля, само собой появляется что-то новое. Оно рождается из вашего опыта.

Постоянно оценивайте то, что вы делаете. Именно об этом написано в книге Lean Startup. Разрабатывайте свой MVP (Minimum Viable Prototype, Еле Живой Прототип). Проверяйте его. Не подходит? Выбрасывайте, вы уже получили опыт.
Чем быстрее вы ошибётесь, тем быстрее научитесь.

Повышайте свою ценность


Никто не может знать всё.

Задайте себе вопрос — чем можно помочь команде? В чём она больше всего нуждается? Кто из вас эксперт в масштабируемости? Кто досконально знает ваш язык программирования? Кто больше всего болеет за продукт? Кто координирует усилия?

Все команды разные, поэтому вам придётся приспосабливаться и выбирать, искать сильные и слабые стороны вас и вашей команды.
Учитесь любить что-то одно и беритесь за это. Пытайтесь правильно подать себя. Ведь и вам самим нравится то, что помогает решать ваши задачи, а не то, что кое-как выполняет вашу работу.

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

Сперва основы


В какой-то момент своей жизни мы поймём важность основ. Почему-то подразумевается, что возвращение к истокам — тема для пожилых людей. Постарайтесь не глупить и не ждите. Ставьте на основы прямо сейчас.

В анналах Computer Science есть проверенные временем отличные решения, которые вы можете применять в любом новом проекте. Нужно стараться думать последовательно, отталкиваясь от этих решений.

Перефразируя знаменитую поговорку: есть три важнейших аспекта разработки программного обеспечения — архитектура, архитектура и архитектура, именно в таком порядке.

Примеры таких основ: разделение ответственности, общая теория систем, шаблоны проектирования Банды Четырёх, общие шаблоны распределения обязанностей, принципы SOLID, чистый код, принципы Agile, алгоритмика, структуры данных, спецификации HTTP, и т.д.
Конечно, вы можете с головой окунуться в какие-нибудь фреймворки модульных тестов типа Jasmine, JUnit, Mocha — но, безусловно, полезнее будет научиться писать код, который можно покрыть тестами (например, изолируя код от состояния и уменьшая связность компонентов). 

Посмотрите с разных сторон


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

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

Не старайтесь работать больше, старайтесь работать меньше, но более интеллектуально. Думайте! Думайте о том, над чем вы работаете. Отключите автопилот. Покиньте зону комфорта. Возьмите управление в свои руки.

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

Конечно, люди могут начать думать о вас, как о человеке со странностями — просто потому, что вы будете делать странные вещи, но вы не можете стать лидером, пока не сможете сделать что-то странное и инновационное. Что-то такое, что ещё никто до вас не делал. 
Для примера: я уверен, что каждый из вас задумывался о том, что в компании много времени уходит впустую на всяких совещания и встречах. Ну, на тех, на которых говорят обо всём и ни о чём. Именно это толкнуло Джеффри Бэзоса (основателя и CEO компании “Amazon”) подойти к проведению встреч в своей компании слегка нестандартно. Когда все участники встречи собираются в зале для совещаний, у них есть 30 минут на прочтение тезисов встречи в полной тишине. И только после этого можно перейти к обсуждению.

Синтаксис


Мы пишем код для людей, а не для машин, синтаксис — основа их взаимодействия. 

Хороший пример в цитате Пастера: «Если бы у меня было больше времени, я бы написал письмо покороче».

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

Не запутывайте


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

Абстрагирование замечательно. Оно позволяет создать новый семантический слой, в котором можно точно выразить свои мысли. Но оно же для некоторых аспектов деятельности (например, для рефакторинга) усложняет понимание огромной и сверхдетализированной схемы системы.

Именно поэтому надо искать естественные точки, в которых мы может проводить рассечение и пытаться рассмотреть какие-то компромиссные решения.

Как пример: парадигма «Корень/лист» доменной модели, парадигма «Контроллер/инструменты», принцип «высокая плотность — малая связанность», межуровневые RESTful-интерфейсы взаимодействия.

Вычищайте оставленное-на-всякий-случай


Есть такое понятие — «оставленное-на-всякий-случай»[в оригинале — “kippel”, прим. переводчика]. Это то, что мы оставляем на всякий случай, но больше никогда уже не используем. В вашем доме такого навалом, впрочем, как и, наверняка, в вашем коде. Всякие унаследованные методы, которые мы боимся удалить из-за того, что какая-то часть проекта может поломаться; сиюминутно нужные бибилиотеки, которые нам больше никогда не будут нужны; устаревшие комментарии…

В самой природе человека лежит то, что мы должны создать сложность для того, чтобы потом её героически упростить. Нужно периодически пробегаться по проекту, находить «оставленное-на-всякий-случай» и уничтожать его.

Минимализм борется с отвлекающим от основного.
Перевод: Pablo Guevara
@80x86
карма
83,2
рейтинг 0,4
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (39)

  • +3
    Приятно узнать себя минималистом )
    Правда кое что прихрамывает, но эти места и сам знаю.
    Отличный минифест, побольше бы минифестантов.
    • +8
      Разве ж это манифест минималистов? Вот манифест минималистов: !
      • +4
        Вот манифест минималистов: programming-motherfucker.com
        • –2
          Это манифест (зачёркнуто) не очень умных людей.
  • +2
    Квинтэссенция опыта индустрии
  • 0
    Вот просто рад этой статье в понедельник )
    Спасибо большое, распечатаю каждый пункт и повешу в офисе!
  • +2
    <лирика on>
    Кстати, цитату про «написал бы покороче» кому только не приписывают — от Карла Маркса по Пастера. Мне нравится классический вариант «из письма другу»: «Извини, что пишу длинно, нет времени написать короче». Очень хорошая мысль. Ну а «Ваша работа закончена, когда из кода нельзя ничего выбросить» — как мне кажется, вообще отсылка к классическому ответу Микеланджело на вопрос «Как Вы создаете свои статуи?»: «Я беру камень и отсекаю всё лишнее»
    <лирика off>

    Хорошая статья.
  • +10
    Я просто оставлю это здесь www.python.org/dev/peps/pep-0020/
  • +12
    Делайте хорошо и правильно, а не плохо и неправильно. Обожаю такие посты. Те, кто поймет о чем речь в посте, уже применяют эти правила так или иначе. А те, кто еще недостаточно опытен, все равно не смогут применять эти правила, пока не дойдут до них сами. Нельзя просто прочитать пост и перепрыгнуть через несколько уровней профессионального развития.
    • +4
      Сначала просто сделайте, потом сделайте правильно, потом сделайте лучше.

      Вам еще прыгать. Никогда не делайте хорошо и правильно. Сначала делайте быстро.
      • +5
        Под «хорошо и правильно» я имел в виду не идеальный код, а эффективные подходы к разработке.

        PS мне еще всю жизнь «прыгать», чему я очень рад. Я никому не желаю останавливаться в развитии.
        • +2
          Хороший тост. Я с удовольствием присоединяюсь.
          • +3
            И еще большое спасибо за «Поле Чудес» — это было круто!
      • 0
        Прыгайте дальше. «Быстро» входит в «хорошо и правильно».
  • +2
    Лучший код, написанный вами ­— это код, который вы не напишете. Просто потому, что он не может быть ошибочным.


    Я расстроился :(
  • +3
    Краткое содержание статьи: лучше быть здоровым и богатым, чем бедным и больным.
    • +2
      Ого, как яростно заминусовали. Что ж, поясню. Подобные опусы вам ничего кроме лозунгов не дают. Чтобы из них что-то вынести, вы должны сами своей головой до них дойти.
      «Вы должны X потому что один очень богатый чувак делал X каждый день и у него получилось». Это стиль тупой агитки. А в разработке думать надо башкой своей!
      • 0
        Так лучше :)
  • 0
  • +3
    Конечно, вы можете с головой окунуться в какие-нибудь фреймворки модульных тестов типа Jasmine, JUnit, Mocha — но, безусловно, полезнее будет научиться писать код, который можно покрыть тестами (например, изолируя код от состояния и уменьшая связность компонентов).

    Можно покрыть тестами почти любой код (кроме исследовательского и т. п., когда результаты не определены). Нужно научиться писать код, который легко покрывать тестами. Но сложно этому научиться без окунания с головой. Только когда попытаешься покрыть тестами достаточно большой проект, который «нельзя» покрыть тестами, тогда придет понимание как писать код, который легко покрывать. Заодно и понимание того, что стоит покрывать, а что нет. Прочитав книжку про TDD понимание не придет (ну или я совсем тупой). Только практика приведет к пониманию на уровне рефлекса.

    P.S.Ошибка в переводе
    высокая плотность — малая связность
    Есть слово «связанность», а есть «связность» — практически антонимы в данном контексте. Обычный перевод «high cohesion — low coupling» — «высокая связность — малая/низкая связанность» или «высокое сцепление — малая/низкая связанность». Пишу не в личку, потому часто вижу это ошибку и в комментах, и в постах.
    • 0
      Вы правы. Спасибо.
  • +3
    «В один из наиболее продуктивных дней я удалил тысячу строк кода». Кен Томпсон
  • +3
    «Боритесь за закон Парето» — странный подход для минималиста. Логичнее было бы бороться против него, выполняя только самые полезные 20% и не тратя 80% на рутину и выскабливание, отдавая это джуниорам, автоматизируя и т.п.
    Да и остальной текст, вроде как бы по теме, только иногда с погрешностью 100%, не знаю уж проблема это перевода, формулировок или понимания.
    • 0
      Написано же, что 80% усилий нужно оставлять на будущее. То есть реализовывать сейчас только те 20%, которые решат задачу на 80%. А остальное отложить на потом, когда более важные задачи будут решены. Причем с большой вероятностью это «потом» никогда не наступит в виду изменившихся требований.
      • 0
        Только есть одна проблема. Выполняя всё быстро в какой-то момент может оказаться, что система пришла в настолько не поддерживаемое состояние, что теперь быстро занимает в 10 раз больше времени, чем раньше правильно. Поэтому, ИМХО, это правило плохо подходит для крупных проектов, разве что вы не хотите сделать хоть как-то, а потом уйти.
        • +1
          Речь не идет, по-моему, о выборе между «писать говнокод быстро» и «писать правильно». Речь, прежде всего, о выборе реализуемых фич. Есть 10 требований к какому-то продукту с условно одинаковой длительностью реализации, реализовали 2 самых важных и даем заказчику «посмотреть». Получаем от него два новых фичереквеста и опять выбираем 2 самых важных из общих 10, реализуя их, и т. п. Глядишь так о 8 из первых 10 он и не вспомнит никогда :)

          Это не отменяет того, что за архитектурой нужно следить, покрывать тестами и проводить постоянный рефакторинг, не допуская наращивание технического долга, но не нужно закладывать в архитектуру суперрасширяемость и супергибкость на будущее. Прежде всего не нужно вводить уровни абстракции, которые сейчас не требуются. Код должен быть готов к их введению, но вводить заранее не нужно.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Удивительно, что вчера была опубликована моя статья на хабре:

    habrahabr.ru/post/176669/

    библиотека yaui, построена именно на этих самых принципах. Как здорово, что вы тут опубликовали эти принципы, так точно выражающие мой подход, который всегда так не просто доносить до окружающих. Ведь если не понимать идей минимализма (и наномализма) то люди часто не впечатлены, поскольку привыкли оценивать по внешнему богатству по отдельным впечатляющим внешним элементам.
  • +1
    Правило Парето-Зенона. Если 20% труда дает 80% результата, то 20% от оставшихся процентов труда дает 80% оставшегося результата. Если продолжать трудиться, мы получаем уйму свободного времени и никогда не заканчивающийся проект.
    • +2
      Да да. Меня всегда принцип Парето формально удивлял. Люди с ГСМ очень его любят. Но при этом никто не думает, что для того, чтобы 20 процентов выстрелило, надо пропахать и 80 процентов.
      А в манифесте тоже формально смешно звучит «Боритесь за закон Парето». Если это не закон и себя не проявляет, то давайте бороться за 10 процентов, а лучше за 5.
  • 0
    YAGNI расшифровывается как You Ain't Gonna Need It (вам это не понадобится)
    • 0
      В оригинале было написано то, что было написано.
      Я тиснул комментарий (на всякий случай).
      • 0
        ну все таки смысл фразы имеет другой оттенок
  • +4
    Я перед тем как прочесть обычно бегло сканирую статью. Насканировалось:

    Разработчикам… Манифет…
    Убивайте в зародыше…
    Уничтожайте… Чем быстрее, тем лучше…

    Я аж кофе попрехнулся. Прочел, а оно вон че оказалось :)
    • 0
      Ждём лекции-анализа о «сканировании». С одной стороны lesswrong и компания с необходимостью отрицания опоры на прошлый опыт и эмперического подхода, с другой — экономия времени и плюшки в виде таких вот смыслов. В комментариях, как мне кажется, многим будет что добавить.
  • 0
    Видел на реальной практике как люди эти принципы применяли не правильно, в следствие этого их работа была долгой и крайне низкого качества. Возможно многие из этих принципов работают в стартапах, но не работают в корпоративном секторе, где надо внимательно, быстро и хорошо.
    Даже скажу больше, все зависит не от самих принципов, а от человека. Тот, кто умеет — тот делает. А кто не умеет говорит, что 20% усилий дают 80% результата.
    • 0
      >Лучшее — враг хорошего
      Однако, от хорошего к великому — целая вселенная. Многие люди всю жизнь остаются лишь «хорошими», вместо того, чтобы взять и сделать оставшиеся 80% и стать действительно великими! Я же думаю вы знаете, почему Джобс крайне был чувствителен к минимальным деталям продукта!
  • 0
    Читая перевод, заметил неточность в переводе:
    (оригинал github.com/pabloguevarac/minifesto/blob/master/german.html#L74)
    В переводе вы использовали «Синтакс» вместо «Синтеза». Инетресно чья ошибка ваша или автора.
    • 0
      Чёрт его не знает.
      По смыслу что то, что другое не очень :(

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