Comments 24
Одно другому не помеха, собственно - полировать глюкало можно, но не нужно, если им не пользуются. И дорога ложка к обеду, даже если она вырезана из дерева перочинным ножиком - все лучше, чем черпать кашу из котелка рукой. Тут он прав.
Проблема в том что после обеда эту деревянную ложку нужно либо выбросить и сделать новую, серебряную, либо продолжать есть ей, рискуя нахвататься заноз. И вот тут то и начинается самое интересное - рефакторинг "успешного" продукта оч сложная задача
я этим в основном и занимался - легаси чесал причесывал и переписывал.
Этой весной ко мне прискакали и спросили: а помнишь, в 2011 году ты делал PoC реверс инжиниринга одного формата документов?
Ясен пень помню и полез искать свои архивы. А бэкапы у меня зашифрованные.
В общем вытащил в итоге, хотя помучался подбирать пароль и оказалось что новая версия распаковщика пишет "пароль не подходит" вместо "формат устарел".
Вытащил, причесал, вскрыл еще один интересный формат, архивируемый. Написал конвертер в pdf. Начали миграцию. На win 2000, и тд и тп, все очень древнее, миллиард документов нужно было перенести в новое хранилище.
инженеры Google были «в ужасе от кодовой базы видеосервиса и от того, насколько ужасна его архитектура»
И они конечно же оставили всё как есть ? Или всё же исправили это дело что бы в дальнейшем не тратить гору времени и денег на переделки?
Увы, но они не стали исправлять. Не претендую на истину, но в инете я встречал такое высказывание:
When Google acquired YouTube in 2006 for $1.65 billion, one of the first things they did was... rebuild the backend from scratch. YouTube was originally built on PHP. Google rewrote it in Python.
Это один их популярных фактов против рефакторинга. Есть такое исследование, которое показывает, что вместо затрат на рефакторинг можно выполнить пересоздание ПО каждые 6-8 лет.
Смешно, что они переписали его на python
А по рефакторингу - нет, невозможно его заменить переписыванием. Только нечто очень маленькое и с понятным функционалом можно действительно переписать. И например учесть всё что узнал, так, чтобы написать в этот раз нормально.
Но любое даже "полное переписывание" теми же людьми будет опираться на старый код и по сути будет рефакторингом, а большие проекты переписать просто невозможно, если вы будете "по быстрому" переписывать проект, то получится только хуже
"не имеет стратегического значения"
«На самом деле, дело не в том, насколько хорошо была спроектирована архитектура», — пояснил он. По словам инженера, реальный показатель успеха продукта — это то, насколько он действительно служит пользователям и решает их проблемы.
В огороде бузина, а в Мумбаи дядька, как говорится.
Про нужность продукта думает фаундер, маркетологи, аналитики и т.д. Инженер про эту чепуху думать вообще не должен, он внезапно(!) должен думать про инженерные характеристики. Называется "разделение труда". Придумано в неолите.
В огороде бузина, а в Мумбаи дядька, как говорится.
Если эти высказывания приложить к разным стадиям проекта, то логично.
Качество кода на выходе не рынок и при поддержке успешного продукта нужно разные.
При этом Мартин Фаулер подвигает идею, что базовый уровень качества стоит держать повыше, так как эти вложения окупаются намного быстрей, чем кажется, чуть ли не в первые месяцы проекта.
Дханджи Прасанна заявил, что значение чистоты и качества кода переоценено
Не сочтите меня за кого бы то ни было, но в ИТ, как правило, имя и этнокультурная принадлежность позволяют судить по архитектурным и программным взглядам на кодовую базу. Стереотипы раз за разом подтверждаются, и по ним можно сразу предугадывать, какие взгляды имеет работник. Нравится вам это или нет.
Три основания в треугольнике успеха от Дханджи Прасанна:
1. Качество кода не обязательное условие успеха. Продукт может быть коммерчески успешным, даже если код далек от совершенства.
2. Приоритет надо отдавать быстрому исправлению ошибок выявленных в уже выпущенном продукте, а не вылизыванию продукта до релиза. Быстрое исправление ошибок, в уже выпущенном продукте, не принципиально отличается от изначального их отсутствия.
3. Разработчикам надо концентрироваться на фактическом выполнении конечным продуктом его предназначения, а не на архитектуре проекта и качестве кода.
В приеципе почти то же что говррил Кент Бек в XXX.
Я сам фанат чистого кода и архитектуры. Но тут он прав - обычно коммерчески успешный проект страдает от говнокода.
Но это не значит что он останется успешным. Есть много примеров где качество кода убивало проекты из-за скорости поставки.
Тот же гугл мог использовать деньги по другому - не погупать ютуб, а допилить свой сервис. Скачать все видео с ютуба и перезалить себе. Просто на тот момент было выгоднее купить ютуб.
скачать все видео не всегда рабочий вариант. Как бы имею опыт миграции всякого большого и часто бывает, что без вскрытия и прямого доступа, через публичный АПИ, миграция займет десять лет.
У многих троттлинг, мутная схема поиска, обхода и тд и тп. Кролинг больших объемов задача не тривиальная, понятно что не для Гугла, но это бы стоило как бы не дороже чем просто купить. И точно быстрее.
Главное в продукте тех документация. А остальное все приложиться. По ней любой код можно переписать на другом языке. И не важно плохой исходник был или нет.
Он прав, но только для одной очень специфической фазы жизни продукта - MVP и взрывного роста. Когда тебе нужно захватить рынок, скорость важнее всего. YouTube победил Google Video не потому, что у него был хороший код, а потому что он был первым и достаточно хорошим. Но как только рост замедляется и начинается фаза поддержки и развития, этот ужасный код превращается в гирю, которая тормозит любую новую фичу
Он же индус?
Техдиректор Block: в техносфере преувеличивают значение чистоты и качества кода