А как сейчас с работой?
Другой опыт это стартапы которые принадлежат концернам. Все реально в облаке, и набирается команда которая шарит как надо разрабатывать для облака и контейнеров, как работать в скрам и что такое девопс и пайплайны с гитом. Там совершенно другая песня. И XML там мало кто швыряется
Ну да. Грюне визе всё ж таки. В таких проектах брюзжать приходится. Где твоя документация, а кто тесты писать будет, а кто про безопасность думать будет и те пе. А то молодежь аджайльная шашки наголо и погнали кодить. В аджайле документации нет! И тому подобная ересь.
Но зато свобода от замшелого бетриба, который полгода не может права на дженкинс выдать... Падлы.
в идеальном мире документация и не нужна. ну, когда код красивый и снабжён комментариями и инфраструктура к нему тоже разворачивается из темплейтов - Infrastructure as a Code. и тикеты снабжены комментариями по делу, а не типа "я проверил, у нас всё работает". но поскольку реальное айти состоит на 99.999999% из говна и палок, то приходится носить с собой ещё гигабайты таблиц, графиков, картинок и текста, которые никогда не соответствуют действительности
это потому что выше сидящие манагеры не умеют правильно организовывать процессы. Это обычно концерны. Там вообще все печально. Очень печально. По этому если концерн умный, он оставляет свой классический IT в покое и для новых модных вещей открывает стартапы и всякие спиноффы
я видел как может работать скрам и девопс в стартапе который финансирует концерн и управляет бывший менеджер из гугла, это другое дело. Там только скрам митинги, и никаких других больше. Там инвестор хочет видеть продукт за свои бабки. Там некогда в митингах лишних сидеть.
Ну да. Грюне визе всё ж таки. В таких проектах брюзжать приходится. Где твоя документация, а кто тесты писать будет, а кто про безопасность думать будет и те пе. А то молодежь аджайльная шашки наголо и погнали кодить. В аджайле документации нет! И тому подобная ересь. Но зато свобода от замшелого бетриба, который полгода не может права на дженкинс выдать... Падлы.
да, так и есть. Лично для себя я решил что лучше новые костыли чем старые. В молодежно аджайлном проекте я добавил пару строк в Infrastructure as Code и пайплайн задеплоил мне в облако что я хочу. Да и вообще скраммастерши молодые симпатичные :) А в замшелом бетрибе сидишь ексель заполняешь чтоб тебе может через пол года VM выдали и с пристарелыми девелоперами бодаешься в бесконечных митингах. Получается полный "It works on my machine"
в идеальном мире документация и не нужна.
Не канает. Только в микроскопических проектах без окружения. Комментарии в коде это уже документация. Против которой, собственно, и воют 95% "аджайл-девелоперов". Что характерно, против нарисованных мной деплоймент диаграмм никто не возмущался. Только спрашивали где они лежат.
Пример: наш сервис обращается к рест-сервису. Кто за него отвечает? С кем у нас договор? Кто-то гарантирует 99,999% доступность, и вообще какое у нас SLA? Если он недоступен, что мы делаем? Кому звонить?Или не надо? Переходим на резервный, игнорируем, сами перестаём что-либо обрабатывать? Где всё это документировать?
А так... Чем больше проект тем абстрактнее должен быть входная точка. Легко ссылаться на документацию в коде, если у тебя один микросервис . А когда у тебя их 20? А какой нужен для чего? А есть ли у нас уже что-то что делает ааа? В коде искать ответы на такие вопросы - обалдеешь.
Так что в идеальном мире документации ровно столько, сколько надо. От 10 шкафов для программки, которая будет работать на АЭС до 5 строчек "как запустит и какие параметры" для скриптика delete_all_images.
А, да, для IaC документация архиважна. 2-3 картинки экономят часы и дни, когда разбираешься в новом проекте. А то бывает с переходом на новую версию меняется логика команд. В паппете, по-моему, нас такое подкосило. Была бы парочка диаграммок, в разы веселее переписывать было бы.
насчет документаций и тестов, что там что там жопа. Но чаще это все лучше организовано в аджайлных проектах. Там хоть readme.md бывает или просто спросить можно на прямую в слэк.
в концернах чаще там те кто писал уже ушли/умерли и никто ничего не знает. Может в лучшем случае можно найти 2 летнюю страничку в confluence
Не канает. Только в микроскопических проектах без окружения. Комментарии в коде это уже документация. Против которой, собственно, и воют 95% "аджайл-девелоперов". Что характерно, против нарисованных мной деплоймент диаграмм никто не возмущался. Только спрашивали где они лежат.
Пример: наш сервис обращается к рест-сервису. Кто за него отвечает? С кем у нас договор? Кто-то гарантирует 99,999% доступность, и вообще какое у нас SLA? Если он недоступен, что мы делаем? Кому звонить?Или не надо? Переходим на резервный, игнорируем, сами перестаём что-либо обрабатывать? Где всё это документировать?
А так... Чем больше проект тем абстрактнее должен быть входная точка. Легко ссылаться на документацию в коде, если у тебя один микросервис . А когда у тебя их 20? А какой нужен для чего? А есть ли у нас уже что-то что делает ааа? В коде искать ответы на такие вопросы - обалдеешь.
Так что в идеальном мире документации ровно столько, сколько надо. От 10 шкафов для программки, которая будет работать на АЭС до 5 строчек "как запустит и какие параметры" для скриптика delete_all_images.
А, да, для IaC документация архиважна. 2-3 картинки экономят часы и дни, когда разбираешься в новом проекте. А то бывает с переходом на новую версию меняется логика команд. В паппете, по-моему, нас такое подкосило. Была бы парочка диаграммок, в разы веселее переписывать было бы.
все вопросы выше по доступности и эскаляции и фоллбэкам решаются на ура service team. Они отвечают на эти вопросы, организуют oncall ротации, кому звонить и как
себя вести при инсиденте. Кто координирует устраненние, связывается со стекхолдерами, кто дебажит и тд.Они же потом проводят пост мортемы и вместе с девелоперами составляют юзерсторис. Работает на ура и в той команде было майкросервисов больше 20 плюс одна часть всей команды сидела в мюнхене а другая на украине. Я такой дисциплины и обработки инсидентов не видел ни в одном концерне.
диаграммы кстати всегда делались
Ага. Или "ну это и так всем понятно! У нас это с самого начала проекта!". Не далее как сегодня. Говорю ребята, вот вы тут пишите, "надо проверить верно ли выполнена Lösungsskizze", а что вы в неё пишете вообще? Сразу 5 человек - "ну что за вопросы, это всем понятно! Lösungsskizze должна быть Lösungsskizze, ведь это же Lösungsskizze!". Зашибись.
А теперь, говорю по очереди - вот лично ты что в неё пишешь?
- Краткий план работ, например, имплементировать сервис и написать к нему тест.
- А ты?
- Я только помечаю надо ли менять схему БД.
- А я пишу подробнее в каком классе мне какой метод надо править.
- Ой. Т.е. Всем всё понятно, но все пишут по-разному?
- А это... Таво.... А ты архитектора спроси! Он ещё три года назад обещал документацию написать!
Но, блин, всем всё понятно. Офигеть можно.
Я сейчас влез на галеры. Надо вот из такого страшного проекта попытаться сделать что-то с нормальным QA чтобы хотя бы раз в 2-3 месяца релизить можно было. В идеале, конечно, 1 раз в месяц, но мечтать не вредно. И похоже без того, чтобы выкинуть нахрен 2/3 древних коболистов, ничего не добьёшься...
да, знакомо, задача одна, а сколько людей из команды ни спроси все сделали бы по своему. И когда готово, реквестер в а...уе, потому что он хотел вообще что то другое.
И тут сразу вопрос, а рефайнменты есть ? Скорей всего нет.
есть четко поставленная задача ? есть дефинишн оф дан и дефиишн оф реди ?
Есть задача которая должна быть решена командой ? Значит для нее должна быть юзерстори, а перед тем как ее потащат в спринт вся команда ее прорефайнила и дала эстимейшн сколько времени это займет, все знают о чем речь, как решать и что стекхолдер ожидает на выходе. И тогда таких ситуаций не происходит. И да, за тем чтоб это получалось надо иметь грамотного продактоунера
и скраммастера.
> Я сейчас влез на галеры. Надо вот из такого страшного проекта попытаться сделать что-то с нормальным QA чтобы хотя бы раз в 2-3 месяца релизить можно было. В идеале, конечно, 1 раз в месяц, но мечтать не вредно. И похоже без того, чтобы выкинуть нахрен 2/3 древних коболистов, ничего не добьёшься...
могу сразу сказать что мало что выйдет, в пустую потраченое время и деньги. Опыт показал что надо менять всю команду. Одному бодаться нет смысла
Коварный вопрос - а они откуда знают?
да все просто, они сами не знают, они по началу исходят из общепринятых правил что например фоллбэки нужны и что нуржен онколл. они поводят интервью с тимлидом каждой команды девелоперов которые пишут майкросервис.
Создается первая версия сценария кому звонить и как себя вести. После первого инсидента продводится анализ и самой ошибки и что было не правильно сделано при ее устранении. И так как они же сами проводят постмортемы, в то время как девелоперы фиксят баги, service team подгоняет процесс. Получается continuous improvement. Но это работает только если у тебя дисциплинированая команда. И таки я такое в живую видел
Ага. Или "ну это и так всем понятно! У нас это с самого начала проекта!". Не далее как сегодня. Говорю ребята, вот вы тут пишите, "надо проверить верно ли выполнена Lösungsskizze", а что вы в неё пишете вообще? Сразу 5 человек - "ну что за вопросы, это всем понятно! Lösungsskizze должна быть Lösungsskizze, ведь это же Lösungsskizze!". Зашибись.
А теперь, говорю по очереди - вот лично ты что в неё пишешь?
- Краткий план работ, например, имплементировать сервис и написать к нему тест.
- А ты?
- Я только помечаю надо ли менять схему БД.
- А я пишу подробнее в каком классе мне какой метод надо править.
- Ой. Т.е. Всем всё понятно, но все пишут по-разному?
- А это... Таво.... А ты архитектора спроси! Он ещё три года назад обещал документацию написать!
Но, блин, всем всё понятно. Офигеть можно.
Я сейчас влез на галеры. Надо вот из такого страшного проекта попытаться сделать что-то с нормальным QA чтобы хотя бы раз в 2-3 месяца релизить можно было. В идеале, конечно, 1 раз в месяц, но мечтать не вредно. И похоже без того, чтобы выкинуть нахрен 2/3 древних коболистов, ничего не добьёшься...
Почему вас до сих пор не уволили? Вы не решили проблему не только за 15 минут! Вы и за 2-3 месяца её не решили! Или вы сами из тех, кто увольняет?
да все просто, они сами не знают, они по началу исходят из общепринятых правил что например фоллбэки нужны и что нуржен онколл. они поводят интервью с тимлидом каждой команды девелоперов которые пишут майкросервис.
Это всё задачи для "от сеньёра и выше"? Джуниоры и миддлы туда не лезут, а просто кодят свой узкий участок?
Элементарная задачка.
Требуется - добавлять какие-то фрагменты в ХМЛ файл.
Для простоты - пусть они будут одинаковые по структуре ХМЛ.
Вроде как все работает, но... медленно. И чем дальше - тем медленнее.
Твоя работа - вместо 10 минут на добавление одного фрагмента сделать... хммм... 100 милисекунд... хотя, пожалуй, много.. 20-ти хватит...
Да, пока не забыл - работа с файлом остается. Т.е. если рубильник смайнают - все должно работать без потерь...
И, заметь, никаких ограничений не ставится - хочешь стандартные либы - будь ласка, хочешь штаны через голову - милости просим... только выдай 20 милисек на добавление... и это... на доработку/фих тебе пара часов,
Смотря в какое место добавлять. Может, там удобно поставить метку и просто открыть файл как текстовый, без построения DOM в памяти, или даже стримить его кусками, пока не найдёшь метку, затем добавить что надо после метки тоже кусок текста и сохранить файл. Думаю, гигабайтный может быть обработан за секунды. Насчёт 100мс не знаю - у вас файл же на диске лежит, а свойства вашего хранилища неизвестны. Может, там убитые и вусмерть фрагментированные HDD.
Есть ещё такая штука StAX - Wikipedia или SAX, но вот тут пишут, что для модификации XML лучше подходит всё же построение DOM.
Вообще, это какой-то бред - хранить многогиговые XML. Это формат с избыточными данными - одни закрывающие теги с повторением названия открывающего чего стоят. Сжать всё это дерьмо или сразу использовать формат без дублирования. Но сжатое потом разжать надо и снова сжать - лишнии операции. Может, проблема в генераторе таких XML и то, куда и как их хранят? А то кто-то наговнокодил, а вас потом подрывают вдруг и неожиданно провести блицкриг врукопашную против танков (15 минут на многогиговый XML)?
Это всё задачи для "от сеньёра и выше"? Джуниоры и миддлы туда не лезут, а просто кодят свой узкий участок?
я не в курсе по каким критериям выбирали serivce team, в прошлом девелоперы но сказать что очень сеньеры тоже нельзя. Но дело совсем не в сеньерности. Тут дело в том что исходная позиция при начале проекта это общепринятые бест прэктисес и изначальное понимание что ошибки будут сделаны и это нормально. И потом со временем процессы после каждой итерации подгоняются под конкретно наши реалии. Вот в принципе и все.
Секрет это просто дисциплина и быстрая реакция на ошибки.
а причем тут гит ?
Если девелопер тестирует свой код на лептопе стартуя докер контейнер, потом комитит в репозиторий который пайплайном будет залит на k8s в облаке, это очень не странно что вероятность того что это в облаке не заработает очень велика. Но когда говоришь такому девелоперу что в тестовом кластере не работает, часто ответ что, а у него на лептопе работает. Это как в комиксе "ну давай тогда твой лептоп установим в продакшн"