В чем суть: веб-студия, в которой я работаю, вместо того, чтобы использовать готовые решения под проекты решила изобрести свои велосипеды. Это вылилось в свою cms и crm. Разрабатывались они долго и упорно последние лет 5.
На cms была реализована пара десятков сайтов и несколько порталов. Все сайты были разработаны на разных стадиях разработки cms (стабильные версии не велись, сайты лепились из последнего коммита в ветке cms. Иногда изменения ядра из порталов мержились в ветку cms, иногда нет). По своему опыту знаю, что начинать разработку на этой cms следует только с ее доработок. Порой даже элементарного функционала не хватает. Документация есть, но часто она не спасает, и все возникшие трудности решались только через автора cms. И я точно уверен, что если для порталов использовать фреймворки, а для сайтиков одну из популярных cms - это сэкономит кучу времени и денег компании (иногда на разработку элементарных модулей уходили недели времени из-за архитектурных проблем cms).
Похожая ситуация и с crm - код часто без комментариев, документация вообще отсутствует, как ее дорабатывать и поддерживать знает только автор, море функционала и бизнес-процессов.
Так сложилось, что авторы crm и cms увольняются, оставляя все это наследие нам, тем, кто пришел работать позже. Есть часть проектов на разной стадии готовности с обязательствами перед заказчиками и морем невыполненного функционала, которые строились на этой cms. Оценить срок переноса на какой-нибудь готовый инструмент сложно (например, один проект занял 2-3 месяца разработки и подвис, а заказчик проснулся недавно) и не факт, что на текущих проектах мы вообще сможем уложиться в бюджет. Но я уверен, что если оставить все как есть и продолжать развивать эти велосипеды, студия только потеряет в финансовом плане (и моральном своих разработчиков) в дальнейшем. Т.к. на данный момент при любой возникшей трудности придется изучать ядро и читать код, а не документацию. Это уйма времени с сомнительным профитом.
Начальство гордится этими разработками и не хочет ничего слушать. Даже на прошлой неделе, когда точно было известно, что разработчик cms нас покидает было принято решение разработать новый сайт на велосипеде.
Как вообще решаются такие проблемы? Как развивать cms в таких ситуациях, и стоит ли вообще этим заниматься? Я думаю, что даже если начальство не примет наши доводы в пользу стека технологий и готовых решений, и решит обновить штат, новые разработчики увидя код будут только гореть желанием все перенести и переписать. Или может я ошибаюсь, и все это надуманно и люди без проблем погружаются в чужие велосипеды при разработке (лично у меня это вообще не получается когда код мудренный)?
Не волнуйтесь, вас уволят и правильно сделают. И вот почему.
Начну со стороны хорошего бизнесмена:
У него уже есть cms и crm, которую он пилил 5 лет, умеет продавать и знает. Да, так получилось, свой велосипед, ужасно написанный, но это его не волнует до тех пор, пока она кормит и его и всех его подопечных. Отказаться от неё означает не только огромные временные затраты на смену всего, начиная от обучения программистов как её пилить, заканчивая обучением всех, кто будет её касаться. Так же это означает поддержка уже двух систем, старых клиентов со старой и новых с новой. Но самое главное - это высокий риск того, что продавать её будет тяжелее.
Со стороны хорошего разработчика:
А хорошему разработчику вообще до фени, с чем ему работать. Спросите у опытных. Эмоционировать при виде говнокода и велосипедов - это максимализм юного программиста. Разработчики с опытом умеют погружаться в любой велосипед, в любой говнокод и работать с ним. А потому что они уже навидались и в своё время тоже кричали и пытались перевернуть мир, но, кому это надо? Вы - наёмный работник, вы не должны писать красивый код, вы должны решать бизнес задачи. Бывалые так и делают, просто иногда про себя вздыхая, т.к. чувство прекрасного всё же не убить :)
Хм. В том-то и дело, что затраты на обучение, разработку, дебаг, новые фичи есть. Но профита мало. Я сравнивал - сайтик сделали на велосипеде за 3 недели. В то же время, аналогичный функицонал на популярной cms делался за 3-5 рабочих дней. При этом сразу уменьшается порог вхождения на проекты, т.к. документации и готовых рецептов по популярной cms в интернете море.
А про сторону хорошего разработчика вообще смешно. Именно хорошие разработчики и будут настаивать на повышении качества продуктов, а не лепке костылей на легаси-коде.
Описанный вами "Опытный работник" скорее смахивает на безвольного любителя пользоваться только спинным мозгом кодера. Конечно опыт работать с говнокодом любой степени это нужный навык. Но профи, который ценит свои навыки и время будет разгребать говонкод либо с целью сделать из него нормальный со временем (так как хороший инженер программист знает, что говонокод это постоянные убытки на поддержке и трата ресурсов в холостую) и за большие деньги, либо за очень большие деньги. А тут какая то веб студийка, Где все держится на соплях и честном слове, хорошие работники туда не пойдут.
Yago: вы зря пытаетесь понять кто прав кто нет, тем более пытаетесь узнать это на тостере. Я думаю окромя начальства этого никто не знает и как быть и что делать со своим бизнесом знает только бизнесмен.
Хороший разработчик не будет советовать директору какой продукт ему следует продавать, иначе он уже не программист, а бизнесмен. И в этом вы не правы. Поэтому становитесь хорошим разработчиком, либо же становитесь сами бизнесменом.
Евгений Елчев: мои 15 лет работы по зарубежьям полностью согласны с evnuh - бизнес практически всегда интересует бабло, а не что скрыто под капотом и как оно работает.
DevMan: А что это за фирмы в зарубежье были? Бизнес интересует это без спорно, но не ужели думаете что хороший бизнесмен не прислушается к мнению специалистов? Вы думаете, бизнесмены предпочитают выбирать технологию которая приносит убытки, вместо той, которая приносит доход? Думаете, что если специалист придет к нормальному начальнику и скажет, что сможет сократить время разработки в два раза, а следовательно увеличить в два раза прибыль, то хороший начальник не прислушается к нему?
Евгений Елчев: я не думаю - я знаю, поскольку не один год плотно работал и работаю с этими людьми.
разработчики приходят и уходят, и каждый новый захочет переписать старое, это факт.
если им дать волю то продукт все время будет разрабатываться, а не продаваться.
слова специалиста - это всего лишь слова специалиста, особенно когда уже есть отлаженный процесс.
к ним могут прислушаться или нет, зависит от их убедительности и очевидности выгоды.
если руководство на это не идет, значит у них есть на это свои соображения. и истерить по этому поводу бессмысленно.
Евгений Елчев: Специалисты могут считать себя умнее бизнесмена, однако кто кому платить зарплату? Зачастую расчеты рядового специалиста учитывают только его маленькую зону ответственности, не имея представления о целой картине бизнеса.
DevMan: Артем Воронов: Между жалением переписать чужой код и пониманием в этом необходимости две большие разницы. Я видел код который хотел переписать, видел который было нужно переписать, но чаще я работаю с кодом глядя на который хочется делать так же. Мы живем в разных мирах, если ваш опыт говорит о том, профессионал должен работать с говнокодом и работать с начальством которому плевать на мнение специалиста который лучше разберется в своей области, а именно разработке, то живите в этом мире. Я для себя выбрал другой путь и надеюсь наши пути никогда не пересекутся.
Евгений Елчев: живу в обоих мирах. Пишу код и строю свой бизнес. И весь опыт говорит о том, что код сам себя не продает. Более того - сам по себе код, каким бы он идеальным не был, никому не нужен. Говнокод, который продается и приносит прибыль лучше идеального бесполезного кода. Не волнуйтесь на счет пересечения путей - это обязательно случится :)
Евгений Елчев: опыт у меня есть, иначе бы я не ответил. И даже есть отличный пример в тему, как один "плохой" софт под давлением новых разработчиков и халявщиков-клиентов (кто это такие siliconrus.com/2013/05/polzovateli-kotoryie-ne-pla... и https://roem.ru/25-07-2014/109922/otkazalis-ot-dem... компания решила переписать на "новый", "расширяемый" софт. В итоге это принесло все те проблемы, которые я описал в ответе. Негодование старых клиентов (люди не любят перемены), всё те же бесконечные хотелки-запросы, только от других новых клиентов, поддержка теперь уже двух продуктов и расширенный штаб, т.к. старые разработчики заняты поддержкой старого софта, а новые пишут на новой технологии. Собственно, за 3 года разработки компания уже не раз пожалела, что пошла на поводу у программистов и клиентов.
Поэтому, как думаете, сколько процентов наёмных работников считает, что начальник - мудак и делает неправильно, что именно этот работник сделал бы по-другому и получилось бы лучше? Правильный ответ - 100%. Автор вопроса тому пример. А чтобы доказать таким советчикам, что он не прав - что нужно сделать? Правильно, нужно сделать так, как он хочет и только когда всё просрётся он поверит. Будьте реалистами, опирайтесь на цифры, как это делает начальник.
Артем Воронов: DevMan: evnuh: Я не могу понять в чем вы меня пытаетесь убедить? В том что жизнь говно? Почему я работаю именно так как я говорю, а вы говорите, что это не возможно, как может быть невозможно то что уже есть?
Вы накинулись и утверждаете, что бизнесмену виднее, что красота кода не влияет на прибыль. Да кто бы спорил что и говнокод можно продавать. Но все эти паттерны и прочее придумали не для того что бы свое чсв поднимать.
Говнокод может продаваться тоннами на лево и на право. Но если это не сайтик который сделал и забыл, а огромное приложение и внем нет архитектуры а сплошной говнокод. То добавление фич (а фичи добавлять нужно постоянно, в любой сфере, потому что требования меняются) превращается в ад, приходиться содержать больше работников, сроки внедрения растягиваются, компания несет убытки. Если у приложения хорошая архитектура, тесты и прочее то можно сократить отдел разработки иногда в два раза и сократить расходы на несколько миллионов в год и это опять же не какая то моя фантазия, это реальный кейс. У нас в компании идет оптимизация 4ый год., Приложения переписываются, говнокодеры увольняются идет огромная экономия бюджета.
Я устал вам объяснять, реально вам нравиться ваша точка зрения, да пожалуйста, только хватит мне писать и убеждать что то что я вижу каждый день не существует.
Евгений Елчев: тебе никто не говорит что это невозможно, тебе говорят что начальство - на то и начальство, чтобы решать что делать, а что нет.
ты реально не видишь между этим разницы или ты упоротый?
Сайты на WordPress + Интернет магазины WooCommerce
Если руководство потратило 5 лет на это, то ни один аргумент не поможет. У этих людей мозги отморожены. Здравый смысл отсутствует. Не пытайся изменять людей. Это не реально. Просто ищи тех с кем мыслишь схожим образом.
Все можно сделать.... (как бы странно это не звучало....)
1. Нужно составить схему архитектуры, создать список классов и их методов, функций и т.д..
2. Наложить файлы на архитектуру, чтобы понимать где что делается.
3. Затем, рефакторинг архитектуры и кода (если необходимо и есть время).
Продолжать работу.
PS: не очень приятная работа, однако без неё однозначно всё встанет в ближайшем будущем на этом решении без необходимого понимания и документации разработчика.
Не стоит считать владельцев бизнеса идиотами. Возможно текущая CMS заточена под конкретный сегмент покупателей и за счет этого она и продается. Если текущий разработчик CMS уходить, вы вполне можете взять на себя ответственность за развитие этой cms и провести ее рефакторинг. Вылечите болезни этой CMS и спокойное работайте дальше.
Если же хотите переубедить владельца бизнеса, то научитесь считать выгоду не как разработчик, а как бизнесмен. На какую аудиторию заточена CMS, какие текущие расходы на продажи и на разработку(в деньгах, а не абстрактных человеко-часах), во сколько обойдется переход, как изменятся расходы\прибыль при приходе на стандартные CMS? Это всего лишь малая часть вопросов. Предоставьте владельцу веер решений, из которого можно будет выбрать лучшее для бизнеса.
насколько я понял ключевой момент в том что поддерживать старый код вы не хотите.
если зп белая увольнятеся самим может быть не выгодно поэтому дальше вы можете продолжить саботировать разработку + типа пытаясь разобраться в коде, но это будет все медленно, пока не уволят.
хотя фишка может быть в том что увеличивать сроки не так и плохо для бизнеса. лет 5 назад вариантов готовых цмс црм было меньше, сейчас у клиентов есть выбор куда идти и что для них дешевле - развивать старую систему или сделать новую, с учетом того что у них куча инфы в старой и потребуется ее перенос и переобучение персонала. тут все индивидуально - кому то может будет выгоднее продолжать платить больше но оставить все по старому - вы можете убить их бизнес(или принесете урон) если компания откажется развивать эти црм.
желательно донести этот анализ до начальства, сейчас, чтобы были готовы.
- описать проблемы существующего кода/процесс разработки и на что они выливаются
- то что без создателей систем из развитие пойдет гораздо медленнее.
- предложение хотя бы для новых сайтов делать на готовых системах - но тут нужна готовая альтернатива и их сравнение.
- написать вывод то что вы хотите/не хотите развивать старый код и готовы/не готовы уволится если решат оставить старое (то есть например "готов уволится если оставляем по старому" или "мне не нравится старый код но готов остаться и поддерживать его если будет нужно").
написав письмо естественно могут уволить и искать того кто согласится поддерживать и развивать старый код, чтобы заставить сменить систему разработки начальство должно видеть цифры связанные с деньгами, как это выглядит изнутри им пофигу. называть цифры в деньгах напрямую может быть вам будет сложно потому что вы можете не знать конкретных цифр, поэтому называйте цифры - сроки.
правильного решения для бизнеса вы не знаете, вы видите толоько код, а решения могут быть разные
- искать того кто захочет это развивать
- полностью переходить на новую готовую платформу (переводить со старой на новую - вообще не понятно сколько стоит и насколько реально)
- закрыть компанию пока не поздно
- искать промежуточное решение
если это будет написано без эмоций то это сможет принять начальству правильное решение. хотя конечно оно может быть неожиданным и не желательным для вас, например - уволить вас и поднять зп тем кто уходит в 2 раза, чтобы они продолжали это поддерживать, но насколько я понял они сами устали от говнокода и хотят вовремя слиться, поэтому вряд ли их удастся удержать.
раз уж вы любите писать правильный код то и правильные слова тоже не помешает. с начальством нужно дружить и помогать им развивать их бизнес, но принять решение как действовать дальше вы сами не можете.
если об этом не говорить будущего у студии скорее всего нет - вы будете сабоитровать потихоньку (может быть неосознанно - мысли о том что все плохо будут отнимать много энергии, вместо того чтобы тратить ее на работу) - начнут затягиваться сроки, выходить из бюджета - уходить в минуса - работать станет в любом случае не комфортно.
Есть один способ, только тсссс, никому он нем не слова. Берете ящик водки, спаиваете начальника, раздеваете его, раздеваетесь сами, делаете компрометирующие фотки, далее обычный шантаж и дело в шляпе
А на самом деле, зачем задавать этот вопрос тут. Вы приводили эти аргументы начальству? Оно не согласилось? Все, либо терпите, либо уходите. Больше тут обсуждать нечего.
:) Наверняка некоторые сталкивались с похожими ситуациями. Хотелось бы узнать побольше о решении проблемы, чем "терпи" или "уходи". Уверен, есть и иные решения.
Yago: Многие сталкиваются, не спорю, но не такими же ситуациями. Потому что везде люди разные. Где то уходят, где то не видят в этом проблемы, где то наоборот приходят и открывают глаза начальству на то, что предыдущие разработчики впарили какой то мутный процесс разработки, где то нихрена не меняется.
Ваш вопрос звучит, как склеить любую девочку в любой ситуации, но оно так не работает, нет универсальных рецептов.
Yago: Точка зрения? Поговорить, если не поможет уходить. Ну еще можете сделать параллельно проект на том что хотите и показать преимущества на готовом проекте, а не на словах.
