Комментарии 37
Поправочка: в Yii (если по-уму) не практикуется exit(), а практикуется Yii::app()->end(). Это не одно и то же.
Тем не менее, end позволяет обработать прекращение работы перед exit, что сильно лучше, чем просто убить скрипт никому ничего не сообщив. Вы в статье про событийную модель упомянули, вот как раз end — это и есть событие завершения работы.
Ну так вызывайте с нужными аргументами не по умолчанию или переопределите метод. Все таки Yii не заставляет вас использовать exit, это от вас зависит.
убрали бы вы лучше это упоминание про YII в таком контексте, ибо необоснованно — по приведенной вами же ссылки видно, что в Yii::app()->end() вызывается обработчик события прежде чем сработает exit().
Мне кажется, что если в коде есть переменные Костыль1 и Костыль2 да еще и с нецензурными префиксами в имени, то без изменения команды никакими рефакторингами проблемы не решить
К слову, эти переменные в код добавил дотер.
Любопытно услышать, почему.
Я склонен причислять программирование к творческим занятиям, а куда там до творчества без эмоций?
Даже если посмотреть с практической точки зрения, этот стыд хочется выпилить быстрее, чем кучку TODO и FIXME — замечательная мотивация.
Я склонен причислять программирование к творческим занятиям, а куда там до творчества без эмоций?
Даже если посмотреть с практической точки зрения, этот стыд хочется выпилить быстрее, чем кучку TODO и FIXME — замечательная мотивация.
театральные постановки с матом я тоже не понимаю, если уж творишь, то старайся не натворить. И способов передать эмоциональное состояние есть предостаточно, а если не владеешь минимальным их набором то может лучше и не браться?
В программировании на самом деле не должны быть места эмоциям, логика тут правит балом. И если возможно объяснить почему не стал рефакторить можно (сроки и т.п.), то такой нейминг говорит о культуре человека и у него не может быть оправданий.
В программировании на самом деле не должны быть места эмоциям, логика тут правит балом. И если возможно объяснить почему не стал рефакторить можно (сроки и т.п.), то такой нейминг говорит о культуре человека и у него не может быть оправданий.
Вы про use слышали? Или вам нравится namespace полностью писать?
А просто rewrite-ы на уровне веб-сервера не оно? Работать будет в стопицот раз быстрее, без оверхеда и надежнее. Все равно по началу маленькие куски нового фреймворка юзаются.
Вопрос, который мне задают чаще всего, — как разговаривать о рефакторинге с руководителем?
В таких случаях я даю несколько спорный совет: не говорите ему ничего!
Ага молча делать его за свой счет — это надо сильно любить свой проект и работу.
Когда будет вторая часть «Безболезненный рефакторинг фронтенда»?
Ага молча делать его за свой счет — это надо сильно любить свой проект и работу.
Просто в каждую задачу закладывать время на рефакторинг
Это тоже не совсем правильно.
Работодатель должен знать, чем занимаются программисты, как минимум из соображений честности.
И однажды можно услышать совершенно справедливый вопрос от недоинформированного работодателя «А какого, собственно, у вас время уходит в разы больше, чем могли бы сделать другие программисты, или чем вы делали раньше?»
Работодатель должен знать, чем занимаются программисты, как минимум из соображений честности.
И однажды можно услышать совершенно справедливый вопрос от недоинформированного работодателя «А какого, собственно, у вас время уходит в разы больше, чем могли бы сделать другие программисты, или чем вы делали раньше?»
Я на такое б ответил так: «Если вы наняли меня — вы хотели качества. Вы можете нанять другого программиста.»
А вообще если всегда соблюдать такое правило, то не будешь сильно выбиваться за сроки других программистов за счет значительно меньшего технического долга.
И я говорю про то, что в рамках любой задачи необходим рефакторинг (не глобальный и всего проекта, а локальный). Это абсолютно чесно. Вставляете комментарии к статье в бложику — рефакторите связанную с этим часть, а не впихиваете абы как.
А вообще если всегда соблюдать такое правило, то не будешь сильно выбиваться за сроки других программистов за счет значительно меньшего технического долга.
И я говорю про то, что в рамках любой задачи необходим рефакторинг (не глобальный и всего проекта, а локальный). Это абсолютно чесно. Вставляете комментарии к статье в бложику — рефакторите связанную с этим часть, а не впихиваете абы как.
Бизнес нанимает программиста, чтобы заработать денег. Ему не то чтобы сильно важно, что там под капотом. Поэтому когда вы придете к нему и скажете «вы хотели качества», он вас не поймет, и вы поругаетесь. Единственная причина рефакторить — сделать то же самое дешевле, чем это было бы без рефакторинга. Иначе рефакторинг бесполезен.
Во всем должна быть мера.
Бизнес обязан понимать разницу между прототипом и продуктом. У этих двух состояний есть одна цель — получать прибыль. Но если прототип ориентирован на краткосрочный период, то продукт уже озадачен долговременной поддержкой.
Задача рефакторинга (в понятиях бизнеса) — как раз сделать дешевой поддержку. На начальном этапе поддержка не так важна, и есть риск не выбраться из прототипа в условиях быстро меняющихся потребностей.
Ниже отличный коммент про менеджмент vs программисты.
Но по моему опыту все скатывается до «угадали программисты, чего захочет бизнес, или нет». Хорошо, если есть ответственный за это человек в команде, а когда программирование ведется в отрыве от бизнеса, жди беды, если не угадал.
Бизнес обязан понимать разницу между прототипом и продуктом. У этих двух состояний есть одна цель — получать прибыль. Но если прототип ориентирован на краткосрочный период, то продукт уже озадачен долговременной поддержкой.
Задача рефакторинга (в понятиях бизнеса) — как раз сделать дешевой поддержку. На начальном этапе поддержка не так важна, и есть риск не выбраться из прототипа в условиях быстро меняющихся потребностей.
Ниже отличный коммент про менеджмент vs программисты.
Но по моему опыту все скатывается до «угадали программисты, чего захочет бизнес, или нет». Хорошо, если есть ответственный за это человек в команде, а когда программирование ведется в отрыве от бизнеса, жди беды, если не угадал.
Ниже отличный коммент про менеджмент vs программисты.
Вы про мой коммент ниже или про какой? =)
Я вообще сторонник подхода, чтобы не разделять прототип и продукт. Я убежден, что прототип постепенно должен становиться продуктом по мере работы над ним. Самые кривые вещи должны постепенно рефакториться, когда они начинают доставлять неудобства. И таким образом, кривой тяп-ляп прототип постепенно должен превращаться в нормальный продукт. Мне кажется, такая эвристика в большинстве случаев подходит, если надо что-то побыструхе вывести на рынок и протестировать идею. Потому что будем честны, много ли прототипов удается переписать с нуля? Обычно этот шаг откладывается до одного большого «рефакторинга», который никогда не наступает.
Единственная причина рефакторить — сделать то же самое дешевле, чем это было бы без рефакторинга
Вы так недалекоглядны. Не всегда в бизнесе преследуют только краткосрочные цели. В среднесрочной и выше перспективе подход «тяп-ляп» является убыточным для бизнеса. Потому очень редко программисты-быдлокодеры получают большие деньги.
И ни слова о тестах. А без тестов рефакторить это очень и очень плохая затея.
В данном случае я не имею ввиду юнит-тесты. Как по мне, стоил покрыть старый код приемочными тестами. Чтобы знать, что всё старое будет работать на новом коде
В данном случае я не имею ввиду юнит-тесты. Как по мне, стоил покрыть старый код приемочными тестами. Чтобы знать, что всё старое будет работать на новом коде
Вы описали очень хороший способ перехода с одного фреймворка на другой. Но по моему опыту (я писал раньше на Kohana, и пишу теперь на Symfony), степень говнокода — это особенность системы, а не фреймворка, на которой все написано. Если у вас были тяжелые и непонятные контроллеры в Kohana, вас будут ждать такие же в Symfony, и поддерживать это дело на Symfony будет не обязательно проще (а чаще — сложнее, т.к. вы начнете тратить уйму времени на борьбу с фреймворком там, где раньше вы просто делали class Kohana extends Kohana_Core и вворачивали любой костыль). Я бы посоветовал вам бросить ресурсы не на переход от одного фреймворка на другой, а на рефакторинг кода в рамках одного фреймворка. Возможно, имеет смысл начать юзать высококачественные компоненты (Doctrine, symfony/form) в вашем проекте на Kohana. Или начать выносить бизнес-логику из контроллеров в отдельный слой. И это может дать намного больше профита с меньшими затратами, чем переписывать все на другом фреймворке.
У нас всё примерно и происходило по описанному вами сценарию. Началось с подключения DI-контейнера (вынесение бизнес-логики в отдельный слой), логгера (monolog) и мейлера (swiftmailer), потом пришел eventdispatcher и т.д. К моменту, когда мы подумали, что хотим заменить KohanaORM на Doctrine, мы уже использовали бОльшую часть symfony, поэтому решение о переходе целиком на symfony далось нам легко.
Сейчас старый код плавно мигрирует из kohana в symfony, не доставляя головной боли. На переписывание ресурсы практически не тратятся.
Сейчас старый код плавно мигрирует из kohana в symfony, не доставляя головной боли. На переписывание ресурсы практически не тратятся.
Оффтоп. Напомните название сервиса, где можно делать такие «фото» кода, как на первой картинке.
Немного оффтоп.
Я абслютно согласен: рефакторинг — не дело менеджеров или бизнеса. Команда сама должна решать, когда и сколько делать рефакторинг. Единственный критерий тут, и единственная причина делать рефакторинг: как быстрее и дешевле (при заданном бизнесом уровне надежности) сделать для бизнеса то, что ему надо. И тут уже это могут знать только технические специалисты.
Другое дело, что часто менеджемент не доверяет техническим специалистам в этом вопросе. И, кстати, правильно делает =). Потому что очень часто программисты подменяют «быстрее и дешевле» на «нам интереснее». И это часто можно видеть не только от новичков, но и от очень серьезных девелоперов. Когда за счет бизнеса идет обучение новым технологиям или просто развлечение со всякими крутыми штуками.
Отсюда у меня такой вывод: в извечной войне «менеджеры против рефакторинга» программисты должны для начала учиться работать с менеджементом и с бизнесом по одну сторону баррикад. Постепенно работать над этим доверием, когда если программист говорит «нам надо делать А», это значит, что программист совершенно уверен, что для бизнеса «А» будет полезно, а не это просто его прихоть изучить технологию «А».
Я абслютно согласен: рефакторинг — не дело менеджеров или бизнеса. Команда сама должна решать, когда и сколько делать рефакторинг. Единственный критерий тут, и единственная причина делать рефакторинг: как быстрее и дешевле (при заданном бизнесом уровне надежности) сделать для бизнеса то, что ему надо. И тут уже это могут знать только технические специалисты.
Другое дело, что часто менеджемент не доверяет техническим специалистам в этом вопросе. И, кстати, правильно делает =). Потому что очень часто программисты подменяют «быстрее и дешевле» на «нам интереснее». И это часто можно видеть не только от новичков, но и от очень серьезных девелоперов. Когда за счет бизнеса идет обучение новым технологиям или просто развлечение со всякими крутыми штуками.
Отсюда у меня такой вывод: в извечной войне «менеджеры против рефакторинга» программисты должны для начала учиться работать с менеджементом и с бизнесом по одну сторону баррикад. Постепенно работать над этим доверием, когда если программист говорит «нам надо делать А», это значит, что программист совершенно уверен, что для бизнеса «А» будет полезно, а не это просто его прихоть изучить технологию «А».
Для этого в команде и должен существовать IT-директор (CIO), гибрид между бизнес-руководителем и технарём, которому можно объяснить, что после того, как мы переписали 5% кода на технологию А, на том же железе бенчмарки стали летать на 70% быстрее, и который сможет выделить объективно требуемые для рефакторинга ресурсы.
Если его заменить, скажем, руководителем отдела разработки (старшим технарём), получится фигня, поскольку ему тоже может быть что-то по приколу покрутить, а оптимизация бизнеса — вообще не его головная боль.
Если его заменить, скажем, руководителем отдела разработки (старшим технарём), получится фигня, поскольку ему тоже может быть что-то по приколу покрутить, а оптимизация бизнеса — вообще не его головная боль.
Я думаю, что в этом вся и проблема, что многие думают «оптимизация бизнеса — вообще не его головная боль».
Я считаю, что подход «девелоперы беспокоятся про оптимизацию бизнеса» может применяться на абсолютно любого размера проектах, начиная от ситуации, где проект делает 1 девелопер, и для этого не должно быть никаких требований по наличию или отсутствию каких-либо ролей. У нас только так не принято пока что, к сожалению. Вот и страдаем.
Я считаю, что подход «девелоперы беспокоятся про оптимизацию бизнеса» может применяться на абсолютно любого размера проектах, начиная от ситуации, где проект делает 1 девелопер, и для этого не должно быть никаких требований по наличию или отсутствию каких-либо ролей. У нас только так не принято пока что, к сожалению. Вот и страдаем.
1) Не каждый разработчик вообще способен думать об оптимизации затрат.
2) Не каждый из тех, кто способен, хочет об этом думать.
3) Не каждому из тех, кто хочет, готовы за это доплачивать.
2) Не каждый из тех, кто способен, хочет об этом думать.
3) Не каждому из тех, кто хочет, готовы за это доплачивать.
Пункты 2-3 самые прикольные у вас. Получается, программисту надо доплачивать за то, что он будет думать во время работы? И не каждый программист хочет думать во время работы? WAT??? Я всегда думал, что программист должен делать все, что в его силах в свое рабочее время, чтобы сделать работу лучше. Оказывается, нет?
Нет. Любой сотрудник, включая программиста, должен выполнять свою работу в объёме должностных обязанностей, оговорённых в собеседовании и трудовом договоре. Если же должностные обязанности существенно расширились в процессе работы, это хороший повод поставить вопрос либо о соответствующем увеличении оплаты, либо о снижении объёма работы.
Конечно, каждая компания мечтает о фанатиках, которые будут круглосуточно заботиться об их бизнесе, да ещё и за цену обычного программиста, транслирующего ТЗ в код от звонка до звонка. Но таких людей мало, да и однажды обжёгшись в одной компании, в следующей они так себя вести уже не будут.
Конечно, каждая компания мечтает о фанатиках, которые будут круглосуточно заботиться об их бизнесе, да ещё и за цену обычного программиста, транслирующего ТЗ в код от звонка до звонка. Но таких людей мало, да и однажды обжёгшись в одной компании, в следующей они так себя вести уже не будут.
Из моего опыта.
Проблема рефакторинга/легаси кода исчезает насовсем при использовании архитектуры микросервисов.
Должен сказать, что появляется проблема оркестрирования сервисов, но она легко решаема.
Проблема рефакторинга/легаси кода исчезает насовсем при использовании архитектуры микросервисов.
Должен сказать, что появляется проблема оркестрирования сервисов, но она легко решаема.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как переписать большой проект или безболезненный для бизнеса рефакторинг