Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
Что посоветуете?

Здравствуйте, merge, Вы писали:

M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.

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

Здравствуйте, merge, Вы писали:

M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?

Ну да, промышленный код должен не просто решать задачу, но быть понятным и поддерживаемым. Код нужно писать так, чтобы он соответствовал принципу наименьшего удивления. Другими словами, код должен быть отчуждаемым. Не должен содержать черной магии и тайных знаний (если без тайных знаний не обойтись, то нужно писать пояснения в комментариях, т.е. код должен писаться так, чтобы мидл смог его поддерживать с адекватным уровнем усилий). Третьими словами, код должен соответствовать практикам типа Clean code Стива Макконнела, Роберта Мартина, принципам рефакторинга Мартина Фаулера — по всем трем есть соотв.книги, где все эти принципы описаны. Вдобавок, нужно соблюдать общеизвестные DRY, KISS, SOLID, использовать паттерны вместо велосипедов. Все эти книги должны быть в наличии у каждого члена команды в быстром доступе, чтобы в процессе работы быстро их открывать, иначе никто читать их не будет, ведь в запарке при работе над текущей задачей у разраба нет ни сил ни желания искать эти книги. Поэтому тут спасет например программа быстрого поиска и открытия и файлов, типа Farr. На корпоративной вики должен быть манифест с явным и четким описанием этих принципов, каждый член команды должен быть согласен с ними (чтобы не пришлось уже в процессе работы постоянно кому-то из них доказывать, чем SOLID, Clean code или паттерны лучше велосипедов). Есть определенная категория программистов, которая либо не признает эти принципы, либо считает что соблюдать их необязательно, приводят свои доводы, они в некоторых случаях могут быть верны — например при разработке жестких highload-систем, или встраиваемых систем, и т.д, т.е. там где ограничения по перформансу, по размеру или по другим факторам приводят к тому, что код нужно писать в угоду этим факторам, а не в угоду clean code. Но даже там можно применять многие практики из Clean code. Если берете такого программиста в команду (ну а понять отношение программиста к этим практикам призвано собеседование), будьте готовы к такого рода рискам и трате времени на постоянные дискуссии по любому комменту в код ревью. Не говорю что это плохо, скорее полезно, но это издержки на ваши силы и на затраченное время. Далее, нужно явно внедрять культуру разработки, т.е. в процессе код ревью постоянно проверять весь код на соответствие этим принципам, заниматься евангелизмом, т.е. проводить обучение и всем повсюду тыкать в лицо этими книгами и принципами, включая менеджеров, показывать и доказывать зачем они нужны, к каким эффектам приводят и как на дистанции упрощают разработку и сопровождение кода. Если не следить на код ревью за их соблюдением, то даже разрабы, которые эти книги читали, скорее всего не будут их соблюдать. Не потому, что они такие плохие, а потому что у разраба свои сроки сдачи задачи и он поглощен решением проблемы, а не соблюдением этих принципов; и первая версия сдаваемого кода по задаче — это часто наслоение в коде результатов инженерного поиска (читай "слеплено из говна и палок"), и чтобы привести решение к промышленному виду, нужно еще потратить доп. усилия, ведь с нуля clean code никто не пишет, код растет "из сора", как и стихи, и задача код ревью и этих практик — убрать весь этот сор. Поэтому для код ревью нужен именно взгляд со стороны, от человека, который эти приницпы и сам применял, умеет видеть в коде их нарушения и предлагать конкретные улучшения, как именно нужно исправить код чтобы он стал соответствовать этим принципам, т.е. любое замечание по коде ревью должно указывать на конкретные нарушения конкретных принципов (замечания типа "тут код плохой. переделай как-нибудь по-другому" не годятся, нужны конкретные замечания типа "функция нарушает стандартные унарные формы, что приводит к плохо понимаемому и плохо поддерживаемому коду, см.книгу мартина clean code стр.XX, исправь — приведи к любой стандартной унарной форме"), и если автор кода не знаком с ними, то также указывать на источник принципа (книга и страница, название принципа) и на то, как именно нужно сделать исправление; по мере накопления опыта разрабы сами начнут эти принципы применять, и в коде ревью будет достаточно просто указывать на факт нарушения принципа, без детальных пояснений.
Подытоживая: тебе нужно либо самому вводить культуру разработки (если ты знаком с этими практиками), либо искать евангелиста их знающего и умеющего, который займется внедрением культуры разработки в команде, а также убедить менеджеров в необходимости этой культуры (а это отдельный вопрос, если вкраце, нужно по каждой практике уметь показать на цифрах, как это улучшает показатели, например как принцип O из SOLID уменьшает вероятность регрессионных багов, а это уже механизм, который менеджеры поймут и могут контролировать, это реально хороший и конкретный ответ на вопрос "как снизить вероятность регрессионных багов"; или если видишь какую-то издержку из-за плохого кода, просто высчитай потери на неё, затем укажи что если бы применялась определенная практика, этой издержки бы не было — как пример, из-за непонятного наименования каких-то переменных другой программист неправильно написал код, и пока все разобрались и всё исправили, потратили столько-то часов (или даже дней — бывает и такое), а если бы были конвенции по понятному нэймингу согласно clean code, то эту проблему отловили бы ешё на этапе код ревью — и с такими примерами нужно идти к менеджерам, это ответы на вопрос "какие ваши доказательства" для внедрения этих практик).

