Об документацию

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

Комплект из "Инструкции по сборке" и "Руководства пользователя" закрывал вообще 80%+ процентов вопросов по всем темам, от функциональности до внутреннего устройства.

Теперь софт пишут по аджайлу, а развертывают докером, и в инструкции по развертыванию часто идет одна команда - как стартовать докер образ, и креды к репозиторию образов. Вот такой внезапный удар в дупло, усложняющий эксплуатацию.

А вы думали, большим компаниям сильно надо, чтобы у вас получалось?

Без темы

Видели в интернете одно время было популярно забавное увлечение: додумывать пословицы, как они были "на самом деле"? При этом смысл менялся.

Например: "кто старое помянет, тому глаз вон -- а кто забудет, тому оба".
Или: "рыбак рыбака видит издалека -- и стороной обойдет".

Как минимум, это было интересное, нестандартное упражнение. Часто такое упражнение проделываете?

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

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

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

Или вот еще: чувак, я слышал, ты в школе арифметику учил? А ну, посчитай пример с канала "Хулиномики": "Илон Маск внёс на брокерский счёт 5000 долларов. Он купил 300 акций Теслы по $30 за штуку. Минимальная маржа у брокера - 30%. Не учитывая комиссий и процентов по займу, при какой цене акций он получит маржин-колл?". На ответ дается три-четыре минуты.

Не могу в уме посчитать, сколько банку должен буду, если занял Х, а возвращать буду так-то и так-то? Так я, выходит, не арифметику учил, я опять неправильными визуализациями страдал, дурачок. Зачем мне интегралы, если меня примеры из жизни в тупик ставят?

И так во многом.

Об дистанционную работу

Мы не нанимаем дистанционных сотрудников. Ну, таких, которые сидят дома или в коворкинге, и индивидуально работают на нас. У подхода есть и плюсы, и минусы, мы решили, что минусы перевешивают, пока мы можем нанять локальных. Хочу объяснить, почему.

1. Всеобщее стремление к удаленной работе похоже на карго-культ. Напомню, что в середине 90х, в 200х в условном Сиэттле программисты даже в крупных компаниях сидели в "кубиклах", исправно приезжали на работу, и вопросов к этому было немного. При этом компании вполне себе строили и нанимали удаленные ресурсные центры из условного Бангалора. Потом все поменялось. Почему? Очень просто. Стартапы в Долине обнаружили, что местные разработчики кончились, ездить по два часа никто не хочет, платить за дорогую аренду нужно и за офис, и за жилье сотрудникам опосредованно. И тут зажглась звезда "удаленки". Но мы не стартап в Долине, мы не хотим бежать вслепую с чужой повесткой.

2. Кажется, что удаленка сильно расширяет возможность нанять хорошего сотрудника, и это плюс. Но этот плюс надо помножить также на минусы. Минус номер 1: если при офисной работе вы конкурировали за сотрудника в плюс-минус окрестности офиса, то теперь вам надо конкурировать с гораздо большим числом компаний, которые тоже нанимаю удаленно. Это круто разным Амазонам и Одноклассникам, но совсем не круто для небольших компаний. Минус номер 2: людей стало больше, но от этого они не стали автоматически уметь работать удаленно. Да, представьте себе, работать на удаленке тоже надо уметь, от одного желания такое умение у работника не появляется.

(83% удалённых сотрудников обманывают коллег и руководителей по поводу работы)
https://incrussia.ru/news/obmanyvayut-kolleg/

(Треть сотрудников IT-компаний признались, что работают 3–4 часа в день)
https://incrussia.ru/news/working-only-3-4-hours-a-day/

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

Мы поразмыслили над всем этим, и пришли к такому варианту:
- нанимаем в офис в городе
- обеспечиваем режим 3/2 или 2/3 "офис"/"дом".
Можно ли лучше? Можно. Но вряд ли за счет перевода на удаленку.

Джентльмены, обращаюсь за советом.

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

С моей стороны есть требование только к полетному контроллеру - он должен быть конкретным по выбору, остальное уже по лучшим практикам рынка. Хотел бы получить его в сборе. Что можете посоветовать? Есть готовый kit?

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

