Как бороться с "теоретиками"?
У меня новая команда разрабов, весьма разношёрстная - от чуть-чуть нюхнувших пороху "уже не выпускников" до матёрых дядек с усами и в очках (как в гугле при поиске слова "программист").
Так вот один из таких дядек - "теоретик". Он в команде ответственный за каКчество продукта. Ну то есть авто-тесты, код-ревью и прочие кволити-гейты. Пишет умные "мыла" всем подряд. В личной беседе то и дело проскакивает "а вот в последнем номере <какого-то журнала для айтишников> <какой-то гуру> <чего-то там умное написал>". То есть вроде как мужик должен быть с башкой на плечах. Знает хотя бы названия фреймворков и концепций последних.
Но вот смотришь на его код - и хочется повеситься! ГРАНДИОЗНЫЕ методы по 2000 строк со штуками типа:
if (obj is Type1) { }
else if (obj is Type2) { }
else if (obj is Type3) { }
// MOAR ELSE IF!!!!!11111
Или XAML-разметка на 1 Мегабайт, из которых 80% копи-паста. Дизайнер в Студии вешается намертво при попытке открытия.
Или код типа (комментарий авторский)
public override int GetHashCode()
{
// this is actually the best solution
return (this as object).GetHashCode();
}
Кто не в курсе, в C# это железное переполнение стека.
На SOLID и DRY положено, причём очень толсто! Документации в коде нет, потому что "её же надо обновлять потом, ну на фиг".
В общем, на словах он Лев Толстой, а на деле уй простой. "Теоретик".
Как с ним бороться? Поделитесь опытом.
Как с ним бороться? Поделитесь опытом.
Только личный контакт, кабак, разговоры про баб (или что там вам обоим интересно) и т.д. :)) Его уже не переделать, с ним просто нужно научиться жить рядом.
У нас в конторе, когда несколько лет назад верховная власть поменялась, шеф первое время приглашал пообщаться в неформальной обстановке, то есть выпить и закусить на халяву (коллектив сугубо мужской, из баб только секретарша, работа стрессовая, поэтому непьющих в результате естественного отбора не осталось). Удовольствия было мало, не расслабишься, все время думаешь, чего этот гад хочет, ну и рассказываешь ему чего-то соответственно. Но это недолго было, пару человек он таки выкинул, ну а потом опять наступила стабильность...
Элементарно. Берете что-нибудь потяжелее и заходите к нему в комнату, когда он пишет очередной код. Бьете его тем, что принесли, несколько раз сильно по голове, затем протираете отпечатки, вкладываете в его бездыханные руки, прижав, чтобы оттиски были поярче, и было принято за самоубийство. Записочку можете от него тут же предсмертную отмылить (текст заранее нагуглить, или просто написать, что осознал, какое говно его код. и клаву не забудьте протереть и его фингеры туда потипать). Ну, и чтобы никто не видел, как Вы оттуда выходите.
Не стоит каждого идиота поить пивом и рассказывать ему про своих баб. Куда проще кусок арматуры в баумаркте...
Как бороться с "теоретиками"?
-----
Хммм... Забей...
Бо, сильно лучше он писать не станет - научится хорошо кодить - это работа и не самая простая. Особенно при начальном уровне освоенности инструмента.
Если править... хммм... документация во первых, тесты (не его) во вторых. а вот фиксинг обнаруженных багов - это уже чисто его... исправить не исправишь, но основания для замены будут...
смотришь на его код
-----
А ты не смотри на его код. Проверяй только функционирование и соблюдение кодинг конвентион.
А чтобы совсем не помереть - интерфейсы, абстрактные классы, снова интерфейсы и патерны... и почаще взаимодействие с такими же спецами.
а вот в последнем номере
-----
Пыхх... Знаю человека, который способен назвать почти все все публикации по проблеме которой занимался, процитировать близко к тексту чуть ли не пол статьи... но, блин, не проси этого чела связать причину со следствием... или сделать компиляцию из двух статей в которых одно вытекает из другу... ну такой чел - самостоятельное мышление на нуле...
Я с таким, слава богу, только с нанятым со стороны сталкивался. Потому решение было простое - нафиг с пляжа. Первые два месяца еще удивлялись, мол, может мы чего не понимаем, а потом, когда он наконец-то предоставил общественности свой код... Офигели. На вопрос что это было получили ответ, мол, мы нифига не понимаем, опыта у нас нет, а Мартин в комментариях к первому изданию своего Clean Code еще тогда писал что надо всегда делать только так.
Имхо - не переделать. Но если есть возможность, можно попробовать засадить за документацию. Наш мог не сильно напрягая остальных рисовать диаграммки и гнать текст килобайтами.
Как с ним бороться? Поделитесь опытом.
Это не совсем про программирование. Я как то по совету подписался на рассылку и до сих пор не отписался:
Спама нет, обновления не частые, так что не раздражает. Конечно, никакой серебрянной пули там не будет, но по многим вопросам мозги просветляет.
Попробуйте с ним сделать код-ревью его кода. Если не поможет, тогда да, надо принимать меры.
public override int GetHashCode()
{
// this is actually the best solution
return (this as object).GetHashCode();
}
Кто не в курсе, в C# это железное переполнение стека.
Вот тут не совсем понятно. Знаю что так делать нельзя из-за замедления выполнения кода и из-за некоректной работы алгоритмов, но что будет переполнение стека не слышал.
Можете пояснить?
Всем спасибо за советы! Особенно понравился вариант с арматуриной. Я бы предпочёл его.
От кода отстранить человека нереально. Он в конторе 15+ лет и считается гуру, поэтому особо сложные задачи дают ему (плюс архитектура, плюс каКчество).
так делать нельзя из-за замедления выполнения кода и из-за некоректной работы алгоритмов
Как - так? Что за замедление и какая такая некорректная работа?
Здесь всё элементарно. Переопределяется виртуальный метод, причём таким образом, что он вызывает сам себя. Бесконечная рекурсия --> переполнение стека мгновенно. Система динамического определения типа на то и существует, чтобы в рантайме выбирать подходящий метод. Из-за этого вызовы obj.GetHashCode() и (obj as object).GetHashCode() полностью равноценны, если в классе объекта obj переопределён (перекрыт) этот метод.
Во, архитектура и качество. Такой опытный человек должен определять архитектуру приложения! Пусть документы пишет. Грамотно описанная система может быть реализована и не очень опытными кодерами! Так победим! :)
Опять же качество. Кроме документации пусть пишет тесты. Ведь это очень важно!
От кода отстранить человека нереально. Он в конторе 15+ лет и считается гуру...
Ну да, я как-то изначально предполагал подобную ситуацию, а иначе лучше рецепта тов. сталина (нет человека - нет проблемы) ничего не придумано. Здесь уж надо определиться, или мир, или война. Один раз был в подобной ситуации лет десять назад, только что пришел в контору, испытательный срок и все такое... Дали мне проект, изрядную часть которого (доступ к базе данных) должен был написать подобный сотрудник, и он меня реально сдерживал, ускорить процесс я не мог никак, человек работал в удовольствие, так сказать, и никуда не торопился. В итоге доступ к базе написал сам, проект запустил, а шефу сказал, что с радостью заменю свой код на "правильный", как только он будет готов. Разборки были, конечно, код ревью от "гуру" и все такое, на что я отвечал, что типа давай свой суперский код, и я его вставлю. Шеф в конфликте встал на мою сторону (ему этот концептуальный спор до фонаря был, а работающий проект - совсем другое дело), пару месяцев я еще ждал "код", но не дождался, гуру перекинули на другие проекты, но и там чего-то пошло не так, он попал под давление и в итоге слился.
Зачем переопределять метод, если он всего лишь вызывает базовую реализацию? В этом случае лучше вообще ничего не трогать.
Это был просто пример. Это не значит, что весь его код такой. У него много кода, и этот код работает (за исключением таких вот приколов). Но этот код нечитабильный и нарушает все принципы SOLID и DRY.
Может завести обычай "для молодежи" но на общей планерке разбирать типичные случаи кода с наглядной демонстраций вариантов и общим обсуждением какой из них лучше и почему ; ) Так чтобы совсем отсидеться не удавалось (типа каждый себе номер варианта выбрать и записать должен). Медленно, но будет хоть привыкать к правильному подходу. И остальным обмен опытом не помешает.
на общей планерке разбирать
-----
Это не работает.
Даже если оппонент прав и докажет правоту - не работает.
Чтобы работало оппонент должен отработать в конторе столько же и на такой же должности. Ну либо быть его Гуру.
остальным обмен опытом не помешает.
-----
??? - для опыта есть много источников... планерка - не для обмена опытом, а чтобы выяснить где сейчас затык и какими ресурсами его ликвидировать.
Основная цель подобного мероприятия - донести инфу так, чтобы чел себя оппонентом не почуствовал и не закрылся, без унижения.
Т.е. сам вначале как привычно выбрал, а потом сам же догадался как лучше. А внешне никто не заметил, что вначале иначе было.
Для опыта дофига источников, но чтобы начать ими пользоваться надо понять что лично тебе это зачем-то надо. А гуру не склонны сомневаться в правильности привычных вещей.
Минуты на своевременное обучение экономят потом часы вылавливания багов более опытными спецами и высвобождают ресурсы. Затыков куда меньше становится.
чтобы начать ими пользоваться надо
-----
Ими пользоваться, вообще-то, ужат в школе. Ну для инженера школа это институт или университет.
Минуты на своевременное обучение экономят потом часы
------
Это - 100% правда,
Просто планерка не место для обучения. Элементарно - там находятся десятки людей, оторванных от своей работы и не нуждающихся в данном обучении.
А внешне никто не заметил, что вначале иначе было.
------
Так внешне никто и не замечает.
Никто и не видит сколько надо переписать кода чтобы исправить маленькую оплошность, которой не было в начальном ТЗ, но которая "подразумевалась".
У меня сейчас аккурат такая же ситуация - переработанный из ВБ6-лике кода код не использует базовый компонент Дистинкт (выборка селект дистинкт). В коде - все написано и должно работать. Но не согласуется по типам. Вот сижу и считаю сколько времени уйдет на замену. где-то от 300 до 500 вхождений...
Но! Никто не заметит и не оценит. Тем более - внешне.
Я думаю проблема больше в нас, мы легко привыкаем к немецкой системе работать. У немцев принято работать не в удовольствие а со стрессом, каким то рабочим мазохизмом, пока все друг другу мозги не перетрахАют в извращенной форме проект не сделают. Думаю что всегда на фирмах много нахлебников, много мертвых душ но на самом деле они живые и очень даже здравствующие, числящиеся и даже ходящие на работу всякие родственники как правило
В США подход к работе несколько иначе, более свободный и в удовольствие с наименьшим количеством нахлебников
Нахлебников там совсем не меньше.
Там - больше легких денег. Легче найти кого-то кто имеет деньги и готов их вкладывать под перспективу.
Еще там неплохой менеджмент.
Все остальное, особенно - квалификация - там весьма плохо.
В инновационной конторе на 150-200 человек может быть всего 2-3 сотрудника которые понимают что делают. Остальные - ой, баласт...
Помнится, ДБА пришлось 3 дня объяснять, что в базе реляция неправильная. Ему - пофиг, а у нас - мапер неправильно отрабатывает...
В Германии, на мой взгляд, спецы получше будут, но очень узкие. Так, чтобы был полный охват и смежные области - почти не бывает.
Еще минус по Германии - практически отсутствует самообучение. Что знает - то делает, освоить что-то новое - из нереального...
Ну еще - количественно спецов в конторе вроде поболе будет...
Как с финансированием - не смотрел - мне тогда не до того было...
Полностью согласен, и даже кое что хочу выделить и сделать ударение
В инновационной конторе на 150-200 человек может быть всего 2-3 сотрудника которые понимают что делают. Остальные - ой, баласт...
Так и должно быть. Там где 1 супер специалист никогда ничего не будет, всегда на одного специалиста должна быть еще куча балласта. Поэтому в США и самые крупные успехи за последние десятилетия, и Китай кажется их догоняет
В Германии не нахлебников выбрасывают, всяких родственников а балласт, и с балластом выбрасывают специалистов, лучшие специалисты в Германии фактически без работы, сидят дома под видом безработного балласта
В Германии делают подвижки чтобы избавиться от нахлебников но очень слабо, например КУКА быка продана самсунгу, теперь там беготня и переговоры чтобы некоторых оставить хотя бы не инженерами а перевести кладовщиками, или аирберлин соединили с люфтганза, тут вообще смешно, драка за места для родственников и любовниц. Время быстро летит, в 2000м детей всех устроить, теперь внучата подросли а у некоторых у правнуки, вот и валится все
Но ведь еще есть малые и средние фирмы. Надо вспомнить как вообще они создавались, это было государственное назначение предпринимателей а все остальные должны идти к ним работать, в Англии так начали первыми делать
В Samsung нахлебников хватает и своих, и они ещё по их количеству оставят немцев далеко позади. Государственное регулирование в части концернов - японское изобретение, бритты тут не причем. Да и KUKA никогда не принадлежала корейцам. И не принадлежит.
да, только с недавнего времени принадлежит китайцам, надеюсь теперь высококлассные промышленные роботы будут всем доступнее
https://www.bloomberg.com/news/articles/2017-03-08/midea-e...
Сам принцип продажи предприятия иностранцам заключается в том, чтобы избавиться от нахлебников и принять на работу тот самый "балласт", среди которых попадаются и хорошие специалисты. Иностранные хозяева не могут притащить своих родственников, знакомых, друзей, друзей родственников зарубеж, это международная практика.
Так называемый "балласт" необходим, это не нахлебники, они выполняют черновую работу, воплощают идеи хороших специалистов.
И по поводу качества, КУКА худшие роботы. Лучшие роботы японские, корейские, китайские, американские
НП.
Я вот с неделю назад, взял код с репозитория, простмотрел изменения и увидел странный код от моего коллеги.
Вот он: что было раньше слева, что сделал коллега - справа.
доваблю что
- функция, фрагмент которой приведен, возвращает признак ошибки или успеха BOOL
- функция, SetData возвращаете тоже признак ошибки или успеха, но HRESULT.
Ну а это известные определения от Майкрософта:
typedef int BOOL;
#define FALSE 0
#define TRUE 1
typedef long HRESULT;
#define S_OK 0L
#define E_FAIL 0x80004005L
получается, если SetData возвратит E_FAIL, то возвращаемое значение (которое должно быть BOOL) будет не непонятно чем (т.е. и не TRUE, и не FALSE).
Я написал коллеге письмо с этим объяснением, но уже неделя прошла, а он ничего не подправил.
Вот думаю что делать? Может самому втихаря исправить?
Или чего сделать чтоб и код подправить и отношения с коллегой не ухудшить?
Хммм... Добавь тест который завалится на проверке результата.
---------------
с тестами в этом проэкте туговото. А эту функцию трудно автоматом оттестить ибо она в UI.
Код - да, весьма странный - результат ВСЕГДА ТРУЕ - нет смысла его возвращать...
---------------------------------
да это я лишь кусочек функции привел, а вообще она почти 400 строк.
К тому же она виртуальная и вызывается не только из кода нашего проекта, но и из кода не наших (Stingray Rogue Wave) библиотек.
А эту функцию трудно автоматом оттестить ибо она в UI.
-----
Значит пора плотнее знакомится с тестированием.
Раньше Я тоже обходился (и ИЗБЕГАЛ!) без тестирования. Сейчас - все чаще имею проблемы с нетестируемой частью кода и часто крупно теряю во времени когда не отслеживаю изменения кода в тестах.
она виртуальная и вызывается не только из
-----
Эээ... А как это должно влиять на функцию и тот факт что данная реализация всегда возвращает ТРУЕ?
Потому снова советую - напиши тест, который должен получить из функции ФАЛСЕ.
Коллегу таким точно не должен обидеть - проверка возможных ошибок это нормa, а на результат он может обратить больше внимания...
Значит пора плотнее знакомится с тестированием.это ясно. последний свой проэктик я покрыл на 100 процентов юнит тестами (что кстати не гарантирует правильности кода) Но размер его не большой и время было. А этот уж лет 20 ему, и все 20 лет никаких тестов.
Эээ... А как это должно влиять на функцию и тот факт что данная реализация всегда возвращает ТРУЕ?ну во-первых она не всегда возвращает ТРУЕ (там в 400 строках есть и ФАЛСЕ).
А во-вторых, даже приведенный кусочек не всегда возвращает ТРУЕ. Он НИКОГДА не возвращает ФАЛСЕ (это верно), но ТРУЕ - не всегда возвращает.
Я уже описал что будет если СетДата возвратить Е-Фаил: это не ТРУЕ и не ФАЛСЕ.
А вызыватель может написать такое:
if (fun() == FALSE){...}
if (fun() == TRUE){...}
Вот думаю что делать? Может самому втихаря исправить?
Втихаря исправлять, имхо, не стоит, поскольку на такие извращения могла сподвигнуть конкретная проблема совместимости с экзотическими сторонними библиотеками... Надо бы сначала узнать у коллеги, подо что он так код подстраивал. :))
он таки пришел ко мне, и сказал, что все это все равно нужно будет переделать, т.к. чего то там всё равно не работает (что он понял позже коммита). А сделал он это чтобы обмануть Стингреевские библиотеки.
Да я в принципе то и не против такого кода, если деваться некуда. Но! такие гурки должы обязательно быть тщательно докуметированны и об\ясненны прямо в комментах к коду, чего коллега не сделал.