Здравствуйте, merge, Вы писали:

M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?

Вообще ребята может даже и правы.
Обычно автор кода может его поменять быстрее и лучше, в этом нет ничего удивительного.

Вообще у вас ревью кода есть? Если нет, можно ввести.
В смысле, чтобы рядовые программисты (не тимлид) апрувили пул реквесты своих коллег.
Чтобы хотя бы были в курсе, что другие там вообще пишут.

Чтобы не относились к этому спустя рукава (ревью в духе "Вася, кликни там апрув, плиз"),
можно периодически смотреть самому например и делать большие глаза в духе "боже, кто мог заапрувить этот ужас?"

Здравствуйте, bnk, Вы писали:

bnk>Вообще у вас ревью кода есть? Если нет, можно ввести.
bnk>В смысле, чтобы рядовые программисты (не тимлид) апрувили пул реквесты своих коллег.
bnk>Чтобы хотя бы были в курсе, что другие там вообще пишут.

Хе, это работает, пока все занимаются одинаковыми задачами. А если один солверы пишет, другой с геометрией работает, третий — шейдеры, четвертый — веб морду...
Как тут провести осмысленное ревью? Максимум — докопаться до оформления кода.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Хе, это работает, пока все занимаются одинаковыми задачами. А если один солверы пишет, другой с геометрией работает, третий — шейдеры, четвертый — веб морду...
SVZ>Как тут провести осмысленное ревью? Максимум — докопаться до оформления кода.

Ну изначальная постановка задачи в данном конкретном случае как бы подразумевает, что Вася сможет написать то же, что и Петя, просто стесняется.
Если Вася не сможет, то постановка вопроса вроде как вообще бессмысленная, мышка ежиком никак не станет.

M>Что посоветуете?

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

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

Здравствуйте, merge, Вы писали:

M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?

1. Парное программирование повышает число людей, знакомых с определённым кодом. Как минимум их уже двое.

2. Сделать постоянную ротацию, не должно быть "владельцев" кода, люди должны постоянно "трогать" разные части проекта.

Но надо понимать, что первый пункт подходит не всем программистам, очень многим комфортней работать в одиночку. Также есть вероятность, что снизится производительность команды (хотя не факт). А второй пункт однозначно снизит производительность команды, причём ощутимо.

Здравствуйте, vsb, Вы писали:

vsb>Но надо понимать, что первый пункт подходит не всем программистам, очень многим комфортней работать в одиночку. Также есть вероятность, что снизится производительность команды (хотя не факт). А второй пункт однозначно снизит производительность команды, причём ощутимо.

И поставит верхнюю планку достижимой сложности по уровню компетентности самого слабого участника.

Что может быть и хорошо, впрочем, в зависимости от решаемых задач.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Хе, это работает, пока все занимаются одинаковыми задачами. А если один солверы пишет, другой с геометрией работает, третий — шейдеры, четвертый — веб морду...
SVZ>Как тут провести осмысленное ревью? Максимум — докопаться до оформления кода.


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

Здравствуйте, vsb, Вы писали:

vsb>2. Сделать постоянную ротацию, не должно быть "владельцев" кода, люди должны постоянно "трогать" разные части проекта.
vsb>А второй пункт однозначно снизит производительность команды, причём ощутимо.

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

Здравствуйте, Ночной Смотрящий, Вы писали:


НС>Ну и безотносительно ревью — если у вас задачи разработчиков настолько сильно изолированы, то у вас большая проблема. Уход любого из разработчиков остановит проект.

Разделение труда-с.
С одной стороны удобно. А с другой, как ты верно заметил, каждый сотрудник на вес золота.
Но это, похоже, свойство любой компании, занятой в наукоёмких разработках. Я с этим сталкивался даже в очень крупных и богатых компаниях.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Здравствуйте, Ночной Смотрящий, Вы писали:


