Comments 27
И как вы заметили, их и наш миры очень отличаются, и чем там меньше пересечения, тем обеим сторонам спокойнее.
А что менеджер может сказать про код...
Менеджер может сказать, например — Я вчера беседовал с Владимиром, он тоже классный программист, но ты его не знаешь, так вот он сказал, что Ларавель это хрень и с ним ничего делать нельзя, вам бы побеседовать — может ты хоть чему путнему у него научишься.
Лучше менеджерам не совать нос в то, в чем они не разбираются, а оставить это дело тех лиду, или тому, кто выполяет его обязанности, он лучше решит к кому прислушаться, если что.
После этого желание научных споров пропадает. Может потому что никакой практической пользы под этим нет?
Если эти миры не будут пересекаться, то деньги-то откуда брать на реализацию продукта? Продавцам необходимо понимать, что деньги, приведенные ими в компанию, делятся и на программистов не просто так, а чтобы потом продавалось лучше. Если продавец покажет клиенту, что знаком с темой некоторой проблемы и вразумительно объяснит причины/следствия исправлений, то такой продавец будет иметь успех и у клиентов и у программистов. Это я как программист сейчас пишу, надеюсь автор не будет ругаться, что нарушил запрет.
вразумительно объяснит причины/следствия исправлений
Мне до сих пор интересно — как согласуют бюджет на рефакторинг?
Я пытаюсь поставить себя на место инвестора — зачем давать деньги, если в результате будет тоже самое?
Я понимаю почему это интересно программистам.
Но я пока не могу понять почему на это дают деньги которые можно потратить по другому.
P.S. А есть и более фантастические кейсы. Например — остановить разработку новых бизнес-фич на полгода и сменить архитектуру незавершенного проекта. Как удалось согласовать раздувание штата и бюджета я не могу понять.
Это, очевидно, нужно, когда из-за плохой кодовой базы/большого тех-долга стоимость разработки из начального «n» выростает до «10n» и становится экономически выгодно потратить один раз ресурсы(деньги) «1000n» на рефакторинг, что бы стоимость стала снова не «10n», а, например, «2n», чем терпеть прогнозируемый экспоненциальный рост стоимости разработки.
Конечно, если это делается слишком часто и без достаточного обоснования, то это убыточно.
Сначала вы наняли таджиков, которые за три дня поклеили обои, переложили плитку и постелили пол. Быстро? Быстро. Красиво? Красиво! Выглядит так, как вы хотели? Да. Гостей позвать можно? Конечно.
Так вот, это прототип, MVP. Проблема в том, что когда вы начнёте двигать мебель, пол уедет вместе с ней, обои отвалятся от первой же повешенной картины, а плитка облетит подобно осенней листве уже через полгода.
Чтобы этого не произошло, вы зовёте бригаду проверенных молдован и говорите: хочу всё то же самое, только надёжно. И они сначала неделю отскребают всё до бетона, а потом месяц делают заново. Внешний вид получается такой же, но с этим ремонтом ещё ваши внуки жить смогут.
Вот это и был рефакторинг.
Имеем классическое определение.
Рефакторинг — это контролируемый процесс улучшения кода, без написания новой функциональности.
Ключевое словосочетание — новая функциональность.
вы начнёте двигать мебель
Мебель на новом месте это уже изменение функциональности и архитектуры начального проекта, никак не рефакторинг.
Рефакторинг это например так — «Cнять обои и вместо белой штукатурки положить розовую. Поклеить обои ».
Еще раз. Я понимаю, зачем рефакторинг программистам. Но я не могу понять, как бизнес дает на это деньги.
Хотя конечно у меня есть подозрения зачем это делается, но это к программированию это не имеет никакого отношения.
Двигать мебель — фича, которую хочет заказчик.
Он может двигать мебель без рефакторинга, но тогда возникнет куча проблем, которые нужно будет исправлять по одной каждый раз.
А может сделать рефакторинг, чтобы двигать шкаф без проблем, а потом еще и кровать, тумбу, whatever. При этом ремонт делается один раз и качественно.
Ключевое словосочетание — новая функциональность.
В моём примере её и не будет: квартира будет выглядеть абсолютно так же.
Мебель на новом месте это уже изменение функциональности и архитектуры начального проекта, никак не рефакторинг.
Это будущие проблемы, которые появятся, если рефакторинг не провести.
Рефакторинг это например так — «Cнять обои и вместо белой штукатурки положить розовую. Поклеить обои ».
Вот именно. Я ж так и написал: ободрать всё до бетона и сделать заново, но надёжно — ведь розовая штукатурка крепче, чем белая, верно?
ведь розовая штукатурка крепче, чем белая, верно?
Вовсе нет, она просто другого цвета.
Происходит примерно так:
- требуется услуга дизайнера чтобы согласовать цвет
- отдельный штукатур что бы снять старую штукатурку
- розовый цвет еще поискать надо по магазинам
- со старой штукатуркой мог работать один штукатур, а новая потребует трех
- плюс отдельный подсобный рабочий размешивать раствор( технология приготовления штукатурки то изменилась)
А клиенту — та же самая комната. И пока меняют штукатурку и переклеивают обои — клиент живет где то в другом месте.
По жизни рефакторинг он вот примерно такой ;-)
Как инвестиции в обновление основных фондов или как возврат кредитов.
Лайфхак, как описать красивый код в финансовых терминах: стоимость поддержки.
Если код — минное поле, то трудозатраты на его поддержку — гигантские. Да, можно сэкономить на написании исходного продукта, а потом вкладывать в него кучу трудозатрат в поддержку, а можно и наоборот.
Но тут есть другой момент, связанный с общей стоимостью решения на всем сроке его жизни. Если то, что вы пишите, будет использоваться десятилетия (что для рынка IT. в энтерпрайзе, в принципе, нормально) то выгоднее писать хороший код. Эсли же это игрушка в плец маркете, жизненный цикл которой — год, если повезёт, то хороший код там не выгоден экономически.
fillpackart на минималках. Грустное зрелище.
Специально для подобных точек зрения
не плохой метод мотивации работника, если нельзя деньгами :), которые я понимаю и разделяю, разъясню по другому. Деньги — они обычно позволяют планировать на срок порядка года, а есть явления, которые живут десятилетиями, и их неэффективно измерять деньгами.
Статья описывает любое производство. Можно заменить программистов на авиастроителей, ничего не изменится.
Насчёт денег. Есть две величины: стоимость разработки и стоимость поддержки.
Смежные понятия из экономики — CAPEX и OPEX.
Этими величинами можно оперировать. Уменьшение стоимости разработки порождает техдолг, что увеличивает стоимость поддержки. И наоборот — рефакторинг уменьшает стоимость поддержки, но для этого придется потратить ресурсы разработки здесь и сейчас.
Если руководитель разработки при планировании будет оперировать именно этими величинами, то сможет разговаривать на языке денег с бизнесом, что очень удобно: позволит согласовывать время на рефакторинг и обосновать важность поддержки кодовой базы в хорошем состоянии.
И оставьте уже
Полюбите во мне программиста