Об язык С

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

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

На самом деле, Си лучше всего подходит для подкрепления разработки 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%. Любопытно, какое иное решение озвученной проблемы они придумали..

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

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

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

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

Об паттерны

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

Структурные и поведенческие паттерны тут могут придтись как никогда к месту. Только элементами тут будут не классы, а целые системы.

- Медиатор - здесь подсистема (iftt, zapier) сливает в себя все данные, а потом дирижирует другими сервисами, не давая связаться напрямую.

- Декоратор - здесь подсистема выполняет действие (порождает события), и пробрасывает вызов дальше по сервисам.

- Ну и так далее. Я перечислил только пару паттернов из Э. Гаммы сотоварищи, но классификаций и вариантов сильно больше.

Ждем курса по паттернам на Гикбрейнзах и прочих Скиллбоксах для НеРазработчиков?

Прочел давеча, что бизнес в ИТ строится от инициатив разработки. Так и представил, что сидит маркетинг, менеджмент, сейлзы, аккаунты круглым столом вокруг разработчика: "ну, с%кабл%ть, где твои инициативы, ты что, не видишь, ты щас весь наш бизнес рушишь?!"

Об успех в стартапах

В Forbes 100 за 2020 год 52 основателя стартапов, 2 жены основателей и 2 ранних сотрудника с долей. Жениться/выйти замуж за основателя стартапа это примерно так же результативно, как и придти ранним сотрудником и много лет рвать ж@пу за долю. Вернее, если посчитать, даже более результативно – жён основателей поменьше, чем ранних сотрудников с долей

Об людей-функции

Переход на удаленную работу - второй шаг на пути к "сотрудник-функция". Для тебя неважно, кто на том конце сидит, может, человек, а может, и роботом давно заменили. Вот чтобы заменить было легко, сначала надо сепарировать и четко api выставить, в виде тикетницы, например.
Первым шагом был agile и движение в бирюзовую сторону, где роль (само)управления вручена самой команде, потому что менеджер роботом заменяется плохо. Биржи NoCode, FMS (freelance management system) - тоже какой-то из таких шагов.

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

Как бы вы определили, что такое киллер-фича? Ну, чтобы понял не только тот, кто ее делает

Если верить нашей бигдате, ваш самый любимый товар — пакет

В последнее время все настойчиво приглашают в вакансии, в которых отдельно акцентируется, что команда успешно экспериментирует с Amazing ComputerVision AI BigData Machine Learning и прочие такие баззворды, как будто это должно как-то впечатлить или стать аргументом в пользу выбора.

Ситуация буквально "а если кому-то удается сделать хоть что-то мало-мальски работоспособное, то все его поздравляют, потому что это правда успех".

Я бы вообще, если мог бы, настроил фильтр, в котором не будет CV AI ML и прочих этих буквосочетаний в почте. Тенденция, когда deep tech из мультипликатора бизнеса становится его основой, лично меня неприятно беспокоит.

Уроборос Аджайла

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

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

- Команда и ответственность важнее индивидумов и взаимодействия
- Бизнес-ценность важнее рабочего продукта
- Развитие партнёрских отношений важнее сотрудничества с клиентом
- Готовиться к изменениям важнее реакции на изменения

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

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