Комментарии 23
При таком процессе две недели на перемещение кнопки — это на самом деле довольно быстро.
Вопрос же тут не в том, почему так много занимает перемещение кнопки, а почему в разработке при внедрении минорных фич допускается использование подобных процессов? Это катастрофический перерасход ресурсов и дикая бюрократия. Да, такое имеет место быть в крупных компаниях, но по факту эти процессы не добавляют безопасности, зато убивают конкурентоспособность продукта.
Программирование — не моя работа, потому не могу понять, если всё так плохо, то зачем тогда все эти фреймворки один на другом, зачем слои абстракций, изоляция представления, состояния и прочее, и прочее… Уж не ошибки ли архитектуры и организации работы пытается оправдывать автор.
Встречал ситуации когда программисты тратили две недели на перемещение кнопки. Но ещё ни разу не видел, чтобы бизнес просил о таком, чаще всего это самодеятельность на местах, когда люди не думают о том, зачем они двигают эту кнопки и готов ли бизнес заплатить на это несколько тысяч долларов.
В этой ситуации бизнес выполняет роль сознания у человека. Я хочу поднять руку и поднимаю её. Я не отдаю команды конкретным мышцам за меня это делает мозг, он знает лучше что расслабить, а что напрячь.
Так же и с кнопкой, бизнес хочет её передвинуть(и не хочет ничего сломать), а разработчики должны сами знать как это сделать.
И важно учесть о какой кнопке речь? Если это кнопка «Pay», то надо быть предельно острожным, а если кнопка перехода на нашу группу в контактике, то очень серьезно запариваться не стоит.
Так же и с кнопкой, бизнес хочет её передвинуть(и не хочет ничего сломать), а разработчики должны сами знать как это сделать.
И важно учесть о какой кнопке речь? Если это кнопка «Pay», то надо быть предельно острожным, а если кнопка перехода на нашу группу в контактике, то очень серьезно запариваться не стоит.
Ага, а ещё кнопка «Pay» («Subscribe»/«Upgrade»/«Try free»), расположенная в разных местах, может давать разную конверсию. Если речь идёт о бизнесовой задаче и менеджмент не хочет тыкать пальцем в небо — создаются тестовые группы, и на них обкатывается хотя бы 2-3 варианта. Для того, чтобы было возможно как-то узнать результаты нашего эксперимента — нужен репортинг. Репортинг нужно согласовывать с дата аналитиками в том числе. К тому же дизайн кнопки и окружения берётся у дизайнеров, которые его тоже делают не моментально. Когда набрано достаточно данных и эксперимент закончен — нужно оставить победивший вариант и удалить все остальные. То есть, необходимо плодотворное взаимодействие нескольких команд на протяжении определённого отрезка времени.
и готов ли бизнес заплатить на это несколько тысяч долларов
Вопрос масштаба, и не более. Что васяну из гаражей жЫрный заказ, то единорогам — на печеньки в офисы дня на полтора.
Уж не ошибки ли архитектуры и организации работы пытается оправдывать автор.Думаю автор описывает классический монолит и как бы намекает, что с ними нужно бороться. В любом случае я воспринимаю статью как метафору, которая говорит именно об этом. В жутком Legacy как раз монолит встречается чаще всего, а потом уже идут другие проблемы. И да — это ошибки архитектуры классического монолита)
Да при чем тут монолит? Ситуацию, когда перенос кнопки создает кучу проблем, можно получить на любой архитектуре.
Например кнопка должна появляться по условию (или отображать какой-то статус на себе), а это условие нетривиально высчитывается по внутреннему представлению. На старом месте все данные для его вычисления были доступны. А новое место рассчитывает и рендерит какой-нибудь отдельный контроллер (или вот микросервис), который этих данных не имеет. И вообще он из другой подсистемы родом, а все нужные данные — приватные в подсистеме старого места расположения кнопки. Приходится протаскивать их через слои абстракции, возможно дорабатывать внутренние API, добавлять какие-то новые зависимости между модулями проекта и т.п.
Приведу пример более жизненный и понятный. В одной квартире делали ремонт в ванной и сантехник перепутал местами трубы у смесителя в ванной, при повороте ручки влево бежала холодная вода, а при повороте направо — горячая, а должно быть наоборот, так нарисовано на смесителе, да и на всех остальных кранах так сделано. Заказчики оказались перфекционистами и потребовали исправления косяка, тем более делов то на 5 минут. Тем более щас же вроде всё есть, лазерные уровни, перфораторы, 1000 разновидностей смесей для каждого вида работа и т.д. и т.д. Но по факту, чтобы исправить косяк, пришлось разломать плиточный экран для ванной, отодрать ванну от стены, раздолбить стену и плитку, куда были утоплены трубы, а потом всё это восстановить, что заняло отнюдь не 5 минут работы. С программированием точно такая же ситуация, только ухудшает ситуацию еще то, что если в ситуации с ремонтом человек хотя бы примерно видит как всё взаимосвязано, то в абстракциях программирования он не разбирается точно.
Ну, это вопрос к мастерству. Например, более опытный сантехник не стал бы крушить стену, к тому же привлекая к работе плиточников, штукатуров и т.д., нарушая гидроизоляцию, с огромным перерасходом бюджета, а перепаял бы трубы в точке подключения через ревизионный люк. То же самое и с программированием. В подавляющем большинстве случаев для мелких изменений находится простое прямое решение, без переписывания половины кода.
Не знаю я всех подробностей, мне рассказал историю прораб, который делал ремонт в моей квартире. Вариант с перепайкой озвучивался мастером, но почему он не подходит я прослушал. Как вариант, на ванне стояло два смесителя. Один подключенный правильно, а второй нет.
Но вы ведь понимаете, что это по сути костыль. А «Заказчики оказались перфекционистами».
НЛО прилетело и опубликовало эту надпись здесь
… потом скажет: «Давайте всё переделаем за туеву хучу денег», искренне думая, что начать с чистого листа намного проще, всё разломает, превысит в три раза бюджет и в два раза сроки, потом сделает первую версию. А потом будет наворачивать половину тех же костылей, потому что все они были сделаны по какой-то объективной причине.
… или скажет: «Не надо ничего переделывать», искренне думая, что начинать с чистого листа намного сложнее. Будет бояться всё сломать, превысить бюджет в три раза и сроки в два раза. А потом залепит ещё один «костыль» и вся хрупкая иерархия исправлений окончательно рухнет. Вследствие чего время на исправление снова увеличится в N раз.
Не бывает так, что у медали всего одна сторона
Не бывает так, что у медали всего одна сторона
Скажем так, я не берусь отвечать за все кейсы в мире, но за свои двадцать лет работы в ИТ ни разу не видел успешного проекта, когда старый долгоиграющий проект со всей историей выкидывался, и новый начинался с нуля. Зато видел десятки напрочь запоротых таким образом проектов. Что говорит как минимум о том, что статистика отнюдь не на стороне переписываний с нуля.
И тут приходт чел и говорит: ребята, чегойта пирамида уж больно здоровая, вы путаетесь на деплое, давайте на микросервисы это попилим.
Можно сразу разрешить режим свободного размещения кнопок/панелек в пределах рабочей зоны окна. Без влияния на функции и анимацию элементов управления. Это не сложно.
А вот убрать или добавить новый элемент управления — это уже из разряда хотелок, и должно оплачиваться по тройному тарифу. Особенно насчёт волшебных кнопок «сделать хорошо».
А вот убрать или добавить новый элемент управления — это уже из разряда хотелок, и должно оплачиваться по тройному тарифу. Особенно насчёт волшебных кнопок «сделать хорошо».
А это еще никто не упомянул change management, протаскивание через change advisory board который заседает раз в неделю, подготовка и запрос ресурсов QA на тестирование нового функционала
И никому, ни Бобу, ни Элис, ни Кэрол, не придет в голову мысль, что кнопку перемещать вообще не нужно. Пользователь должен найти ее там, где она всегда была.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему чтобы переместить кнопку, нужно две недели