Здравствуйте, rm822, Вы писали:
R>1 и абсолютно фундаментальное требование к любому руководителю — способность нанять себе комманду. Поэтому первый вопрос к лиду — сколько времени ему потребуется чтобы нанять 1 разработчика. Сколько это будет стоить и займет времени. R>Не знает, жует сопли — не лид.
Наем разработчиков — не задача лида. Для этого HRы есть. От лида нужно только понимание, сколько команде нужно разработчиков и каких.
R>3е — понимание экономики ПО, сколько тестеров нужно на 1 программиста, сколько тех-писов, как делится тратится время и ресурсы в разбивке дизайн/программирование/тестирование/поддержка. Не понимает, значит не сможет сделать нормальные оценки, не сможет поставить продукт приличного качества в срок — не лид.
Только выделенное имеет какой-то смысл без знания процесса принятого в конкретной компании.
R>-код ревью не связан с архитектурой от слова совсем
Связано. Как минимум, интерфейсы модулей проверяются на соответствие архитектуре в процессе ревью.
Здравствуйте, rm822,
R>3е — понимание экономики ПО, сколько тестеров нужно на 1 программиста, сколько тех-писов, как делится тратится время и ресурсы в разбивке дизайн/программирование/тестирование/поддержка. Не понимает, значит не сможет сделать нормальные оценки, не сможет поставить продукт приличного качества в срок — не лид.
V_S>Только вот этим должен заниматься не лид, а пиэм.
Взгляни правде в глаза. ПМ — это роль, которая как отдельный человек уже мало где существует
— большинство проектов мелкие, буквально 2-5 разработчиков, на полноценного ПМ-а нужно как минимум 15
— скрам очень активно используется, разрабы работают напрямую с заказчиком. Уже даже сбер-тех его запускает, что про остальных говорить
поэтому _роль_ ПМа очень часто исполняет тим лид, отсюда и требования
Это 15 лет назад была тема с ПМом, архитектором, квадратиками на UML, а программисты только код писали
Здравствуйте, neFormal, Вы писали: ET>>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой? F>ревью имеет смысл делать, чтобы удержать код в рамках одной архитектуры, одного дизайна.
Ревью имеет смысл делать чотбы найти и исправить ошибки на наиболее ранней стадии и как результат сделать работу наиболее эффективной. Если ошибку нашли на этапе код ревью то ее исправили и все. Чем дольше она находится в коде в процессе разработки тем дороже ее найти, воспризвести, отдебажить и исправить.
Хорошая архитектура, плохая, в рамках или нет — к код ревью перпендикулярно. Даже наоборот, при хорошей (понятной и документированной) архитектуре и "хорошем" процессе, сам разработчик может скажем покрыть свой код юнит-тестами на основании уже сформулированных системных требоний и определенных интерфейсов, и соответственно эфффективность код ревью неврелика ( в смысле вероятность что ревьюер что-то отыщет мала). Но в этом случае возможно стоит заревьюить юнит тесты. Если же архитектура плохаа, и судя по самому факту вопроса и процесс возможно не на высоте, то вводить ревью может быть и эффективно. Скажем Вася, критически просматривая код Пети не только найдет явно видимые ошибки, пропущенные автором, но и возможно посоветует "вот ты тут вызываешь foo() из пакета GovnoCode, так имей ввиду что она кривая и делает то и то нехорошо, тут лучше сдеалть так..
Здравствуйте, qqqqq, Вы писали:
Q>Хорошая архитектура, плохая, в рамках или нет — к код ревью перпендикулярно.
а вот и нет :P
Q>Даже наоборот, при хорошей (понятной и документированной) архитектуре и "хорошем" процессе, сам разработчик может скажем покрыть свой код юнит-тестами
и накатать что-то, что не вписывается в общую схему. вчера прочитал в интернетах, а сегодня принёс на проект.
на текущем этапе не страшно, но в дальнейшем принесёт проблем, когда две архитектурные идеи заметно разойдутся. таким образом это равнозначно ошибке.
Q>Если же архитектура плохаа, и судя по самому факту вопроса и процесс возможно не на высоте, то вводить ревью может быть и эффективно. Скажем Вася, критически просматривая код Пети не только найдет явно видимые ошибки, пропущенные автором, но и возможно посоветует "вот ты тут вызываешь foo() из пакета GovnoCode, так имей ввиду что она кривая и делает то и то нехорошо, тут лучше сдеалть так..
у них там архитектура была плохая. про процесс ничего не сказано. процесс вообще может быть идеальным, но некому было экспертно оценить код.
им надо было определиться с критериями хорошести, выбрать правильные подходы, зафиксировать их в доках, а потом контролить исполнение.
Здравствуйте, e.thrash, Вы писали:
ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
тут на первом месте человеческие качества, на втором знания, нельзя стать хорошим тимлидом назначенцем, это всегда неформальное лидерство.
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
Например токсичному человеку, никакие правильные действия с т.з. кодинга и архитектуры не помогут
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
L>Наем разработчиков — не задача лида. Для этого HRы есть. От лида нужно только понимание, сколько команде нужно разработчиков и каких.
HRы смогут принести только массив из 100 разработчиков, а лиду придется выбрать из них 3х которые подойдут.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, e.thrash, Вы писали:
ET>Так получилось что пришёл на проект который писали разные люди с разным уровнем. В итоге имеем не очень хорошую архитектуру и разные подходы в проекте. Раньше руководством не занимался. Сейчас планируется нанимать новых людей из за расширения проекта. ET>Что должно быть у хорошого тимлида из качеств и что наоборот показывает что он плохой лид?
Не очень понятно что такое "тимлид" в твоей конторе. То есть, есть тимлид, есть ПМ.. В принципе, эти две должности разные, хотя иногда совмещаются.
AFAIK, рзаница легко детектирутеся — ПМ деньгами пректа распоряжается, а тимлид — нет. MozgC хорошо расписал
— хороший тимлид — вот все вот это.
Ты распоряжается деньгами в своем проекте? Решаешь, на что потратить бюджет, кого нанять, кому дать премию, кого увлолить?
ET>Например, есть ли смысл делать код ревью, если проект на текущий момент с плохой архитектурой?
Ревью имеет смысл делать всегда, потому как оно позволяет сократить количество багов на раннем этапе. Но надо подходить к вопросу разумно
— никаких споров о форматировании или стилях — это должно энфорситься автоматом (роботом)
— если разработчики достаточно опытные, пусть просто делают ревью друг у друга.
— если нет, пусть его делает тот кто понимает, что должен делать код, который коммитится
Здравствуйте, rm822,
R> ПМ — это роль, которая как отдельный человек уже мало где существует
Пиэм-то роль, да в ней намек — добрым молодцам урок. Нагружают этой ролью синьера, а то и вообще миддла, вот только платят за эту роль — как обычному миддлу.... А снош.. втыков дают, как ПМ-у.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, okon, Вы писали:
O>>Например токсичному человеку, никакие правильные действия с т.з. кодинга и архитектуры не помогут
S>Что значит токсичному? Какие критерии?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, Sharov, Вы писали:
O>>Например токсичному человеку, никакие правильные действия с т.з. кодинга и архитектуры не помогут S>Что значит токсичному? Какие критерии?
это если ты говоришь ересь, они тебе прямо говорят, что это ересь.
