​​Техдирский Треш
https://t.me/ctorecordstrash

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

Присылать свои треши можно через форму: https://forms.gle/7k3L4TjH7RYHit2A7

​​Кратко о работе техдира

​​Александр Поломодов пишет про книгу посвященную тестированию "ATDD. Разработка ПО через приемочные тесты" за авторством Маркуса Гэртнера

Этот труд оставил у меня двойственное впечатление. Например такое, что надпись ATDD большими буквами ни разу не способствует продаже книжки:) Особенно если ты не знаешь, что ATDD расшифровывается как Acceptance Test-Driven Development.
А если серьезно, то книжка достаточно неплохая, но
- отдает немного нафталином (книга 2012 года)
- построена в формате сначала разрабор примеров написания acceptance тестов для парковки, а потом для светофоров. И только после этого идет обсуждение принципов. А я такого не люблю - по-мне так сначала надо дать принципы, а потом обсудить как они работают в конкретной ситуации
Из плюсов, причем больших, следует отметить, что
- автор раскладывает варианты реализации ATDD через BDD, использование табличных форматов (таблицы решений, таблицы запросов, таблицы скриптов) и выделяет автоматизацию через ключевые слова, которые можно выстраивать в иерархии
- отмечает, что ATDD - это разработка ПО, поэтому на связующий код системы приемочных тестов надо писать свои собственные unit-тесты или вообще разрабатывать ATDD через TDD:)
- рассказывает о порочном круге фейла в acceptance тестировании, который начинается с непонятности тестов
- четко говорит про то, что нужен баланс между ручным и автоматизированным тестированием
- неплохо расписывает квадрант тестирования и типы тестов
- дает краткий обзор технологий из 2012 года 😁
- рассказывает о том, как проблемы при написании acceptance тестов сигнализируют, что при реализации кода приложения были потеряны некоторые концепции и предлагает их добавить:)

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

P.S.
Помню, что первый раз с ATDD я столкнулся где-то в те же годы, когда проходил пару курсов университета Berkley про SaaS и использовал BDD при помощи огурца aka Cucumber😁. Кстати, курс был неплохой и был доступен на edx'е по ссылке www.edx.org/course/software-service-uc-berkeleyx-cs169-1x

— Реклама — Пост проплачен —-

Стартап на этапе проработки MVP строит приложение для улучшения коммуникации в семейных парах: https://u-and-me.com/

Основатель @PavelSpin будет признателен за любую обратную связь!

Обновление в Техдирском Треше @ctorecordstrash

​​Идеальный Техдир

Хорошие знакомые тут интересуются, с кем можно посоветоваться на счёт покрытия веб-интерфейса erp системы ui-автотестами? В личку, plz: @ctodsimonov

​​О чем на самом деле говорят в закрытом Техдирском Клубе

​​Про Ценности Компании

Ценности эти бывают самые разные.  И всем набившая оскомину ценность про вовлечённость (т.н. яичница с беконом) и про адекватность при решениях (авианосец и маяк). Мне больше всего нравится ценность про то, что не стоит ныть:

 Озеро. Лебеди разминают крылья.
Красавец-лебедь картинно становится в позы культуриста, растягивая каждое сухожилие, поигрывая мускулами.
Подходит маленькая серая уточка, мнется, начинает (жалобным, слегка писклявым, дрожащим голосом):
- Коне-е-е-е-е-ечно… Наверное, на Юг полетите?..
Лебедь, басом, красиво выгибая спину:
- Ну, да, на Юг. Ага. Там тепло, да.

Уточка:
- Коне-е-е-е-е-ечно… А я ту-у-у-ут останусь… Замерза-а-а-а-ать…
Лебедь:
- Полетели с нами, да. На Юг. Ага. (тянет мускулистую ногу)
Уточка:
- Коне-е-е-е-е-ечно… У вас крылья во-о-о-о-о-он какие… А у меня ма-а-а-а-аленькие, я упаду, разобьюсь и умру-у-у-у-у…
Лебедь:
- Так мы тебя, того. Поддержим, да. Воздушные потоки, понимаешь.
Уточка:
- Коне-е-е-е-е-ечно… А в дороге я проголодаюсь, обессилею, и умру-у-у-у-у…
Лебедь:
- Ну, так будем ловить жуков. Да. Сочных жуков.
Уточка:
- Коне-е-е-е-е-ечно… Жуки большие, у вас клю-ю-ю-ю-ювы вон, какие, а у меня ма-а-а-а-аленький, я не смогу проглотить, подавлю-ю-ю-юсь…
Лебедь (похрустывая, разминает крылья):
- Так мы тебе их того. Разжуем, да. Будешь есть, нормально же.
Уточка:
- Коне-е-е-е-е-ечно…
Лебедь (выпрямившись, глядя на уточку):
- Так. Нах$й.

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

