Если кто-то думает, что архитектурной астронавтикой занимаются исключительно в ИТ, то ответ — нет, не только. Вот пример из Яндекс.Еды, как дизайнер потратил несколько месяцев на решение, которое никому не нужно, но сам дизайнер так его полюбил, что не готов отказаться. Первая картинка — мотивация глазами дизайнера, вторая — отзывы на результат.
Любопытный анализ про STEM. Конечно, не хватает фактологической базы. Но в любом случае, размышления интересные https://www.vtimes.io/2021/01/11/fiziki-i-liriki-kem-bit-a2418
Об эмерджентность
Когда говорят про сложные системы, упоминают их важное отличительное свойство "эмерджентность": это когда у системы появляются свойства, которые сложно или невозможно предсказать, изучая части системы по отдельности, потому что каждая часть не обладает ни свойством, ни даже предпосылками к нему. Понятный пример явления - смерчи. При этом почему-то всегда вспоминают положительные качества, а вот то, что эмерджентное свойство сложных ИТ систем — а они все сейчас только усложняются — "ломаться как говно" по любому поводу почему-то относят к устранимым недостаткам. Подозреваю, что это ошибка.
Нам нужно более простое ИТ, пора возвращаться к истокам.
Когда говорят про сложные системы, упоминают их важное отличительное свойство "эмерджентность": это когда у системы появляются свойства, которые сложно или невозможно предсказать, изучая части системы по отдельности, потому что каждая часть не обладает ни свойством, ни даже предпосылками к нему. Понятный пример явления - смерчи. При этом почему-то всегда вспоминают положительные качества, а вот то, что эмерджентное свойство сложных ИТ систем — а они все сейчас только усложняются — "ломаться как говно" по любому поводу почему-то относят к устранимым недостаткам. Подозреваю, что это ошибка.
Нам нужно более простое ИТ, пора возвращаться к истокам.
Об интеллект
В ФБ давеча замелькали курсы от "основателя компании DBrain, миллионера, эксперта по ИИ/AI Дмитрия Мацкевича". Ну читает и читает, что удивительного, а оказалось — ничего подобного, какая-то брокерская компания сделала достаточно качественные deep fake видео, и "креатив", и лендинг тоже на уровне, чтобы продвигать свой продукт на базе конешноже ИИ.
Вот так вот ИИ-шнику по жопе шлепнуть при помощи ИИ это, господа, КРАСИВО!
В ФБ давеча замелькали курсы от "основателя компании DBrain, миллионера, эксперта по ИИ/AI Дмитрия Мацкевича". Ну читает и читает, что удивительного, а оказалось — ничего подобного, какая-то брокерская компания сделала достаточно качественные deep fake видео, и "креатив", и лендинг тоже на уровне, чтобы продвигать свой продукт на базе конешноже ИИ.
Вот так вот ИИ-шнику по жопе шлепнуть при помощи ИИ это, господа, КРАСИВО!
Об новые технологии
Если вы когда-то встречали в резюме запрос вида "хочу работать с новыми технологиями", то это надо понимать так: я хочу в свое удовольствие на работе ковырять и осваивать кафку, докер, кубернетес, чтобы через полгода-год на +50% к окладу уйти к бОльшим дуракам, чем вы. А вовсе не то, что с помощью новых технологий можно работать быстрее, эффективнее, дешевле строить системы, которые работают надежнее.
Исключения бывают, но я их видел очень редко.
Если вы когда-то встречали в резюме запрос вида "хочу работать с новыми технологиями", то это надо понимать так: я хочу в свое удовольствие на работе ковырять и осваивать кафку, докер, кубернетес, чтобы через полгода-год на +50% к окладу уйти к бОльшим дуракам, чем вы. А вовсе не то, что с помощью новых технологий можно работать быстрее, эффективнее, дешевле строить системы, которые работают надежнее.
Исключения бывают, но я их видел очень редко.
Об документацию
В те стародавние времена, когда самодельный софт ставился долго и мучительно, существовала хорошая практика иметь подробный, обстоятельный документ "Инструкция по сборке и развертыванию", в котором раскрывались не только шаги и команды, как собрать и задеплоить софт, а и детали, доносящие до инженера по сборке и эксплуатации общий замысел системы, хотя бы на уровне структуры, а через него — и по функциям.
Комплект из "Инструкции по сборке" и "Руководства пользователя" закрывал вообще 80%+ процентов вопросов по всем темам, от функциональности до внутреннего устройства.
Теперь софт пишут по аджайлу, а развертывают докером, и в инструкции по развертыванию часто идет одна команда - как стартовать докер образ, и креды к репозиторию образов. Вот такой внезапный удар в дупло, усложняющий эксплуатацию.
А вы думали, большим компаниям сильно надо, чтобы у вас получалось?
В те стародавние времена, когда самодельный софт ставился долго и мучительно, существовала хорошая практика иметь подробный, обстоятельный документ "Инструкция по сборке и развертыванию", в котором раскрывались не только шаги и команды, как собрать и задеплоить софт, а и детали, доносящие до инженера по сборке и эксплуатации общий замысел системы, хотя бы на уровне структуры, а через него — и по функциям.
Комплект из "Инструкции по сборке" и "Руководства пользователя" закрывал вообще 80%+ процентов вопросов по всем темам, от функциональности до внутреннего устройства.
Теперь софт пишут по аджайлу, а развертывают докером, и в инструкции по развертыванию часто идет одна команда - как стартовать докер образ, и креды к репозиторию образов. Вот такой внезапный удар в дупло, усложняющий эксплуатацию.
А вы думали, большим компаниям сильно надо, чтобы у вас получалось?
Без темы
Видели в интернете одно время было популярно забавное увлечение: додумывать пословицы, как они были "на самом деле"? При этом смысл менялся.
Например: "кто старое помянет, тому глаз вон -- а кто забудет, тому оба".
Или: "рыбак рыбака видит издалека -- и стороной обойдет".
Как минимум, это было интересное, нестандартное упражнение. Часто такое упражнение проделываете?
А в жизни такого -- прямо навалом. Например, известное утверждение, мол, надо визуализировать успешный успех, чтобы его приблизить. Попробуйте прям щас свой суперприбыльный бизнес визуализировать, м?
Ну, на этом месте все сразу начинают визуализировать, как они на райских островах отдыхают, преимущественно, лёжа. Понятно, что все соглашаются, что это как бы бесполезно, от такой визуализации теплее не станет.
А вот можно было иначе: визуализировать, как именно процесс управления большой компанией выглядит, подробно, в деталях. Тут в голову придет, что и управляющего партнера можно позвать, и как владение надо структурировать -- через оффшоры, через группу компаний, или как-то еще, и как производство от продаж отделить для оптимизации налогов, как интеллектуальную собственность зарегистрировать. И что много времени надо потратить, чтобы найти подходящих людей, и что бизнес это часто улаживание разных "кря-кря" от недовольных сотрудников. Просто надо правильно продолжить визуализировать. Но увы.
Или вот еще: чувак, я слышал, ты в школе арифметику учил? А ну, посчитай пример с канала "Хулиномики": "Илон Маск внёс на брокерский счёт 5000 долларов. Он купил 300 акций Теслы по $30 за штуку. Минимальная маржа у брокера - 30%. Не учитывая комиссий и процентов по займу, при какой цене акций он получит маржин-колл?". На ответ дается три-четыре минуты.
Не могу в уме посчитать, сколько банку должен буду, если занял Х, а возвращать буду так-то и так-то? Так я, выходит, не арифметику учил, я опять неправильными визуализациями страдал, дурачок. Зачем мне интегралы, если меня примеры из жизни в тупик ставят?
И так во многом.
Видели в интернете одно время было популярно забавное увлечение: додумывать пословицы, как они были "на самом деле"? При этом смысл менялся.
Например: "кто старое помянет, тому глаз вон -- а кто забудет, тому оба".
Или: "рыбак рыбака видит издалека -- и стороной обойдет".
Как минимум, это было интересное, нестандартное упражнение. Часто такое упражнение проделываете?
А в жизни такого -- прямо навалом. Например, известное утверждение, мол, надо визуализировать успешный успех, чтобы его приблизить. Попробуйте прям щас свой суперприбыльный бизнес визуализировать, м?
Ну, на этом месте все сразу начинают визуализировать, как они на райских островах отдыхают, преимущественно, лёжа. Понятно, что все соглашаются, что это как бы бесполезно, от такой визуализации теплее не станет.
А вот можно было иначе: визуализировать, как именно процесс управления большой компанией выглядит, подробно, в деталях. Тут в голову придет, что и управляющего партнера можно позвать, и как владение надо структурировать -- через оффшоры, через группу компаний, или как-то еще, и как производство от продаж отделить для оптимизации налогов, как интеллектуальную собственность зарегистрировать. И что много времени надо потратить, чтобы найти подходящих людей, и что бизнес это часто улаживание разных "кря-кря" от недовольных сотрудников. Просто надо правильно продолжить визуализировать. Но увы.
Или вот еще: чувак, я слышал, ты в школе арифметику учил? А ну, посчитай пример с канала "Хулиномики": "Илон Маск внёс на брокерский счёт 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 "офис"/"дом".
Можно ли лучше? Можно. Но вряд ли за счет перевода на удаленку.
Мы не нанимаем дистанционных сотрудников. Ну, таких, которые сидят дома или в коворкинге, и индивидуально работают на нас. У подхода есть и плюсы, и минусы, мы решили, что минусы перевешивают, пока мы можем нанять локальных. Хочу объяснить, почему.
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 "офис"/"дом".
Можно ли лучше? Можно. Но вряд ли за счет перевода на удаленку.
Inc. Russia
83% удалённых сотрудников обманывают коллег и руководителей по поводу работы
Сервис по поиску работы JobList.com опросил 958 удалённых сотрудников. 83% респондентов признались, что врали, работая из дома. Чаще всего это делали руководители (92%), менеджеры (90%) и сотрудники младшего звена (79%). Каждого третьего из них в какой-то…
Джентльмены, обращаюсь за советом.
Мне нужен простой гоночный квадрокоптер, не из тех, что продаются как девайс, а собранный на раме: отдельно моторы, регуляторы скорости, полетный контроллер и т.п. FPV-камера мне не нужна, только аппаратура управления.
С моей стороны есть требование только к полетному контроллеру - он должен быть конкретным по выбору, остальное уже по лучшим практикам рынка. Хотел бы получить его в сборе. Что можете посоветовать? Есть готовый kit?
Если кто-то сможет за деньги купить, собрать, и передать, готов пообсуждать условия в личке.
Мне нужен простой гоночный квадрокоптер, не из тех, что продаются как девайс, а собранный на раме: отдельно моторы, регуляторы скорости, полетный контроллер и т.п. FPV-камера мне не нужна, только аппаратура управления.
С моей стороны есть требование только к полетному контроллеру - он должен быть конкретным по выбору, остальное уже по лучшим практикам рынка. Хотел бы получить его в сборе. Что можете посоветовать? Есть готовый kit?
Если кто-то сможет за деньги купить, собрать, и передать, готов пообсуждать условия в личке.
Об микросервисы в который раз
Ну, хорошо, всем продали микросервисы: дескать, и устройство системы понятнее из-за них, и two pizza team вообще стандарт в Гугл ИТ, значит, и нам надо тоже. И код можно писать на самом подходящем языке: хочешь, пишешь на php, не хочешь, пишешь на nodejs, что очень удобно (особенно потом сопровождать комплекс, написанный на 10 языках). А еще можно переписать за две недели маленький микросервис, любой. Ну круто же, правда?! А еще архитектура очень отказоустойчивая, и если один сервис упал, то остальные выживут (на практике - не работает никогда). И самое главное - можно МАСШТАБИРОВАТЬ приложения! О том, что монолит тоже можно масштабировать, тем более сейчас, когда железо ничего не стоит, молчат.
Но это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:
1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.
2. Найм. В ситуации, когда средней компании найти хорошего разработчика за праздник, в случае микросервисной архитектуры можно нанимать вообще любых программистов, которые подвернулись, а не те, которые подходят по стеку или согласны работать с легаси и т.п.
Эти две причины пересиливают все сложности, связанные с МСА. А сложностей немало, от оркестрации до смены парадигмы владения системами.
Все, больше на самом деле ни зачем не надо. А, еще маленькое замечание: проще нанимать людей, потому что "у нас такие же крутые технологии, как в Гугле, так что мы будем платить поменьше".
Ну, хорошо, всем продали микросервисы: дескать, и устройство системы понятнее из-за них, и two pizza team вообще стандарт в Гугл ИТ, значит, и нам надо тоже. И код можно писать на самом подходящем языке: хочешь, пишешь на php, не хочешь, пишешь на nodejs, что очень удобно (особенно потом сопровождать комплекс, написанный на 10 языках). А еще можно переписать за две недели маленький микросервис, любой. Ну круто же, правда?! А еще архитектура очень отказоустойчивая, и если один сервис упал, то остальные выживут (на практике - не работает никогда). И самое главное - можно МАСШТАБИРОВАТЬ приложения! О том, что монолит тоже можно масштабировать, тем более сейчас, когда железо ничего не стоит, молчат.
Но это все selling points для недоверчивых технарей, а я расскажу, почему на самом деле бизнес выбирает микросервисы. Причин всего две:
1. Быстрая проверка гипотез, которые в 9 из 10 случаев проваливаются - да, продакт-менеджеры тоже не боги. В случае монолита вы стоите перед непростым выбором: или вкладываться по полной в эксперимент (дизайн, код, тесты), который, скорее всего, будет выброшен, или на коленке слепить то, что рискует выстрелить, и тогда с этим поделием придется жить вечно в монолите. Какой вариант хуже? Оба хуже. В случае с микросервисами эксперименты не сильно трогают ядро системы, которая кормит всю компанию и их семьи.
2. Найм. В ситуации, когда средней компании найти хорошего разработчика за праздник, в случае микросервисной архитектуры можно нанимать вообще любых программистов, которые подвернулись, а не те, которые подходят по стеку или согласны работать с легаси и т.п.
Эти две причины пересиливают все сложности, связанные с МСА. А сложностей немало, от оркестрации до смены парадигмы владения системами.
Все, больше на самом деле ни зачем не надо. А, еще маленькое замечание: проще нанимать людей, потому что "у нас такие же крутые технологии, как в Гугле, так что мы будем платить поменьше".
Потратил пару вечеров на то, чтобы разобраться со стянутыми из разных мест интернета библиотеками sensor fusion по алгоритму Махони, а он все не работает. Оказалось, что его реализации на гитхабах содержат мелкие ошибки, заботливо опенсорснутые авторами. Сегодня почитал оригинальные пейперы и методические рекомендации, сократил код в полтора раза, и все заработало. Опенсорс - сила! (нет)
Интересный казус с GPL v3 в российском правовом поле: в России признают только переведенные на русский документы, а GPL явно выражается, что изменения в нее, в том числе переводы на другой язык, ее нарушают.
Поэтому тем, кто выбрал этот путь, придется выпускать хитрый dual-licensed, который все равно будет нарушать GPL на территории России, но будет валиден в отношении нее на других территориях
Поэтому тем, кто выбрал этот путь, придется выпускать хитрый dual-licensed, который все равно будет нарушать GPL на территории России, но будет валиден в отношении нее на других территориях
Об язык С
Существует некоторая легенда, что язык Си предназначен для системного программирования.
На самом деле, нет. Для системного программирования он оказался предназначен, потому что любое программирование в те годы было системным, кроме рассчетов баллистики на Фортране.
На самом деле, Си лучше всего подходит для подкрепления разработки Unix-way, просто об этом забыли. Так что на нем писать? Высокоэффективные портабельные одно-страничные и одно-файловые утилиты, которые соединяются друг с другом клеем в виде пайпов и скриптов. Для этого в Си есть:
1. Независимая (а не раздельная) компиляция, модуль = файл. Поэтому многофайловые проекты компилируются небыстро, т.к. по умолчанию надо оттранслировать все .h-файлы заново.
2. Отсутствие работы со строками. В системных утилитах строки нужны для работы с файлами, а на это уже есть posix api, больше ничего не нужно.
3. Неудобство в кроссмодульных связях. Сам язык никак не помогает связать модули в единое, все это возложено на линкер, и есть минимальный инструмент языка в виде extern. Все, больше ничего нет.
4. В юниксе все - это файл, в Си все - есть указатель. Хочешь мутабельную или иммутабельну ссылку? Держи указатель. Хочешь привязаться к адресу в памяти для ввода-вывода? be Держи указатель. Хочешь посчитать размеры? Держи адресную арифметику на указателях. А для коротких мелких утилит больше ничего и не надо.
5. Даже компиляция родным инструментом (gcc) идеально делается для однофайлового проекта, без всяких мейков: "gcc main.c", и все. Полученный a.out можно запускать.
В этом смысле Rust его никогда не вытеснит, потому что решает совсем другую проблему и не является конкурентом.
Существует некоторая легенда, что язык Си предназначен для системного программирования.
На самом деле, нет. Для системного программирования он оказался предназначен, потому что любое программирование в те годы было системным, кроме рассчетов баллистики на Фортране.
На самом деле, Си лучше всего подходит для подкрепления разработки 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, альтернативы есть.
Я уже как-то писал, что недолюбливаю git. Разумеется, я не уникален в этом. Некто Ричард Хипп - вы его могли знать, он там одну небольшую малоизвестную любительскую БД написал - sqlite - однажды решил, что так жить нельзя, и написал свою scm - FOSSIL. Что в ней интересного:
1. Это scm для людей. Там всего один бинарник, и вся метаинформация транзакционно хранится - вы не поверите - в sqlite на дисочке.
2. Ничего не надо устанавливать в систему, достаточно drop-copy бинаря.
3. В систему встроен веб-сервер для GUI, а fossil достаточно умен, чтобы понять, что директория содержит markup-файлы, таким образом, к коду в этом же репозитории можно вести и просматривать документацию, и все это локально.
4. GIT все равно все используют как централизованную SCM с главным репозиторием, так что fossil по умолчанию так и работает: делаешь коммит, и оно тут же отправляется в главный remote. Это не очень подойдет для больших команд, но нормально для trunk-based development, а к тому же не плодит бессмысленные мерж-коммиты.
В общем, если хочется взять и начать работать локально, и бесит git, альтернативы есть.
В современной разработке принято скептически относиться к наследию прошлого. Это касается и знаменитого "ГОСТ 34". Знатоки амазона и специалисты по кубернетесам уверены, что это устарело, не нужно, да и вообще олицетворяет все самое плохое, что ассоциируется со словом "водопадная модель разработки". Хочу в нескольких важных пунктах описать, что такое ТЗ по ГОСТ 34.602-89, и почему он никак не устарел.
1. Начнем с заголовка. ГОСТ 34 звучит так: "Техническое задание на создание автоматизированной системы". Это не спецификация на систему (SRS, требования к ПО), а спецификация на процесс ее создания. То есть в этом документе описывается не столько система, сколько весь development lifecycle, связанный с конструированием и запуском. И согласно этому, там есть место для:
- замысла системы
- решаемых проблем
- оснований для создания системы: кто заинтересован, кто платит, как проверить, что сделали то, что нужно
- план выполнения работ: конструирование, пилотирование, сопровождение, и стоимость работ.
Если вы не можете перед началом работ описать проблемы, которые собираетесь решить, и как проверить, что результаты достигнуты, то дело, вероятно, совсем не в ГОСТе.
2. Если внимательно почитать сам стандарт, то в п. 2.2 можно найти замечательное (неточная цитата) "по согласованию сторон, допустимо переименовывать разделы, объединять, вводить новые и опускать неактуальные". Ну вы поняли, да? :) Можно оставить только нужные вам разделы, и это все равно по духу останется ГОСТом.
3. Поклонников Agile пугает пункт о плане: как можно предположить план, начиная разработку, ведь по канону план каждой итерации должен составляться по окончании предыдущей, и никто не знает, что будет делаться дальше, рынок покажет? И на это есть ответ. В плане пишем короткое и понятное: "в соответствии с ведомостью исполнения работ". Всё, работаем, ведомость заполняем из вашей скрам-тикетницы.
4. Что насчет требований, документации? Многие мыслят ТЗ в ГОСТ 34 как огромный талмуд с требованиями, а какие в Agile предварительные требования? И это легко решается. Вместе с замыслом работ у вас есть описание, что хочется получить, в конструктивной форме. Нарезаете его на сценарии, запускаете в разработку. Из этих сценариев, кстати, составляется документ "Программа и методика испытаний" для сдачи - пожалуй, единственный обязательный документ стандарта. Процесс сдачи это кумулятивное демо, а к демо в скраме относятся крайне благосклонно.
Остальная документация носит рекомендательный характер, можете ее писать, или не писать, можно в вики, можно в тикетах, где угодно.
—
В общем, оригинальная задумка ТЗ по ГОСТ 34 это не про требования. Это про то, как управлять разработкой, причем так, чтобы каждый инженер проекта смог внести максимальный вклад.
1. Начнем с заголовка. ГОСТ 34 звучит так: "Техническое задание на создание автоматизированной системы". Это не спецификация на систему (SRS, требования к ПО), а спецификация на процесс ее создания. То есть в этом документе описывается не столько система, сколько весь development lifecycle, связанный с конструированием и запуском. И согласно этому, там есть место для:
- замысла системы
- решаемых проблем
- оснований для создания системы: кто заинтересован, кто платит, как проверить, что сделали то, что нужно
- план выполнения работ: конструирование, пилотирование, сопровождение, и стоимость работ.
Если вы не можете перед началом работ описать проблемы, которые собираетесь решить, и как проверить, что результаты достигнуты, то дело, вероятно, совсем не в ГОСТе.
2. Если внимательно почитать сам стандарт, то в п. 2.2 можно найти замечательное (неточная цитата) "по согласованию сторон, допустимо переименовывать разделы, объединять, вводить новые и опускать неактуальные". Ну вы поняли, да? :) Можно оставить только нужные вам разделы, и это все равно по духу останется ГОСТом.
3. Поклонников Agile пугает пункт о плане: как можно предположить план, начиная разработку, ведь по канону план каждой итерации должен составляться по окончании предыдущей, и никто не знает, что будет делаться дальше, рынок покажет? И на это есть ответ. В плане пишем короткое и понятное: "в соответствии с ведомостью исполнения работ". Всё, работаем, ведомость заполняем из вашей скрам-тикетницы.
4. Что насчет требований, документации? Многие мыслят ТЗ в ГОСТ 34 как огромный талмуд с требованиями, а какие в Agile предварительные требования? И это легко решается. Вместе с замыслом работ у вас есть описание, что хочется получить, в конструктивной форме. Нарезаете его на сценарии, запускаете в разработку. Из этих сценариев, кстати, составляется документ "Программа и методика испытаний" для сдачи - пожалуй, единственный обязательный документ стандарта. Процесс сдачи это кумулятивное демо, а к демо в скраме относятся крайне благосклонно.
Остальная документация носит рекомендательный характер, можете ее писать, или не писать, можно в вики, можно в тикетах, где угодно.
—
В общем, оригинальная задумка ТЗ по ГОСТ 34 это не про требования. Это про то, как управлять разработкой, причем так, чтобы каждый инженер проекта смог внести максимальный вклад.