О синдроме NIH

[metaclass]

Как наши многоуважаемые читатели уже могли заметить, мы с ребе belnetmon страдаем синдромом NIH в особо запущенной и тяжелой форме. Симптомы усугубляются еще тем, что мы сами это осознаем, но избавляться от него в большинстве случаев не собираемся.

Этому есть объяснение, и самым кратким образом оно описано вот тут:
Ссылка

1. Использование готовых решений, увы, стоит очень много времени. Вот как только понадобится перейти на новую версию ОС, на которой работает только новая версия решения, уже несовместимая со старой - сразу и будет стоить.

2. А тем, что этот кусок не сломается внезапно.

Никогда не сталкивались с тем, что вы приезжаете к важному заказчику ставить систему, а у вас сторонний модуль начинает кидать коней из-за несовместимости с какими-нибудь тонкими квантовыми эффектами настройки компа, ОС или инфраструктуры у оного заказчика?
Или когда система в силу особенностей реализации сетевых протоколов сразу же демонстрирует все грабли в настройках сети, типа глюков с фрагментацией пакетов и MRU.

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

А если "готовое решение" - это программно-индусская жопа в виде хреново документированных готовых бинарников, вызываемых через несколько слоев COM-объектов, сетевых вызовов и прочей жути, там даже мне лень в эти дебри лезть.

Comments

[volodymir-k.livejournal.com]

> Никогда не сталкивались с тем, что вы приезжаете к важному заказчику ставить систему, а у вас сторонний модуль начинает кидать коней

Может Вы хотите сказать, что написанный Вами никогда так не глючит? Ха-ха три раза.

> в исходниках можно разобраться и пересобрать их с отладочной инфой и есть тот, кто в них разбирается.

Итого:
- в стороннем коде надо разбираться, если будут кони (вероятность p1)
- в своём коде надо разбираться при написании (100%) +и если будут кони (p2)

покажите мне выгоду?

[metaclass.livejournal.com]

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

В собственном коде я хотя бы уверен, что исключения корректно обработаны и в лог записаны и коды ошибок APIшных не игнорируются. А в чужом я неоднократно видел полное забивание на обработку ошибок и вообще диагностику любую.

[volodymir-k.livejournal.com]

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


Я наблюдал людей с НИХ-синдромом. Могу сказать, что обычно это люди, которые раздражаются по мелочам и от этой злости прекращают думать. У меня наработан навык перевода "на лету" в голове чужого мусора в свои понятия. Я думаю, как можно было бы ЭТО переписать, мне интересно -- и потому не отказываюсь понять. Для меня Code Review это тяжёлый, но приятный труд.

Ну и у Вас специфика -- дотнетчики по сравнению с явистами всё-таки что плотник супротив столяра.)))