|
Хочется номинировать на пример over-engineering новую главную книгу и любимые мной subledger/distributions.
Во первых - из за того что там очень высокий уровень абстракции, большая часть диагностики сводиться к сообщению "У нас тут какая-то фигня". После этого приходится тратить где-нить от часа до трех времени, чтобы протрассироваться и понять - где-же именно и какую настройку консультанты неправильно сделали. Просто благодаря могучим программистским механизмам, место возникновения ошибки отделено от его причины изрядным количеством вложеных вызовов,классов-фабрик, классов сохранения состояния, классов перехода состоянияи и тд и тп. Поэтому в момент обнаружения ошибки, выдать понятную диагностику просто невозможно. Проверку параметров в унаследованный от Дамгаарда код прогрессоры добавить не догадались.
Аналогично - процентов 85 эскалированных в Микрософт ошибок, приходилось на те самые замечательные распределения и сабледжер. При этом чтобы воспроизвести ошибки в стандарте и понять условия их возникновения, приходится тратить достаточно заметное время на трассированние исходного кода.
При этом, как я много раз уже писал, subledgers/distributions - это вообще абсурд, не связанный с экономической реальностью. Новая аналитика и ГК - конечно полезна в определенном числе случаев, но с другой стороны - в 98% случаев и старой ГК (как в 2009) хватало. (В том числе для вполне себе крупных внедрений enterprise уровня).
Наконец - хочу ввести критерий ovengineering: Это, как несложно было догадаться, отрицательный экономический эффект от изучения новой технологии. Вот я на эту борьбу с ГК и распределениями потратил, в общей сложности, порядка 4 недель жизни.
Во первых - далеко не все это время было billable. Клиенты как-то не очень рвутся оплачивать то, что с их точки зрения является ошибкой (не важно - нашей в настройках, или Микрософтовской - в коде).
Во вторых - эти знания мне вряд ли пригодятся для каких-то других задач, кроме собственно воспроизведения ошибок MS и поиска ошибок консов. (А это, как я уже заметил, не очень выгодные в финансовом плане и не очень интересные в профессиональном плане задачи). Я точно не буду создавать свой собственный вид source document и вряд ли я буду переписывать разноску в ГК.
Так что для меня изучение нового замечательного, богатого на новые программистские технологии модуля дало в целом негативный экономический эффект. Я потратил изрядное время на получение знаний сомнительной полезности и применимости.
То есть - конечно если за стажерскую зарплату сидеть и тихонечко разбираться в новых технологиях, то можно не думать об окупаемости этого процесса. Но вот если ты фрилансер, или если ты ключевой сотрудник партнера (и твоя зарплата подпирает сумму выручки), то критерии эффективности очень даже актуальными становятся.
|