Как стать автором
Обновить

Комментарии 54

Недавно на работе понадобилось поменять «дизайн» у внутреннего приложения, которое писал не я. Оказалось проще переписать все с заново. Заодно логику подправили и работать быстрее стало. Затраты получились наверно даже больше, чем при написании изначального приложения.
Немного баяна вспомнилось :):
Любой русский программист после пары минут чтения кода, обязательно вскочит и произнесет обращаясь к себе: переписать это все нафиг. Потом в нем шевельнется сомнение в том, сколько времени это займет, и остаток дня русский программист потратит на то, что будет доказывать самому себе, что это только кажется, что переписать это много работы. А если взяться и посидеть немного, то все получится. Зато код будет красивый и правильный.

На следующее утро русский программист свеж, доволен собой и без единой запинки докладывает начальству, что переписать этот кусок займет один день, не больше. Да, не больше. Ну, в крайнем случае, два, если учесть все риски. В итоге начальство даст ему неделю и через полгода процесс будет успешно завершен. До той поры, пока этот код не увидит другой русский программист.

А в это время, в соседних четырех кубиках, будет ни на секунду не утихать работа китайских программистов, непостижимым образом умудряющихся прийти раньше русского программиста, уйти позже, и при этом сделать примерно втрое меньше. Эта четверка, давно не пишет никакого кода, а только поддерживает код написанный, в свое время индусом и дважды переписанный двумя разными русскими. В этом коде не просто живут баги. Здесь их гнездо. Это гнездо постоянно воспроизводит себя при помощи любимой китайской технологии реиспользования кода — copy/paste. Отсюда баги расползаются в разные стороны посредством статических переменных и переменных переданных по ссылке (поскольку, китайский программист не может смириться с неудобствами вызванными тем, что он не может изменить значение внешней переменной переданной в его функцию модулями, которые переписывает русский программист).

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

Поэтому, когда всю четверку уволят во время сокращения… А кого еще увольнять? Русский — еще не переписал свой кусок, а индус — главная ценность фирмы — он редко обращает внимание на проект, но когда обращает, все понимают, что так как он, архитектуру никто не знает. Так вот, когда китайцев увольняют, у их кода возможны две основные судьбы. Первая — он попадет к русским и его перепишут. Вторая — он попадет к местному, канадскому программисту.

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

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

Канадский программист смело бросится налаживать все, и станет еще хуже, хотя казалось бы… Эта суета выведет из медитации индуса, который придумает и вовсе гениальное решение — отбранчить код. Согласно его плану, мы теперь будем поддерживать две версии одного и того же кода — одну работающую но с Багом, другую без Бага, но не работающую. Русский программист услышав об этом плане, сломает линейку об стол и дома обзовет жену дурой, но на митинге возразить не решится.

