alekciy
Новичок
Какие методики/алгоритмы лучше применить для поддержания версионности кода? Как я понимаю готового решения нет и нужно писать свое, но хотелось бы подумать для начала, как наиболее оптимальнее это выполнить. Пока возникает такой вариант.
Начальные условия: два класса (модуль или какая другая программная единица кода, в общем некая сущность), пусть X и Y, два разработчика. Класс Y (назовем его класс-клиент) связан с X (назовем его класс-сервер) через метод m(), т.е. класс Y знаем, чьим клиентом он является. При этом X совершенно не знает, кто использует его метод m, но у него есть публичное свойство в котором содержится версия. При этом глобально принята семантическая схема именования версий ("Семантическое управление версиями 1.0.0-rc.1").
Ситуация: Изменилась сигнатура (поэтому увеличился номер мажорной версии) метода m и в id теперь не целое, а массив:
Соответственно разработчику класса Y нужно изменить метод n().
Проблема: Когда есть много кода и много разработчиков вероятность поломки связанного кода становится высока. В принципе, даже при одном разработчике это актуально, порой упомнить и проконтролировать все связи нереально либо же затратно. Поэтому очень хочется иметь возможность знать, где и что изменилось и какие другие части системы это может затронуть, а так же иметь возможность заранее предусмотреть изменения.
Решение: Сейчас мне видится наиболее разумным такая схема. Добавляем глобально класс-реестр который хранит связи между классами и версии, а так же информацию в духе email каждого автора класса. Каждый класс содержит в себе не только номер текущей версии, но и будущей планируемой и предыдущей. Класс-клиент всегда знает, чьим клиентом он является и с какой версией класса-сервера работает.
Алгоритм изменения кода:
1) В классе увеличили номер будущей версии, но сам код ни как не изменяем еще.
2) Вызываем метод класса-реестра сообщая ему о нашем намерение.
3) Реестр посмотрел, кто подписан на данный класс и уведомил все заинтересованных лиц.
4) Авторы классов-клиентов посмотрели, касаются ли их изменения (может сменился метод который они не используют) и если касаются, то вносят изменения в свой код (по сути вводят новую ветку исполнения кода [реализовать можно банальным if ($current_version = будующая_версия) {} elseif ($current_version = текущая_версия) {}] параллельно с текущей, что бы когда будущая версия кода-сервера стала текущей выполнялась эта ветвь).
5) Изменяем класс-сервер, сменяем номера версий, уведомляем реестр о новой текущей версии.
Ни чего не сломалось, потому как связанный код под новые условия уже должен быть изменен.
Цели:
а) в пределах двух версий (текущей и будущей) быть уверенным в работоспособности системы состоящей из кода разных разработчиков (что не исключает полезности этого и для одного разработчика);
б) иметь возможность в любой момент времени узнать, какие части будут затронуты при изменении одной из компонент, это позволит более точнее определять фронт работ.
Мысли? Соображения? Дополнения?
Понятно, что реализация может варьироваться в широких пределах. К примеру, я не уверен, что класс-реестр так необходим, в конечно итоге классы-клиенты могут содержать эту информацию с себе. Кроме того идею можно расширить и хранить не только версию, но и список изменений (в данном случаем изменившиеся методы/свойства).
Начальные условия: два класса (модуль или какая другая программная единица кода, в общем некая сущность), пусть X и Y, два разработчика. Класс Y (назовем его класс-клиент) связан с X (назовем его класс-сервер) через метод m(), т.е. класс Y знаем, чьим клиентом он является. При этом X совершенно не знает, кто использует его метод m, но у него есть публичное свойство в котором содержится версия. При этом глобально принята семантическая схема именования версий ("Семантическое управление версиями 1.0.0-rc.1").
PHP:
<?php
class X
{
public static
$version = '0.1.0';
public function m()
{
return array(
'id' => 1,
);
}
}
class Y
{
public static
$varsion = '0.1.0';
public function n()
{
$X = new X();
$var = $X->m();
// что-то делаем с $var
}
}
PHP:
<?php
class X
{
public static
$version = '1.0.0';
public function m()
{
return array(
'id' => array(),
);
}
}Проблема: Когда есть много кода и много разработчиков вероятность поломки связанного кода становится высока. В принципе, даже при одном разработчике это актуально, порой упомнить и проконтролировать все связи нереально либо же затратно. Поэтому очень хочется иметь возможность знать, где и что изменилось и какие другие части системы это может затронуть, а так же иметь возможность заранее предусмотреть изменения.
Решение: Сейчас мне видится наиболее разумным такая схема. Добавляем глобально класс-реестр который хранит связи между классами и версии, а так же информацию в духе email каждого автора класса. Каждый класс содержит в себе не только номер текущей версии, но и будущей планируемой и предыдущей. Класс-клиент всегда знает, чьим клиентом он является и с какой версией класса-сервера работает.
Алгоритм изменения кода:
1) В классе увеличили номер будущей версии, но сам код ни как не изменяем еще.
2) Вызываем метод класса-реестра сообщая ему о нашем намерение.
3) Реестр посмотрел, кто подписан на данный класс и уведомил все заинтересованных лиц.
4) Авторы классов-клиентов посмотрели, касаются ли их изменения (может сменился метод который они не используют) и если касаются, то вносят изменения в свой код (по сути вводят новую ветку исполнения кода [реализовать можно банальным if ($current_version = будующая_версия) {} elseif ($current_version = текущая_версия) {}] параллельно с текущей, что бы когда будущая версия кода-сервера стала текущей выполнялась эта ветвь).
5) Изменяем класс-сервер, сменяем номера версий, уведомляем реестр о новой текущей версии.
Ни чего не сломалось, потому как связанный код под новые условия уже должен быть изменен.
Цели:
а) в пределах двух версий (текущей и будущей) быть уверенным в работоспособности системы состоящей из кода разных разработчиков (что не исключает полезности этого и для одного разработчика);
б) иметь возможность в любой момент времени узнать, какие части будут затронуты при изменении одной из компонент, это позволит более точнее определять фронт работ.
Мысли? Соображения? Дополнения?
Понятно, что реализация может варьироваться в широких пределах. К примеру, я не уверен, что класс-реестр так необходим, в конечно итоге классы-клиенты могут содержать эту информацию с себе. Кроме того идею можно расширить и хранить не только версию, но и список изменений (в данном случаем изменившиеся методы/свойства).
