Маркетолог спрашивает программиста: в чём сложность поддержки большого проекта?
Программист: ну представь, что ты писатель и поддерживаешь проект "Война и мир". У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь "шёл дождь", сохраняешь, вылетает сообщение об ошибке "Наташа Ростова умерла, продолжение невозможно". Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение "Поручик Ржевский умер." Выясняется, что он в следующей главе облокачивается о столб, которого уже нет...
Это забавный, но очень не удачный пример, если для "читателя"(бизнеса) важно чтобы Ржевский выжил - необходимо проверить всю структуру взаимодействий всех ключевых объектов и эти риски изначально закладывается в бюджет проекта. В реальности же обычно ищется компромисное решение при котором Ржевский выживает с вероятностью допустим 70%, что вполне устаивают "читателя" который ограничен бюджетом.
Угу, и именно такой подход приводит к тому, что было описано Lore. Потому что когда выживший с 70% Ржевский приходит на состоявшийся с 60% бал и встречается с приехвшей на 80% Наташей Ростовой для того, чтобы с 75% вероятностью предложить ей руку и сердце, дабы спустя несколько лет с 55% вероятностью у них родилась двойня, получаются оччччень забавные ситуации, среди которых появление Росомахи на дуэли Пушкина с Пьером Безуховым, выяснившим, что он прапрапрадед Джона Коннора - это еще цветочки
По факту, конечно же, любому, кто хоть как-то варился в этой области, описанное Lore знакомо и по-человечески его состояние полностью понятно. Другое дело, что он немного лукавит. Структурный подход в создании любого продукта исключает ситуацию, когда действие, которым система должна была обладать и которое было просто временно отключено, при включении не работает. Если система обладает каким-то свойством, и ее доработки проводятся с учетом этого свойства, то при включении возможности его использовать, это свойство будет работать всегда. Другое дело, если на каком-то этапе разработки, вместо того, чтобы придерживаться структурного подхода, разработчики начали втыкать костыли между несвязанными точками, замыкая цепь там, где ей замыться не следовало, по принципу "и так сойдет - ведь работает же, и заявленных трудозатрат не требует". Вот тогда, при включении полетов систему начинает время от времени покорачивать (от короткое замыкание) на этих самых костылях, вынуть которые и заменить на нормальные мосты не хватает либо духу, либо времени соответственно.
Вот тогда пишутся объяснительные записки, в которых в зависимости от таланта специалиста и его воображения ситуация представляется все более плачевной, а задержки - очевидными. Любимый прием при написании таких записок - берется проблема и в нескольких местах разными словами описывается, дабы казалось, что проблема не одна, а их несколько, желательно, чтобы они переплетались и образовывали узел убрать/разрубить который невозможно, а на то, чтобы распутать - неминуемо требуется уйма времени.
Собственно, это мы и увидели в сообщении Lore. По факту же, если переводить с русского на русский, он написал следующее: существует проблема с полетами и системой фазирования, которую в Дреноре вывели на новый уровень и понапихали везде, где только можно. В связи с тем, что до введения полетов нужно было еще дожить, то на анализ того, под какими углами человек "в фазу" будет попадать, забили по принципу "пусть разбираются те, кто придет на наше место": отсюда карманы, телепорты и прочее. Беда усугубляется тем, что система фазирования вышла весьма тяжеловесной и на старте Дренора повесила сервера, из-за чего ответственным разработчикам в первые дни дополнения пришлось ее переписывать на коленке, втыкая костыли во все щели, до которых они могли дотянуться, дабы ее работу оптимизировать. В результате сейчас "дорабатывать" ее, дабы решать проблему с полетами, приходится при помощи "ейной матери" и прочих разных разработческих заклинаний.
Lore, понятно, о масштабах проблемы мог не знать, он может искренне сожалеть, что так вышло, и во многом брать вину на себя, как ответственный за разработку, но факт фактом, зачем он вывалил это открытое письмо на суд общественности - понять можно с трудом...
Тема: Lore о разработке обновлений (Прочитано 32825 раз)
