Рефакторинг в системном администрировании

Материал из Xgu.ru

Перейти к: навигация, поиск
stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.


Короткий URL: refactoring


[править] Мысли

  • Что такое рефакторинг
  • Методы, использующиеся при рефакторинге


  • Не ломалось, не чини
  • Администрирование хаоса
  • Понижение энтропии
  • Снижение хаоса
  • Unixway
  • Запись в консоли

Анализ сделанных записей (преобразование, сокращение)

  • Переход на другие
  • Применение методов управления исходным кодом для управления виртуальными машинами (бранчи, мерджи, коммиты и прочее)


[править] Ещё мысли

Я сочувствовал цисководам во многом и завидовал в одном --- они могут попасть на любой маршрутизатор и, дав элементарную команду: sh run могут составить представление об его конфигурации.

C Unix-системой не всё так просто. Программное обеспечение может быть проинсталлировано какое угодно, оно вообще может быть собрано из исходников, да ещё и с какими-угодно патчами, наложенными на код. Конфигурационные файлы могут правиться по собственному вкусу, да и они могут быть рассеяны по системе и находиться в совершенно неожиданных местах.

Если предположить, что во всех системах используется один и тот же дистрибутив, и все администраторы следуют одинаковым правилам по настройке, ситуация упрощается, но не полностью. Конфигурационные файлы имеют достаточно большую свободу для редактирования, которая регламентирована, но всегда есть пространство для маневра.



Задача.


Необходимо сказать, каким образом систему можно поднять из состояния инсталляции из дистрибутива до текущего состояния.


Существует исходная система. В процессе эксплуатации этой системы с ней выполняются разнообразные операции по настройке (инсталлируется программное обеспечение, меняются конфигурационные файлы, меняются имена и местоположение файлов в файловой системе).


Вопрос в том, можно ли показать обозримую (наглядную и понятную человеку) процедуру по превращению чистой системы в существующую систему. Речь идёт только о настройках системы, не о данных.

Процедура должна быть формализована настолько, что её можно поручить компьютеру, то есть, выполнять автоматически.


Говоря конкретно, нужен механизм, который сможет в любой момент предоставить скрипт, с помощью которого можно чистую систему (например, debootstrap) довести до текущего состояния.


[править] Читаемость скрипта настройки

Очень желательно чтобы процедура была читаемой. Это означает, что

  1. Она должна быть максимально простой (действия, которые можно удалить из неё, должны быть удалены)
  2. Если при настройке были сделаны какие-то комментарии, они должны присутствовать в процедуре в наиболее подходящих местах.




Интересные задачи, связаные с этой.

  1. Мы решили отрефакторить систему. Можно ли как-то это делать не в живой системе, а в скрипте настройки?
  2. В процессе рефакторинга мы решили, что разделим одну систему на несколько. Можно ли сделать процесс превращения скрипта доточки в несколько скриптов максимально автоматизированным?




Создание разностных пакетов:


Рефакторинг:


Practically, refactoring means making code clearer and cleaner and simpler and elegant. Or, in other words, clean up after yourself when you code. Examples would run the range from renaming a variable to introducing a method into a third-party class that you don't have source for.


В результате мы должны получить наглядное представление о том, что именно сделано в системе. Мы берём существующую систему A1, берём чистую систему A0 и сравниваем их. Изменения должны быть наглядными, они должны давать точное представление о том, как привести систему A0 в A1.