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

На днях в сети появился минисайт 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”, прим. переводчика]. Это то, что мы оставляем на всякий случай, но больше никогда уже не используем. В вашем доме такого навалом, впрочем, как и, наверняка, в вашем коде. Всякие унаследованные методы, которые мы боимся удалить из-за того, что какая-то часть проекта может поломаться; сиюминутно нужные бибилиотеки, которые нам больше никогда не будут нужны; устаревшие комментарии…

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

Минимализм борется с отвлекающим от основного.