Об микросервисы в который раз

Ну, хорошо, всем продали микросервисы: дескать, и устройство системы понятнее из-за них, и two pizza team вообще стандарт в Гугл ИТ, значит, и нам надо тоже. И код можно писать на самом подходящем языке: хочешь, пишешь на php, не хочешь, пишешь на nodejs, что очень удобно (особенно потом сопровождать комплекс, написанный на 10 языках). А еще можно переписать за две недели маленький микросервис, любой. Ну круто же, правда?! А еще архитектура очень отказоустойчивая, и если один сервис упал, то остальные выживут (на практике - не работает никогда). И самое главное - можно МАСШТАБИРОВАТЬ приложения! О том, что монолит тоже можно масштабировать, тем более сейчас, когда железо ничего не стоит, молчат.

Но это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:
1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.
2. Найм. В ситуации, когда средней компании найти хорошего разработчика за праздник, в случае микросервисной архитектуры можно нанимать вообще любых программистов, которые подвернулись, а не те, которые подходят по стеку или согласны работать с легаси и т.п.

Эти две причины пересиливают все сложности, связанные с МСА. А сложностей немало, от оркестрации до смены парадигмы владения системами.

Все, больше на самом деле ни зачем не надо. А, еще маленькое замечание: проще нанимать людей, потому что "у нас такие же крутые технологии, как в Гугле, так что мы будем платить поменьше".

Картинка: сияние простоты МСА в Monzo, британском необанке

Потратил пару вечеров на то, чтобы разобраться со стянутыми из разных мест интернета библиотеками sensor fusion по алгоритму Махони, а он все не работает. Оказалось, что его реализации на гитхабах содержат мелкие ошибки, заботливо опенсорснутые авторами. Сегодня почитал оригинальные пейперы и методические рекомендации, сократил код в полтора раза, и все заработало. Опенсорс - сила! (нет)

Интересный казус с GPL v3 в российском правовом поле: в России признают только переведенные на русский документы, а GPL явно выражается, что изменения в нее, в том числе переводы на другой язык, ее нарушают.

Поэтому тем, кто выбрал этот путь, придется выпускать хитрый dual-licensed, который все равно будет нарушать GPL на территории России, но будет валиден в отношении нее на других территориях

Об язык С

Существует некоторая легенда, что язык Си предназначен для системного программирования.

На самом деле, нет. Для системного программирования он оказался предназначен, потому что любое программирование в те годы было системным, кроме рассчетов баллистики на Фортране.

На самом деле, Си лучше всего подходит для подкрепления разработки Unix-way, просто об этом забыли. Так что на нем писать? Высокоэффективные портабельные одно-страничные и одно-файловые утилиты, которые соединяются друг с другом клеем в виде пайпов и скриптов. Для этого в Си есть:

1. Независимая (а не раздельная) компиляция, модуль = файл. Поэтому многофайловые проекты компилируются небыстро, т.к. по умолчанию надо оттранслировать все .h-файлы заново.

2. Отсутствие работы со строками. В системных утилитах строки нужны для работы с файлами, а на это уже есть posix api, больше ничего не нужно.

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

4. В юниксе все - это файл, в Си все - есть указатель. Хочешь мутабельную или иммутабельну ссылку? Держи указатель. Хочешь привязаться к адресу в памяти для ввода-вывода? be Держи указатель. Хочешь посчитать размеры? Держи адресную арифметику на указателях. А для коротких мелких утилит больше ничего и не надо.

5. Даже компиляция родным инструментом (gcc) идеально делается для однофайлового проекта, без всяких мейков: "gcc main.c", и все. Полученный a.out можно запускать.

В этом смысле Rust его никогда не вытеснит, потому что решает совсем другую проблему и не является конкурентом.

Об git и не только

Я уже как-то писал, что недолюбливаю git. Разумеется, я не уникален в этом. Некто Ричард Хипп - вы его могли знать, он там одну небольшую малоизвестную любительскую БД написал - sqlite - однажды решил, что так жить нельзя, и написал свою scm - FOSSIL. Что в ней интересного:

