Как бороться с "теоретиками"?
У меня новая команда разрабов, весьма разношёрстная - от чуть-чуть нюхнувших пороху "уже не выпускников" до матёрых дядек с усами и в очках (как в гугле при поиске слова "программист").
Так вот один из таких дядек - "теоретик". Он в команде ответственный за каКчество продукта. Ну то есть авто-тесты, код-ревью и прочие кволити-гейты. Пишет умные "мыла" всем подряд. В личной беседе то и дело проскакивает "а вот в последнем номере <какого-то журнала для айтишников> <какой-то гуру> <чего-то там умное написал>". То есть вроде как мужик должен быть с башкой на плечах. Знает хотя бы названия фреймворков и концепций последних.
Но вот смотришь на его код - и хочется повеситься! ГРАНДИОЗНЫЕ методы по 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 вхождений...
Но! Никто не заметит и не оценит. Тем более - внешне.
Я думаю проблема больше в нас, мы легко привыкаем к немецкой системе работать. У немцев принято работать не в удовольствие а со стрессом, каким то рабочим мазохизмом, пока все друг другу мозги не перетрахАют в извращенной форме проект не сделают. Думаю что всегда на фирмах много нахлебников, много мертвых душ но на самом деле они живые и очень даже здравствующие, числящиеся и даже ходящие на работу всякие родственники как правило
В США подход к работе несколько иначе, более свободный и в удовольствие с наименьшим количеством нахлебников