Как был, так и остаюсь убеждённым противником публичных pet projects. Нет ничего более захламляющего интернет и бестолкового, чем эти огрызки начинаний, студенческие пробы, альфа-версии и прочие заброшенные строения, выдаваемые за сделанную (по факту проделанную) работу, при использовании которой наступаешь на груду багов и получаешь «ну чё ты, исходник открытый, допиши, исправь, поучаствуй». Напиши большими буквами в README слова «это не драйвер, который я в азарте пропихнул во все списки драйверов, но пререлизная альфа, на которую я забил, едва мне стало скучно, но почему-то не упомянул об этом, пользуйтесь, дарю вам, люди дорогие, фугас под колесо», претензий не будет. Но нет, не пишут.

Потому полезные проекты предпочитаю называть side projects — на первый взгляд то же, но нет. Это закрытые от публики проекты, создаваемые с ясно понимаемой достойной (не ради строчки «дважды в сутки участвую в open source» в резюме) целью, выходящие наружу лишь в стадии продукта, либо не выходящие вовсе. Собсно, это пояснение, почему ниже в тексте side, а не pet.


Так вот, занялся я одним side project. И в рамках оного сознательно пишу код так, как писал бы, будь единственным человеком в галактике. Просто потому, что не собираюсь этот код никому показывать, а если и покажу, мне пофиг. После пары недель такого режима заметил забавное и в то же время очевидное, пожалуй — работа в команде замедляет разработчика. Без команды делаю всё минимум вдвое быстрее. Совокупный список собранного выглядит вот так…

Во-первых, не придумываю commit message. У меня каждый коммит с текстом «update». Даже в больших командах в этой строчке достаточно указывать номер тикета с двумя-тремя словами для того, чтобы в какой-нибудь отчёт могло читаемо лечь или чтобы у читающего уведомления взгляд за ключевые слова зацепился. Себе же это нафиг надо.

Во-вторых, не парюсь с названиями локальных переменных. Их читаю я. У меня в школе была физика, была математика. Потому однобуквенные переменные мне норм, потому могу не зависать на пять минут в глубочайших размышлениях о том, что же лучше, somethingInteger или integerSomething. Или tseloeChisloChegoNibud?

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

В-четвёртых, не трачу время на то, чтобы своими словами пересказать какой-нибудь стандарт или спецификацию. Вот ссылка, вот номер. Я точно прочту. То, что (как показала многократная практика) какой-то Вася однажды поленится прочитать RFC ISO 1294.345b и ему оторвёт жопу… удачи, Вася!

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

И т.д.

Вообще непривычное ощущение… Попробую внятно сформулировать: если ты хочешь сделать проект, ты берёшь и делаешь проект. Командная работа (в команде, с командой, для команды, над командой) — она в очень многом про другое. Да, конечно, всё направлено на благо проекта, через пятые руки работает на результат, бла-бла, этим постоянно моют друг другу ушки на конференциях и в мотивирующих статьях. Только вот порою слишком много ресурса уходит на процесс получения результата, а не на результат. Это норм в больших компаниях (текучка, отчётность, многолетние проекты, выкатки на десятки миллионов пользователей, всё такое), но насколько привольнее дышать, если можешь всем этим не заниматься.


Многим знакомый пример: вы замечаете тупейшую односимвольную ошибку. Ошибка очевидна, понятна, проста для исправления. В side project’е я трачу на неё минут пять: добавить тест, исправить, собрать, запустить тесты, закоммитить.

При налаженных процессах ситуация иная (ща вот из живой реальности диктую):

  1. Придумать текст тикета, понятный менеджеру, лиду и QA. Создать этот тикет, привязав к версии проекта.
  2. Убедиться в том, что этот тикет по приоритету умещается в текущую работу (ну вдруг аще совсем отвлекаться ни на что нельзя, у нас тут блокер горит!).
  3. Исправить. Закоммитить. Создать pull request, назначив ответственного за code review.
  4. Ответственный прочтёт, осмыслит, убедится, вмёржит в ветку.
  5. Катнуть на тестовый сервер.
  6. QA проверит, закроет тикет.
  7. Ура, один символ исправлен на другой. На сцене четыре человека и фиг знает сколько времени.

И это правильно. Теперь уже на примере side project’а я убеждаюсь в том, что процессы (на которые в последние годы ну очень сильный акцент в литературе и культуре) важны и нужны, если вы строите галеру. Невозможно не нанимать криворуких дворников от разработки, если вы в месяц нанимаете сто программистов и увольняете сто программистов. Ну какой тут продукт, какой результат, если нет многоуровневой защиты от Олега, мыслящего уникально.

Но в то же время эта защита как-то ну совсем уж замедляет разработку. Впрочем, я не один такой умный на планете, потому ещё со времён Bell Labs 40-х в R&D (для которых важно породить новое раньше конкурента) не нанимают идиотов, а нанятые не ходят строем на помывку. И это же модель для стартапов, желающих успеть застолбить какую-нибудь нишу раньше неповоротливых корпораций — вложиться в крутых бойцов, дать им волю, убрать все методички, правила, процессы, показать цель и скомандовать «фас». Вот тогда и получается так, что агрессивные Петя, Вася и Егор за год выкатывают продукт, который интереснее и лучше по всем параметрам, чем продукт, который уже два года пилится в недрах Гуяндбука силам двадцати рандомных Джонов Доу.


Альтернативно читающим дополню следующим: отказ от процессов не означает плохой результат. Процессы — они про снятие доверия с программиста, про многократную страховку от кривых рук. Если руки прямые, результат может быть вполне норм, тому много примеров. Вы можете потратить $1M на процессы и нанимать разработчиков за $1. Или вы можете нанимать разработчиков за $1M, обеспечивая процессы за $1. Понятно, индустрия выбирает первый вариант, он надёжнее.