Есть один человек в штатах с который достаточно часто приходится работать над кодом. И вот есть у него привычка которая в последнее время меня выводит из себя.
Когда мы только начали работать вместе, он частенько сомневался в работоспособности то какого-то подхода, то архитектуры. И в тот момент мне это нравилось, так как действительно подходы были (да и есть) не всегда оптимальные. Ну и я считал, что это полезно обсудить лучший подход.
Однако со временем, я заметил, что собственно говоря любую вещь, которые хоть насколько то сложнее средней он начинает обсуждать с фразы «А что, если оно в __каких-то__ случаях не работает?». Резонный ответный вопрос -«В каких например?». В ответ им выдается, дай бог, один какой-нибудь жутко редкий необычный случай, который сложно даже проверить.
Собственно говоря нервирует
— Критика методов, не конструктивная. То есть, чаще всего не предлагается лучший метод
— В случае когда метод лучший предлагается, то он чаще всего гораздо дольше по времени исполнения, при этом очень мало уменьшает вероятность проблем
И самое главное, что меня убивает — это аргумент «Но ведь если там есть ошибка — оно не будет работать.» Ну, ясен пень, работать оно не будет. Поэтому ошибка и называется ошибкой.
Слава богу, что работая я с ним в стиле agile. Поэтому мне достаточно легко говорить — в тот момент, когда мы обнаружим, что оно не работает — мы исправим. Будь воля того человека, то весь мир медитировал бы вечно над одним байтом кода, рассматривая все возможные ситуации, включая нападение инопланетян и глобальный потоп.
Перфекционизм — не такое уж плохое качество.
Главное уметь вовремя остановиться 🙂
Да я сам такой — перфенционист 🙂 Просто нужно уметь останавливаться. Да и плюс, нельзя просто говорить «все это говно», нужно говорить еще «вот есть метод, как сделать все это лучше».
🙂
можно загнать человека в «паралич анализа»… после этого люди начинают бояться чрезмерно глубокого анализа
Меня — да, можно туда загнать. А человек, видимо оттянется в полный рост и будем наслаждаться полным параличем 🙂
в общем, если нужно что бы человек не приставал с глупостями, то есть масса способов:
— перевешивание отвественности на человека за принятые решения, типа «скажи как надо сделать — я так и сделаю»
— перевод отвественности за «усложнение решения», типа «давай я поставлю себе Rational Rose и за пару неделек нарисую все алгоритмы в UML, потом мы их согласуем и будем делать»
— классические бюрократические методы «увода власти»
Я где-то писал в комментариях.
Я обычно говорю человеку — «если видишь метод как все исправить/переделать и есть время — то вперед переделай».
То есть, таки приходятся слегка делать ход конем, чтобы человек не приставал.
Можно попробовать научить доброй русской традиции: пока гром не грянет, мужик не перекрестится.
Пока не возникла сбойная ситуация, это не баг, а фича 🙂 К тому же, есть вероятность, что такая ситуация может никогда и не возникнуть.
>К тому же, есть вероятность, что такая ситуация может никогда и не возникнуть.
С последним согласен.
>пока гром не грянет, мужик не перекрестится.
В целом — это опасная метода, но иногда так и нужно делать.
> В целом — это опасная метода, но иногда так и нужно делать.
Если ваш коллега умный и опытный, он поймет что имеется в виду. Новичку, и даже специалисту среднего уровня, использовать такую практику использовать строго воспрещается.
Ибо им необходимо _учится_ думать на пару шагов вперед. А пока опыта мало, непонятно, какие шаги надо предугадать.
Коллега — опытный и умный. Но, почему-то у него не выработалось ограничение, на сколько шагов стоит просчитывать.
Что ж, тогда ему стоит взять на вооружение методы написания кода, содержащего минимум ошибок (одна ошибка на 420 тысяч строк кода):
«Возьмем, например, обновление программы для GPS-навигации шаттла, занимающее 1.5% программы (6366 строк кода). Спецификация этого изменения состоит из 2500 страниц. Спецификация же всей программы состоит из 30 томов и содержит 40000 страниц.»
Это в НАСА так пишут софт, если верить авторам статьи: http://www.fastcompany.com/node/28121/print
Да, для NASA — это актуально. Так как, стоимость ошибки может быть несколько миллиардов (стоимость потери марсохода).
Для обычной программы — стоимость множество ошибок ничтожна мала.
Приведу ссылку на русский перевод этой отличной статьи:
http://kholeg.spaces.live.com/blog/cns!D006ED9CB32B0F60!152.entry
Статья забавная. Но, если честно мне не совсем понравилось, что это преподноситься, как гораздо более правильный и хороший путь разработки. Да, шатлов по другому нельзя. Но для обычной рыночной ситуации с типичными потребительскими продуктами такой подход равен смерти компании.
Это же поиск в глубину, человек берет ситуацию и доводит ее до абсурда. Так можно проверять различные теории, по крайней мере это стимулирует на поиск более вероятных ошибок 🙂
p/s
В перфекционизме главное без фанатизма:)
Вот и я об этом же. Главное без фанатизма 🙂
Перфекционизм — взял термин на вооружение. Спс
Это надо очень аккуратно юзать, да и не все работодатели любят Перфекционизм:)
Несомнено, такие люди очень полезны, когда они прикрывают тыл и чистят код на втором проходе. Это дает возможность локомотиву нестись в перед не задумываясь, как там в вагонах. Сам сейчас нахожусь в подобной ситуации и не нарадуюсь на своего зама, который хоть и зануда и перфекционист, но дает нормально заниматься движением вперед.
Да, я сам таких людей люблю насчет подчищания кода. Как вы точно заметили — идеально работает в тандеме — локомотив + перфекционист.
Но, когда он во всех вагонах сдергивает стопкраны, просто из-за того, что это можно сделать… Вот тут, у меня и возникает нелюбовь.
Если можно разъясните, что такое «перфекционизм». Но мне не кажется это до такой степени страшным!
Есть разные точки зрения на перфекциониз, но обычно в это слово вкладывают негативные моменты:)
А почитать можно здесь: http://ru.wikipedia.org/wiki/%D0%9F%D0%B5%D1%80%D1%84%D0%B5%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D0%B7%D0%BC
и здесь http://fritzmorgen.livejournal.com/17099.html
— «А что, если оно в __каких-то__ случаях не работает?”
— «Вот и замечательно, значит в условиях кризиса мы с тобой не останемся без работы»
😀
Ну слава богу. А ведь дай я ему все пофиксить, таки бы уволили 🙂
Как же я тебя понимаю!
Тут сильно зависит от конкретной ситуации.
Ситуация 1.
Я — мы пишем видеоплейер на Silverlight, до конца недели должен быть готов и бюджет — всего тридцатка. Давайте всю логику прямо в контролы запихаем, так проще и быстрее.
Перфекционист (П) — Не-не, это несерьезно. Давайте будем следовать MVVM, для VM и M напишем автоматизированные юнит-тесты, и вообще первые пару дней потратим на разработку архитектуры. Иначе изменения плейера в будущем будут дорого стоить. Кстати, ты уже записал все требования в формальный документ? Возьми день и запиши, иначе потом трудно с клиентами общаться будет.
Я — у нас бюджет ТРИДЦАТКА и времени до конца недели. Иди курить Экономикс.
Ситуация 2.
Я — Тут юзеры обнаружили, что у нас SQL injection.
П — Да, правда, смотри — в куче мест у нас SQL запрос из строчек собирается. Найти бы того, кто это написал, да руки бы поотрывать. Медленно.
Я — ну ОК, давай быстренько во всех местах параметры в функцию SqlEscape обернем.
П — не-не, давай лучше параметры через SqlCommand.Parameters передавать. Времени займет переделка столько же, а SQL-Server кроме того еще и сможет запросы лучше кэшировать, наша прилада залетает.
Я — ты прав.
Да, согласен в ситуации 2 — гораздо логичней делать все более аккуратно.
Вопрос состоит в том, что чаще всего человек приходит без рационального улучшения.
То есть, не говорит давайте сделаем MVVM или SqlCommand.Parameters, а говорит.
Блин текущее решение такое опасное. В нем могут быть проблемы. Точка.
Я уже правда нашел магическую формулу — я отвечаю. Если хочешь и сможешь уложиться в сроки, можешь менять на другое решение.
Может он просто не может или не хочет сказать, что на самом деле имеет в виду? Например, «Ты опять принял все технические решения сам. А я ведь тоже могу. И хочу. Мне тренироваться надо».
Нет? 🙂
Ну, все конечно может быть. Но скорее нет, чем да.
Как показывает практика, он не любит новые решения делать/выдумывать, так как опять же не может полностью оценить все возможные проблемы.
Как по мне, классический паралич анализа.
естественно легче сказать чем сделать и легче усомниться в верности решения чем предложить свое решение. если этот человек тебя не устраивает — найди другого компаньона.
Увы, тут он не компаньон. Он работает на ту компанию, на которую я консалтю. Кстати, я когда-то его сам нанял.
Тогда по сравнению с другими кандидатами он был хорош. Но, теперь, явно утомляет.
Взять исправить ошибку и все будет работать как нужно.
Мдее, бывают же люди. К счастью, я работаю один, никто кроме заказчиков, тормозящих с оплатой, не напрягает.
Да ладно, чего нервничать то, не надо обращать внимание и продолжать работать!
На мой взгляд с работодателем вообще спорить не надо, надо делать и получать деньги, а все остальное приложится
Очень спорное утверждение. С такой позицией в просак попасть сложно, но и выбиться вперед тоже шансов мало.
Считаю, что такой человек чересчур ответственный. Не нужно его за это называть таким сложным словом 🙂
Не надо сердится на таких людей, такими их сделала природа этого не изменить. Зануды всегда будут занудами, нытики нытиками и т.д. и т.п. А этот просто не может чтоб не потрепать кому то нервы. Берегите себя и не нервничайте.
Все люди имеют свойство меняться, надо просто психологам с такими работать, а найти ниточки у человека любого можно, а потом за них дергать!
Психологоия сложная наука! К каждому человеку есть подход и своя цена!