К счастью, все это не сильно влияет на дела фирмы, поскольку продукт продается и так. Поэтому менеджмент ходит в целом довольный и не устает напоминать всем, что они отобраны как лучшие среди лучших. И что мы давно доказали свою способность выпускать продукт тем, что выпускаем его иногда.
Трогательная история
а есть продолжение? :)
я не втречал, посмотрите здесь, много чего интересного найдёте ;)
Первым делом выполняется проектировка интерфейса, и только затем всё остальное.
Иди же: если переделывать фундамент — будь готов перестраивать дом полностью.
Возможно я ошибаюсь, но разве одним из плюсов MVC не является разделение логики от представления?
То есть, если строго следовать паттерну, то смена дизайна будет подразумевать только смену дизайна.
Представления да, но не интерфейса
а смена интерфейса?
Да, пожалуй интерфейс это нечто большее чем представление :-)
В таком случае остаётся надеяться на то, что приложение было красиво написано
На мой взгляд не нужно путать изменение функциональности с оформлением, ваш пример:
Например, что бы появились маленькие цифры возле надписи «личные сообщения»
это уже изменение функциональности. В моей практике при редизайне я меняю, именно шаблоны (xsl), и незначительно дорабатываю контроллеры, а это 20-30% от времени.
я к тому что «смена интерфейса» и «смена дизайна» разные вещи, при смене дизайна именно не должна трогаться логика, только вьюверы, если же она затрагивается то это другой вопрос
НЛО прилетело и опубликовало эту надпись здесь
Обычно требуется «смена дизайна» в проектах, в которых MVC и не пахнет, там тянет на все 100-150% времени от всего проекта.
Как бывает на практике — очень часто ещё и требуется смена дизайна у проектов, написанных в те времена, когда ещё о php не знали… И заказчик ещё хочет чтобы «я мог страницы редактировать. Это же только новый дизайн натянуть, да?»
Мдя… Сколько раз такое было: «А давайте ещё вот такую фичу прикрутим, чтобы тут моргало и показавалось вообще всё!»… Больше всего бесит. Но я уже привык)) Давайте, говорю, и накидываю процентов 10-15 от общей стоимости. А на вопрос «почему так дорого?!» — отвечаю, что, мол, придумывать надо было заранее, а тепероь мне «Всё надо переделывать! И вообще, скажите спасибо, что так дёшево!» :)
А вообще, автору топика спасибо. Нормальный, адекватный «разбор полётов».
Да понимаю… Мне еще нравилась фраза арт-дира на прошлой работе типа «давай коменты прикрутим, ты же их вон на том x-проекте уже делал»
Дада))) Это вообще жесть. У нас тоже подобный прикол был… Пришлось пол движка переписывать и 4 таблицы в БД менять… 4 месяца мы выходили на прежний уровень готовности :)
4 месяца добавляли комментарии?..
Нет, ну что вы :) Просто добавление «очередной фичи» вызвало неконтролируемое увеличение сложности, с которой было решено бороться на корню. И добавляли мы не комментарии :)
сдается мне, это была плохая архитектура.
Именно так оно и было, скрывать не буду. Но я тогда пришел на проект, который уже тянулся, и кричать о том, что надо всё переделывать… Сами понемаете :) Пришлось мучиться :)
а вот интересно почему ВСЕ (без исключения, на личном 5 летнем опыте) менеджеры/директора/итд думают что если A сделано на проекте B, то в проект C можно легко вкрутить A?
Возможно, это вызвано обилием криков о том, что «объектный подход подразумевает повторное использование кода». А думать глубже — удел программиста.
Не помню у кого, толи у Макконела толи ещё у кого встречал фразу, смысл которой можно свести к следующему
«Новая фича способна затуманить мозг заказчику, который придёт и будет требовать/просить её от вас. Скажите что вы готовы это реализовать, но стоит пересмотреть смету и сроки. На них это подействует лучше холодного душа.» Как-то так-вот.
Макконнелл, одна из первых глав… Но из каждого правила есть свои исключения… Это был как раз наш случай… )
НЛО прилетело и опубликовало эту надпись здесь
Это в универе можно ответить товарищу с которым курсовую вместе пишете :)
НЛО прилетело и опубликовало эту надпись здесь
Кэп, привет.
Если логика и контент граммотно разделены, то много времени на смену дизайна не потребуется
В статье чётко разделены понятия «дизайн» и «интерфейс». Если надо поменять только дизайн, то да, всё быстро и практически безболезненно. Дизайн — это скин, по сути (skin).
А если на картинке с новым дизайном вдруг появилась маленькая циферька «количество непрочитанных сообщений», то это уже смена интерфейса. Ибо для арт-менеджера это «всего лишь одна цифра. Что там стоит её добавить в дизайн профессионалу?». А для этого профессионала новая цифра — это геморрой по составлению нового SQL-запроса, по вызову этого запроса и по отдаче результата Viewer'у. Хорошо, если SQL-запрос простенький… а если агрегирующий по нескольким таблицам?
Стоимость этих «циферок» (в часах в том числе) знают только программеры, но не арт-менеджеры :)
Предлагаю такой вариант:
вешаем по листнеру на события добавления сообщения и их чтение;
по обстоятельствам либо создаем модель для хранения новых данных, либо расширяем модель юзера;
позволяем view самому вытягивать нужные «для дизайна» данные.