НС>>Ну и безотносительно ревью — если у вас задачи разработчиков настолько сильно изолированы, то у вас большая проблема. Уход любого из разработчиков остановит проект.

SVZ>Разделение труда-с.
А если посмотреть дальше этого? Как ваши люди ходят в отпуск — со звонками "ах, у нас тут сломалось, включи ноут"? Как растут сотрудники, если каждый специалист в узкой ниши и дальше своей ниши ничего не знает? Как может развиваться процесс в целом, если никто не челенджит не только качество, но и вероятно архитектуру, безопасность кода и т.д., потому что никто не знает, что делает другой?
SVZ>С одной стороны удобно. А с другой, как ты верно заметил, каждый сотрудник на вес золота.
Но и уход сотрудника стоит дорого, т.к. если искать надо срочно, потому что внутренней замены очевидно нет, это часто влечет за собой дополнительные расходы (реклама вакансии, рекрутинговые агентства, оплата ваше рынка, чтобы ваш оффер точно приняли). Оно вам надо?
SVZ>Но это, похоже, свойство любой компании, занятой в наукоёмких разработках. Я с этим сталкивался даже в очень крупных и богатых компаниях.
Дело не в богатстве компании, а в том умеет ли конкретный менеджер (+PM) оценивать риски и перспективу. Есть такие, которые начинают решать проблему только в момент ее наступления.

Здравствуйте, Milena, Вы писали:

SVZ>>Разделение труда-с.
M>А если посмотреть дальше этого? Как ваши люди ходят в отпуск — со звонками "ах, у нас тут сломалось, включи ноут"? Как растут сотрудники, если каждый специалист в узкой ниши и дальше своей ниши ничего не знает? Как может развиваться процесс в целом, если никто не челенджит не только качество, но и вероятно архитектуру, безопасность кода и т.д., потому что никто не знает, что делает другой?

Люди уходят в отпуск как обычно.
Две недели любая проблема может обождать.

Насчёт роста... в своей нише расти можно бесконечно. У нас в компании только один разработчик без ученой степени. мне вот некогда писать статьи, а шеф регулярно публикует. Иногда совместно с пользователями. Такой вот косвенный маркетинг.

Что такое "челенджить качество и архитектуру" я не очень понимаю. Либо все хорошо — код работает и позволяет расширять функционал, либо нет. Если нет, значит с архитектурой что-то не то.
Вот так вот просто и незатейливо.
В целом продукт состоит из нескольких подсистем и уж на стыках всегда можно всё обточить. А уж внутреннее устройство системы — ответственность ответственного за эту систему и незачем туда лезть с лохматыми лапами.

SVZ>>С одной стороны удобно. А с другой, как ты верно заметил, каждый сотрудник на вес золота.
M>Но и уход сотрудника стоит дорого, т.к. если искать надо срочно, потому что внутренней замены очевидно нет, это часто влечет за собой дополнительные расходы (реклама вакансии, рекрутинговые агентства, оплата ваше рынка, чтобы ваш оффер точно приняли). Оно вам надо?
SVZ>>Но это, похоже, свойство любой компании, занятой в наукоёмких разработках. Я с этим сталкивался даже в очень крупных и богатых компаниях.
M>Дело не в богатстве компании, а в том умеет ли конкретный менеджер (+PM) оценивать риски и перспективу. Есть такие, которые начинают решать проблему только в момент ее наступления.

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

НС>Практика показывает, что на длинных дистанциях он наоборот повышает производительность. Потому что улучшает понимание проекта в целом и снижает риск выгорания.

Вот только заранее неизвестно, будут ли эти "длинные дистанции" вообще существовать.

"Парадокс стартапов": на начальных этапах надо пилить как угодно, лишь бы быстрее (тут уж не до "понимания проекта", успеть бы до конкурентов). При таком варианте накопление техдолга идет так быстро, что стартап может и не успеть получать финансирование с той же скоростью, с какой требуется брать больше и больше неэффективных (в силу техдолга) инженеров.

Вот и получается гадание на кофейной гуще, что лучше: быстрее сейчас (а то "потом" может и не настать), или менее рисково потом. Обычно выбирают первое, ибо риск краткосрочный, в отличие от.

SVZ>Другими словами, это штучный товар. Поэтому набрать пучок про запас, даже за любые деньги, не получится.

