OS
Ну и один человек может совмещать несколько ролей, так же как и одна роль может быть поделена между разными людьми.
Size: a a a
2019 June 27
V
тут сколько людей - столько и мнений :) ещё не разу не было, чтобы я зашёл в чатик узких специалистов и они бы там раз в неделю не посрались на тему, чем же именно должны заниматься эти специалисты: тимлиды, СТО, архитекты, деврелы, HR-ы и т.д.
А. Я думал - вдруг хорошие устоявшиеся практики/договоренности есть..
OS
По сути, важно лишь чтобы все активности выполнялись в срок и с меньшим скрипом, по-возможности, а уж как это накрошено - вопрос второй
V
Ну и один человек может совмещать несколько ролей, так же как и одна роль может быть поделена между разными людьми.
Тогда почитать/послушать про активности и про роли, без относительно людей
GM
А. Я думал - вдруг хорошие устоявшиеся практики/договоренности есть..
наверняка есть, в больших компаниях, вопрос в том как это к твоей реальности применимо?
OS
OS
как минимум, компании различаются по уровню зрелости и по размеру
V
я кстати понял что ты хотел сказать. Вообще архитектором принято считать человека который умеет сложные системы строить. Понятно что тимлид в чем то арихектор для своего сервиса, но он не видит картину целиком.
Да, верно. И SRE архитект для своей команды/сервисов, что он поддерживает, на разных уровнях.
Ещё же часто нехватка людей/кадров, и да, один берет несколько ролей
Ещё же часто нехватка людей/кадров, и да, один берет несколько ролей
OS
если компания закорузлая и огромная, скорее всего у каждого человека будет одна узкая роль, названий должностей будет 70, число уровней иерархии - минимум 7
OS
в стартапе будет просто: Девелоперы которые пишут, Главный который говорит что писать и Девопс, который делает всё остальное
KT
а это прям осознанно было или типа как мы искали архитектора искали и поняли что этими поисками можно заниматься вечно, а вопросы надо решать уже сейчас?
Там долгая история, так что лучше при встрече
KT
можно в рамках DevOpsConf )
V
бесконфликтно говорить "нет"
А вот как..?)
Если говоришь на ревью - вот этот код - очень коричневого цвета и трудно поддерживаемый. Давай улучшили вот так и вот так.
А в ответ - да ну, забей, и так сойдёт. Хочешь - сам сделай )
Если говоришь на ревью - вот этот код - очень коричневого цвета и трудно поддерживаемый. Давай улучшили вот так и вот так.
А в ответ - да ну, забей, и так сойдёт. Хочешь - сам сделай )
OS
Код ревью - просто плохая практика, вот и всё :)
AS
А вот как..?)
Если говоришь на ревью - вот этот код - очень коричневого цвета и трудно поддерживаемый. Давай улучшили вот так и вот так.
А в ответ - да ну, забей, и так сойдёт. Хочешь - сам сделай )
Если говоришь на ревью - вот этот код - очень коричневого цвета и трудно поддерживаемый. Давай улучшили вот так и вот так.
А в ответ - да ну, забей, и так сойдёт. Хочешь - сам сделай )
а какие договоренности в команде? есть стандарты или каждый пишет как хочет?
V
Код ревью - просто плохая практика, вот и всё :)
Ну, всмысле. Вот у меня парочка Джуниоров. И как нужно..?)
V
а какие договоренности в команде? есть стандарты или каждый пишет как хочет?
Задокументированных формализованных в Вики - нет, ток здравый смысл.
Ну и, как делать стандарты на то, чтобы не писали 200-символьные однострочники на python/bash ?)
Ну и, как делать стандарты на то, чтобы не писали 200-символьные однострочники на python/bash ?)
AS
Задокументированных формализованных в Вики - нет, ток здравый смысл.
Ну и, как делать стандарты на то, чтобы не писали 200-символьные однострочники на python/bash ?)
Ну и, как делать стандарты на то, чтобы не писали 200-символьные однострочники на python/bash ?)
линтер в CI
AS
он сам все объяснит)
AS
у нас превышение длины строки - ошибка сборки