1. Это scm для людей. Там всего один бинарник, и вся метаинформация транзакционно хранится - вы не поверите - в sqlite на дисочке.

2. Ничего не надо устанавливать в систему, достаточно drop-copy бинаря.

3. В систему встроен веб-сервер для GUI, а fossil достаточно умен, чтобы понять, что директория содержит markup-файлы, таким образом, к коду в этом же репозитории можно вести и просматривать документацию, и все это локально.

4. GIT все равно все используют как централизованную SCM с главным репозиторием, так что fossil по умолчанию так и работает: делаешь коммит, и оно тут же отправляется в главный remote. Это не очень подойдет для больших команд, но нормально для trunk-based development, а к тому же не плодит бессмысленные мерж-коммиты.

В общем, если хочется взять и начать работать локально, и бесит git, альтернативы есть.

fossil repo history

В современной разработке принято скептически относиться к наследию прошлого. Это касается и знаменитого "ГОСТ 34". Знатоки амазона и специалисты по кубернетесам уверены, что это устарело, не нужно, да и вообще олицетворяет все самое плохое, что ассоциируется со словом "водопадная модель разработки". Хочу в нескольких важных пунктах описать, что такое ТЗ по ГОСТ 34.602-89, и почему он никак не устарел.

1. Начнем с заголовка. ГОСТ 34 звучит так: "Техническое задание на создание автоматизированной системы". Это не спецификация на систему (SRS, требования к ПО), а спецификация на процесс ее создания. То есть в этом документе описывается не столько система, сколько весь development lifecycle, связанный с конструированием и запуском. И согласно этому, там есть место для:
- замысла системы
- решаемых проблем
- оснований для создания системы: кто заинтересован, кто платит, как проверить, что сделали то, что нужно
- план выполнения работ: конструирование, пилотирование, сопровождение, и стоимость работ.

Если вы не можете перед началом работ описать проблемы, которые собираетесь решить, и как проверить, что результаты достигнуты, то дело, вероятно, совсем не в ГОСТе.

2. Если внимательно почитать сам стандарт, то в п. 2.2 можно найти замечательное (неточная цитата) "по согласованию сторон, допустимо переименовывать разделы, объединять, вводить новые и опускать неактуальные". Ну вы поняли, да? :) Можно оставить только нужные вам разделы, и это все равно по духу останется ГОСТом.

3. Поклонников Agile пугает пункт о плане: как можно предположить план, начиная разработку, ведь по канону план каждой итерации должен составляться по окончании предыдущей, и никто не знает, что будет делаться дальше, рынок покажет? И на это есть ответ. В плане пишем короткое и понятное: "в соответствии с ведомостью исполнения работ". Всё, работаем, ведомость заполняем из вашей скрам-тикетницы.

4. Что насчет требований, документации? Многие мыслят ТЗ в ГОСТ 34 как огромный талмуд с требованиями, а какие в Agile предварительные требования? И это легко решается. Вместе с замыслом работ у вас есть описание, что хочется получить, в конструктивной форме. Нарезаете его на сценарии, запускаете в разработку. Из этих сценариев, кстати, составляется документ "Программа и методика испытаний" для сдачи - пожалуй, единственный обязательный документ стандарта. Процесс сдачи это кумулятивное демо, а к демо в скраме относятся крайне благосклонно.
Остальная документация носит рекомендательный характер, можете ее писать, или не писать, можно в вики, можно в тикетах, где угодно.

—

В общем, оригинальная задумка ТЗ по ГОСТ 34 это не про требования. Это про то, как управлять разработкой, причем так, чтобы каждый инженер проекта смог внести максимальный вклад.

Роскошная статья про настоящий легаси. Очень люблю такую инженерную археологию

https://habr.com/ru/post/547820/

Еще немного инженерной археологии в чат. Как позабытый опыт прошлого (Ada) помогает в настоящем

https://habr.com/ru/post/549688/