Вот поэтому Milena (видимо, работающая в одном из т.н. "гигантов") вас и не понимает. В больших корпорациях "штучный товар" === риск === плохо. Да, один штучный инженер может сделать решение, скажем, за $10m, которому требуется на поддержку 1-2 человека и $2m в год. В больших компаниях на такой же проект будет нанято 10-15, стоить это будет $100m, и поддержка обойдется в $20m.

Но в реальности же получится так: "штучный инженер" возьмет на себя риски создания стартапа, доказательства жизнеспособности идеи, а потом "технологический гигант" просто купит стартап за $50m (вместо разработки своего за $100m).

Вот так risk management и работает, и вот потому-то крупные компании и пылесосят стартапы (исключая недружественные поглощения).

Здравствуйте, merge, Вы писали:

M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?

Помнить, что человек это в первую очередь биологическое существо.
Считается, что человек думает мозгом. Мозг взрослого человека потребляет
более 25% всей энергии.
Когда человеку требуется интенсивно думать,
у него даже может заболеть голова от напряжения.
В противоположность этому, когда человек не думает у него вырабатываются гормоны удовольствия.
Таким образом нежелание разбираться с чужим(да и своим кодом) естественно.
Единицы занимаются извращениями пытаясь понять код.
Остальные предпочитают задать вопрос на форуме и расслабиться получая очередную порцию удовольствия.

Здравствуйте, SkyDance, Вы писали:

SD>Вот только заранее неизвестно, будут ли эти "длинные дистанции" вообще существовать.

Иногда нет, иногда да. Не все компании/проекты это стартапы.

SD>"Парадокс стартапов": на начальных этапах надо пилить как угодно, лишь бы быстрее (тут уж не до "понимания проекта", успеть бы до конкурентов).

Ну вот у меня сейчас как раз такой проект. Месяца за три выкатили MVP, только вот потом настало время делать полноценный продукт, и до беты ушло больше года. Вполне достаточное время, чтобы назвать это длинной дистанцией — двоих у меня нагло переманили внутри компании, один сам ушел, не выдержав анархии стартапного проекта. И даже трех месяцев работы того что ушел хватило, чтобы мне до сих пор икалось когда дело касалось его участков кода. И это при том что у нас владение кодом по возможности совместное. А если я каждому позволю делянку свою окучивать — мы только и будем заниматься расхлебыванием чьего либо ухода.

НС>Иногда нет, иногда да. Не все компании/проекты это стартапы.

Сейчас большинство компаний старается эксплуатировать этот подход. Даже внутри большой компании очень жестко выделяют внутренние проекты. Изначально "спонсируют" только одного-двух работников для исследований, потом, если уже есть готовый годный прототип, могут еще дать времени или ресурсов. Но если не выходит, то довольно быстро сворачивают. Я бы сказал так, год — это максимальный срок в течение которого может не быть production grade кода, и внедрения.

НС>Ну вот у меня сейчас как раз такой проект. Месяца за три выкатили MVP, только вот потом настало время делать полноценный продукт, и до беты ушло больше года. Вполне достаточное время, чтобы назвать это длинной дистанцией — двоих у меня нагло переманили внутри компании, один сам ушел, не выдержав анархии стартапного проекта. И даже трех месяцев работы того что ушел хватило, чтобы мне до сих пор икалось когда дело касалось его участков кода. И это при том что у нас владение кодом по возможности совместное. А если я каждому позволю делянку свою окучивать — мы только и будем заниматься расхлебыванием чьего либо ухода.

По-моему, ты сейчас как раз подтвердил все то, что я писал выше. Сначала — "лишь бы взлетело" (MVP). Потом у вас удалось получить сразу большую инвестицию (больше года). Это риск, на который многие компании не готовы идти даже с наличием прототипа. Разве что вы каждые 3-6 месяцев будете демонстрировать очередную улучшеную версию MVP ("incremental value", будь он неладен).

В общем, в больших софтостроительных компаниях настоящий research — редкость, и зачастую тоже не то чтоб высокооплачиваемая работа. И в плане известности исследователи тоже мало что получат.

Здравствуйте, SkyDance, Вы писали:

НС>>Иногда нет, иногда да. Не все компании/проекты это стартапы.
SD>Сейчас большинство компаний старается эксплуатировать этот подход.

Есть статистика?

SD>По-моему, ты сейчас как раз подтвердил все то, что я писал выше.

Разве?

SD> Сначала — "лишь бы взлетело" (MVP). Потом у вас удалось получить сразу большую инвестицию (больше года).

И? Проект по прежнему остался чем то вроде стартапа.

SD> Это риск, на который многие компании не готовы идти даже с наличием прототипа.

Кто то не готов, кто то готов. Чего всех под одну шконку загонять?