Компания, как государство

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

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

Это признаки авторитарного государства, но даже у самых авторитарных и жестоких государств типа Северной Кореи, такого нет. Есть линейка наказаний от самого минимального до высшей меры.

В России, кстати, высшей мерой явлется пожизненное заключение. И применяется эта мера за самые тяжкие преступлений таких, как убийство.

Так почему же мы все внутри команд такие кровожадные? В чём смысле быть более жестокими внутри компании, чем само наше государство? Почему за ошибку при релизе готовы сразу увольнять?

М?

Если долго-долго-долго,
Что-то делать через жопу,
А потом нормальный способ
Неожиданно включить,
То совсем-совсем недолго,
Подождав всего лишь годик,
То возможно-можно-можно
Можно гемор получить!

Ааа в продакшене база вот такой толщины,
Ааа история данных вот такой глубины,
Ааа, в базу грязными руками,
Ааа, собирай запрос кусками,
Ааа, и огромный геморрой.

(c) Д.Б.

Гендерное про технические команды

В моих командах есть одно любопытное  свойство. Хотя я обычно ориентируюсь только на профессиоанльные качества, но в результате парни у меня почти всегда семейные и этот брак счастливый.

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

UPDATE от @mashintsev: обычно у таких людей маленькие дети и ипотека лет на 30, - самые лучшие мотиваторы для работы

UPDATE2 от @meowthsli: заодно и средство от выгорания!

https://habr.com/ru/company/southbridge/blog/470235/
В этом интервью я очень много рассказываю про разных техдиров: сильных, интересных и глубоких.

Но есть и пара слов про Техдира неудачника - он проиграет любую битву, сольётся и подробно-подробно расскажет акционерам, почему не получилось. С презентацией, отлично поставленной речью и обоснованием. А потом будет долго ходить по конференциям и рассказывать не о том, как строить проекты, а о том, как не надо их строить. Это будет профессионал того, почему проект не получится. Я периодически встречаю таких людей в пич-клубах. Их слова всегда начинают с «Сейчас я расскажу, почему у вас ничего не получится!»

Вот-вот начнется https://www.youtube.com/watch?v=Y9Sxg14pads

Выступаю с докладом «Три команды техдира»

https://youtu.be/llqWlQ5QT8o
Щас Набиуллина в прямом эфире допрашивает замглавы банка китая про запрет биткоина
говорит - ICO запретим

Игорь Мызгин @igormyzgin  пишет, что все сроки, которые могут быть просраны - будут просраны, сроки с железными непросираемыми дедлайнами будут просраны первыми.

(С) неопубликованные аксиомы проджект-манагмента

Фреймворки быстрого старта (ФБС)

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

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

ФБС просто не предназначены для такого, как не предназначен, например, велосипед для того, что в течение дня развести 10 проданных холодильников в разные районы Москвы.

Заставить велосипед перевозить холодильники конечно можно, но дорого. Гораздо дороже, чем просто вызвать грузовое такси, которое перевозит такие грузы сотнями.

Точно также и с ФБС - имеет смысл заранее понять, что будем перевозить. Если это пицца, - то хватит раздать курьерам самокаты.

Когда не стоит выбирать ФБС? Это проистекает из того, каким должен быть бизнес. Функционал фронтенда предназначен для привлечения трафика, а функционал бекенда, - для зарабатывания на этом трафике бабла.

Если ваша история про всякие красивые визуальные истории и полным отсутствием сложной логики с обработкой данных (только сохранить и прочитать), - вам нужен ФБС. Классический пример, - лендосы.

Если же у вас на сервере идёт совмещение сложных логик по доставке, платежам и обработке очень большого массива данных, ФБС станет для вас миной замедленного действия. Пример: сервис по подбору персонала.

UPDATE от Алексея Соломин: Это обычные вопросы долгосрочности и краткосрочности. Касается не только фреймворков, а вообще всего. Нечто, имеющее быстрый порог вхождения с несколькими уже готовыми рецептами позволяет достичь быстрых результатов, но в долгой перспективе заметно уступает иным, противоположным.