В худшем случае тратим час с перекурами. Или я что-то упускаю?
> В худшем случае тратим час с перекурами.
Итого часа два-три на смену дизайна и час на добавление новой циферьки. А если таких «циферок» две появится? Три? десять? :)

Очень часто за фразой «а добавьте-ка такую-то фишку, я вижу, что это несложно» кроется некислая работа по добавлению этой фишки.
Но самое обидное не это :) Самое обидное после аврального штурма фишки услышать «а не, как раньше было лучше, возвращайте».
Спасение от такого — предварительное составление детального ТЗ. Но иногда ТЗ — это пушкой по воробьям, потому что проектик вроде небольшой, по работе баксов на 200-300 и на неделю максимум (буквально сайт-визитница), но перед самой сдачей начинаются «капризы-пожелашки» клиента :(.

Считайте мой комментарий возражением на заявления о необходимости переработать «40% — 80%» проекта для добавления на страницу элемента, не затрагивающего бизнес-логику.

Передумать — право заказчика. Ваша, как разработчика, задача — заранее позаботиться о простоте последующих изменений. Хотя, конечно, если просят поправить сайт-визитницу из одной страницы, тут и 80% от времени всего проекта может оказаться мало :)
Мне кажется, здесь как нельзя более уместны будут слова небезызвестного Стива МакКоннелла.

Всем нам хотелось бы надеяться, что, как только клиент утвердил требования, никаких изменений не произойдет. Однако чаще всего клиент не может точно сказать, что ему нужно, пока не будет написан некоторый код. Проблема не в том, что клиенты — более низкая форма жизни. Подумайте: чем больше вы работаете над проектом, тем лучше его понимаете; то же относится и к клиентам. Процесс разработки помогает им лучше понять собственные потребности, что часто приводит к изменению требований.
Когда речь идёт о добавление нового функционала типа «количество непрочитанных сообщений», то задача разбивается на 2 части — 1) дизайнер вставляет в нужное место пелйсхолдер, например вот так:
 <div>{messages_not_red}</div>

2)a программист, пишет функцию которая извлёчёт данные и заменит {messages_not_red} на соответствующую цифру.
Чем лучше сделана внутренняя архитектура, тем меньше времени на редизайн уйдет.
И тем больше на проектирование внутренней архитектуры. Вы не подумайте, я сам тот еще фанат продуманной и красивой архитектуры. Просто всегда важно взвешивать, что критичнее: стартовые затраты или затраты на последующую поддержку.
Да а ничего, что во первых граммотные подходы уже давно описаны и стоит потратить лишь время на их изучение, чтобы не совершать кучу ошибок. Короче, как завещал Ленин, учиться, учиться и ещё раз учиться. А общие затраты на вечную борьбу с фундаментальным багом — архитектурой всегда больше, чем дополнительное время на планирование архитектуры и соответствующее обучение.
Смена «интерфейса» может может потребовать времени, необходимого для написания пары строк или для переписывания всего основного кода.
Чтобы не приходилось делать это за свой счет, согласовывайте документы (ТТ, ТЗ, печатные и экранные формы) этапов ГОСТ серии 34 или более современные (RUP и т.д.).
Можно по подробнее про более современные?
Спасибо.
слишком смело поделили MVC по временным затратам
Программисты такие программисты
именно поэтому я предпочитаю активные шаблоны и селект запросы к бд из шаблонов. и плевать, что это по mvc, зато эффективно и быстро и легко в поддержке. не нужно менять в пяти местах, если можно в одном.
Эко вы смело предположили, что MVC делит проект на 3 равные части.
Ой. Фигня. Это еще умеренная проблемка. А у меня было так.

Наняли меня как программиста в проект, единственного в проекте. Три месяца я работал без дизайна, потому что директор, аниматор более-менее известный, не мог найти ДОСТОЙНОГО дизайнера.

