Кроспроектный код и рефакторинг
Обычно делается так: интерфейс меняется, но постепенно — сначала методы, которые хочется прибить помечаются deprecated, а затем только (недели через 2-3) они прибиваются. За это время разработчики других проектов должны успеть перейти на новый интерфейс. Тем более, что обычно это означает потратить 5 минут времени и сделать хорошо.
А, ну еще очень помогает Continuous Builds — если какой-то проект перестал билдиться, это сразу видно.
При этом, если еще и unit-тесты гоняются, совсем легко понять — работает проект или очень аккуратно сломан.
При этом, если еще и unit-тесты гоняются, совсем легко понять — работает проект или очень аккуратно сломан.
Первый способ требует офигенного начального проектирования и не факт, что потом всё равно интерфейс не поменяется.
Второй способ - самый реальный. Обход проблем - это, во-первых, чёткая система версионирования библиотеки, когда любой продакшн-проект работает только с конкретной версией библиотеки, а также поддержка обратной совместимости в случае, если изменения серьёзные. В частности, через логирование попыток использования deprecated-методов, как уже написали.
Второй способ - самый реальный. Обход проблем - это, во-первых, чёткая система версионирования библиотеки, когда любой продакшн-проект работает только с конкретной версией библиотеки, а также поддержка обратной совместимости в случае, если изменения серьёзные. В частности, через логирование попыток использования deprecated-методов, как уже написали.
Можно и просто модифицировать библиотеку. Те, у кого проект не скомпилится (что обнаружится при следующем апдейте быстро переведут его на новый интерфейс (а куда деваться?) или пнут того, кто библиотеку модифицировал 
.
.или останутся на старой версии библиотеки, с которой всё прекрасно работает.
в условиях, когда всё должно быть сделано ещё вчера, это наиболее вероятный сценарий, по-моему.
в условиях, когда всё должно быть сделано ещё вчера, это наиболее вероятный сценарий, по-моему.
1. Ты по-тихому отрефакторил библиотеку и пошел домой
2. Утром заказчик по одному из проектов звонит и говорит, что в одной из программ, которые используют библиотеку, найден баг, надо срочно исправить — 10000 человек в разных отделениях ждут
3. Разработчик этой программы вынужден прежде, чем искать баг, судорожно править код проекта, чтобы он хотя бы компилился. При рефакторинге что-то сломалось (случайно и когда программа скомпилирована там уже более одного серьезного бага.
Правильно, когда:
1. На исправление срочных вещей тратится мало времени
2. Программа проходит состояния либо "Правильно - неправильно - правильно" (рефакторинг либо "неправильно-правильно" (поиск и исправление ошибки).
И плохо, если у нас состояние "неправильно-неправильно-неправильно-неправильно-WTF!-все еще неправильно-кажется правильно"
2. Утром заказчик по одному из проектов звонит и говорит, что в одной из программ, которые используют библиотеку, найден баг, надо срочно исправить — 10000 человек в разных отделениях ждут
3. Разработчик этой программы вынужден прежде, чем искать баг, судорожно править код проекта, чтобы он хотя бы компилился. При рефакторинге что-то сломалось (случайно и когда программа скомпилирована там уже более одного серьезного бага.
Правильно, когда:
1. На исправление срочных вещей тратится мало времени
2. Программа проходит состояния либо "Правильно - неправильно - правильно" (рефакторинг либо "неправильно-правильно" (поиск и исправление ошибки).
И плохо, если у нас состояние "неправильно-неправильно-неправильно-неправильно-WTF!-все еще неправильно-кажется правильно"
И плохо, если у нас состояние "неправильно-неправильно-неправильно-неправильно-WTF!-все еще неправильно-кажется правильно"Пропустил состояние "ааааааачтожеделатьааааааа".
я ща как раз в таком. круто!
1. Если баг срочный, то можно откатиться к предыдущей версии библиотеки.
2. Исправлять по-хорошему нужно в таге (в котором вносить изменения в интерфейсы библиотек не следует а не в текущей постоянно меняемой версии.
2. Исправлять по-хорошему нужно в таге (в котором вносить изменения в интерфейсы библиотек не следует а не в текущей постоянно меняемой версии.
так с этого и надо было начинать
ты говоришь об наличии у библиотеки версий, и когда понятно, где искать предыдущую рабочую версию
а эхту мысль уже более четко высказал yoжик =)
ты говоришь об наличии у библиотеки версий, и когда понятно, где искать предыдущую рабочую версию
а эхту мысль уже более четко высказал yoжик =)
1. Если баг срочный, то можно откатиться к предыдущей версии библиотеки.1. Можно, но лучше, когда сразу все хорошо. нет?
2. Исправлять по-хорошему нужно в таге (в котором вносить изменения в интерфейсы библиотек не следует а не в текущей постоянно меняемой версии.
2. Исправлять лучше в текущей версии (если процесс поставлен и текущая версия — всегда рабочая). Иначе окажется, что какие-то баги где-то исправлены, а в текущей версии они есть и таким образом могут второй раз уйти к клиенту.
Но твой подход — тоже работает.
Оставить комментарий
6yrop
Меня давно интересует вопрос: как организовывать код, который используется в нескольких проектах, но в одной компании (т.е. внутренние библиотеки). Общая библиотека выставляет некоторый интерфейс, в связи с этим есть два варианта1. Жесткий интерфейс.
Плюс:
проекты становятся более независимыми. Например, разработчик общей библиотеке может не иметь прав доступа к сорцам всех проектов, где используется эта общая библиотека.
Минусы:
интерфейс надо придумать (т.е. он не сам складывается из реальных потребностей на текущий момент)
очень неудобный рефакторинг. Автоматического рефакторинга вообще нет, ручной тоже осложняется.
2. Меняющийся интерфейс
Минус:
если это VS, то надо поддерживать один солюшен со всеми проектами.
Сейчас столкнулся с ситуацией, когда наш архитектор настаивает на Жестком интерфейсе. Речь идет о небольшой тулзевене. Тулзевена живет своей жизнью уже больше полутора лет — дорабатывается, фиксится, это происходит не часто, но происходит. В начале я тоже хотел придерживаться первого варианта, но через некоторое время перешел на второй и это мне нравилось.
Вопрос: имеет ли право на существование второй вариант? и если имеет, то когда стоит переходит на первый вариант?