А есть где-то подтвержденные исследования, что если тестирует не программист, а тестировщик, то ПО (в смысле, у пользователя) получается более качественным в конечном итоге?

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

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

*не является инвестиционным советом, и может вам не подойти

Для любителей аргумента "люди превыше инструментов и процессов" загадка. Что такого магического произошло с людьми в 1850-м году, что до него бизнес был почти исключительно малым, а потом вдруг, за какие-то 30-40 лет появились корпорации, бизнес-школы, национальные проекты, etc?

Об тимлидов

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

Судя по тому, что тимлиду платят всего на 10-20% больше при том, что он отвечает за работу 10+ сотрудников, бизнес делиться успехом не согласен, и такой руководитель группы, самоходная единица ему особо не нужен, а нужен на самом деле - пилот корпоративной машины, который будет послушно жать на врученные педали и крутить врученный руль, а бизнес (на словах) постарается решить все "руководческие проблемы", от ресурсного обеспечения до карьерного трека и мотивации. Фактически, конечно, все это не решается, так что днём такая самоходная разработческая единица бегает по верхней палубе, вечером растыкивает тикеты за тех, кто "просто пришел программировать". А когда код писать тимлиду? А код тимлид по ночам фигачит, потому что обязанность по выработке с него никто и не снимал.

Как же это продают тимлиду, да и всей команде? Тут в ход вступает заветное "зато над нами ненавистных менеджеров нет!". Ведь менеджер (всегда бесполезный) - конец любого дела, безотказный жупел, аргумент в любом споре.

О том, что ждет тимлида, обычно никто не говорит, ну так давайте я вспомню типичные вопросы. Команда немотивирована, а ты крайний? Прогеры посрались из-за табов/пробелов? Безопасники неделями проект на тормозах спускают? Три продакта суют задачи свои, у каждого самые важные, угрожают оценить ниже низкого, прощай, новый грейд? Таков корпоративный аджайл. Зато менеджеров в команде нет! Просишь сотрудника помочь, он отвечает, мол, это не в моих рабочих обязанностях, доплачивай, или я буду вежливо скипать задачу. Бюджета нет, должностные обязанности шатаешь не ты, руководитель говорит - "ну, ты же управленец, найди подход, а то какой ты тимлид".

Бюджетом ты не управляешь, найм и увольнение тоже не контролируешь (привет, матричная структура!), приоритеты ставишь не ты, рефакторинг надо продавать через две головы вверх, иначе тупо никто не поймет, корп.архитектор рисует абстракции? Ну и что! Зато - ненавистных менеджеров над нами нет.

Есть мнение, что это все работает, потому что а) эффект масштаба - в крупной компании матричная структура крайне эффективна б) современные инженеры, в среднем, крайне мотивированы и прилежны. Таким образом 10% самых неравнодушных в компании с успехом привозят пирог прибыли, который делится и на оставшиеся 90% корпоративных паразитов. Компания не только не гибнет, а еще и развивается - но только крупная.

При этом компанию тащат и развивают 10% вот таких вовлеченных тимлидов. Зато .. - что? Правильно.

Про 20% времени, которое гугл отдает сотрудникам

В компании невозможно все 100% времени людей держать занятыми. Поэтому иногда они будут простаивать - это нормально, Голдратт в "Критической цепи" обосновывает, почему это нормально, и показывает, что это необязательно означает падение производительности.

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

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

Второй возможный вариант, похоже, придумали в Гугле: 20% времени, которые можно потратить на любой проект по выбору - при условии, что свободное время от проекта есть, все все понимают, работа есть работа.

Плюсы подхода: сохраняется мораль, и раскачивается бренд и гордость, обеспечивается воодушевление, все остальное. Интересный ход, в общем.

А относительно недавно Гугл отказался от практики 20%. Любопытно, какое иное решение озвученной проблемы они придумали..

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

Мне иногда в личку прилетают вопросы, вот один из них: надо ли иметь талант и предрасположенность, чтобы управлять, или конструировать — или этому можно научиться? Многие считают, что писать код это интересно, а управлять людьми – "не их".

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

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