Достойный дизайнер — это который бы умел не только дизайн делать, но еще и рисовать в графике, и персонажей, а лучше еще и 3D немножко делать. Нашелся такой джентельмен почему-то не в самом Питере, а в Минске. Супер. Его привезли в Питер на две недели.

Итак, когда был кое-как сделан дизайн, выяснилось, что три месяца я делал невесть что. Я слегка поседел; и хотя предполагал. что все будет непросто — но не настолько. А потом началось… Естественно, выяснилось, что нифига и ничего не продумано. Что страниц не хватает. Что дизайнер не знает, что делать. Что надо поправить кое-что немножко в том, что уже сделано (ну чуть-чуть, это ж верстальщик за две минуты сделает!!!)…

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

С другой стороны, тратят же миллионы с тендеров государственных.
НЛО прилетело и опубликовало эту надпись здесь
А интересно, как кто поступает с постепенной, не такой глобальной сменой дизайна, да и функционала вообще? Приходит менеджер и говорит: «ну нам тут только чуть-чуть подправить, тут вот одну фишечку добавить, там другую...». Прикидываешь все это, понимаешь, что действительно будет быстрее дописать, а не переписать. Корпеешь над этим всем, где-то приходится хак-другой написать, где-то неочевидную логику зашиваешь, ну ладно, думаешь, комментарии поставлю, потом их почитаю, если что, разберусь. Менеджер смотрит на это и говорит: «Круто! А давай еще вот эту фишечку и вот это повесим, и еще у нас вот на том проекте так классно было». Ты постепенно звереешь, так как понятно, что если бы раньше про это знал, предпринял бы уже более глобальные действия, поменял бы что-нибудь кардинально. Но плюешь, добавляешь еще пару хаков. А потом к менеджеру приходит начальник и требует еще такие и такие изменения. В конце концов суммарно получается переделка 70-80% всего, и если бы знал, что так будет, с самого начала бы делал как следует. В очередную доделку ты говоришь менеджеру, что сайт скоро рухнет под собственным весом, и теперь добавление очередной малой возможности займет несколько дней. На что встречаешь в лучшем случае, непонимание. Обычно менеджеры боятся брать на себя такую ответственность по глобальным изменениям.
Так еще на все это наслаивается и то, что проект чужой, был разработан ногами, а на его переделку не выделили время, так как посчитали нецелесообразным. И вот лежит он такой, частями нетронутый в говнокоде, и ты стараешься туда не залезать без особой надобности, а если уж залез, так переделать по-нормальному. Как раз сейчас ищу ту грань для себя, когда нужно переделать, а когда можно и оставить, как есть, а просто дописать под нужные требования.
В этом случае у нас делают рефакторинг. Теоретичекси его надо делать постояннно, но чаще всего бывает как в вашем случае, и постепенно проект обрастает «костылями».
Я лично считаю что лучше 2 месяца рефакторинга, чем пустится в авантюру типа «давайте перепишем начисто проект, займёт месяц, не больше». Плавали, знаем. мало того, что занимает всё равно больше, чем ожидалось, так ещё всё это время нет возможности продемонстрировать клиенту его продукт. Старую версию показывать некошерно, а новой ещё нету.
ну, вообще Вы правы, я согласен. Проблема бывает в том, что иногда проект в таком состоянии, что там рефакторинг ни к чему не привяжешь — весь фундамент гнилой. При этом менеджеры не понимают необходимости процедуры, а потому не дают на нее времени.
Но вопрос заключался даже не в этом. А в том, как бороться с постепенными изменениями? Как распознать, что это только начало и будет продолжение? Или делать с самого начала по-нормальному, даже если на хак ушло бы пять минут, а на переделку гораздо больше времени?
Интуитивно, я стараюсь рефакторить без фанатизма.
Если есть опыт в задачах такого же типа и я думаю, что знаю «как лучше», то стараюсь сразу сделать лучше.
Бывает надо написать несколько хаков, прежде чем заметишь какую то закономерность. А потом уже можно выделить общие черты, и сделать красивое архитектурное решение. К сожалению в этих случаях время всегда не на стороне программера, это да…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации