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