Библиотека сайта rus-linux.net
GDB
Глава 4 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: GDB
Автор: Stan Shebs
Перевод: А.Панин
4.11. Выученные уроки
Открытый процесс разработки является выигрышным решением
Приложение GDB изначально являлось экземпляром программного обеспечения, созданного в процессе применения "соборной" модели разработки, в рамках которой мэйнтейнер осуществляет непосредственное управление исходным кодом, а весь остальной мир наблюдает за прогрессом разработки только при периодической публикации копий исходного кода. Применение такой модели обосновывалось относительным непостоянством в отправке патчей, но на самом деле закрытый процесс разработки сам по себе препятствовал созданию патчей. После перехода к открытому процессу разработки количество патчей стало таким большим, каким не было никогда ранее, причем качество кода осталось таким же высоким, как и было ранее, а в некоторых случаях повысилось.
Создавайте план, но ожидайте его изменения
Процесс разработки приложения с открытым исходным кодом по своей сути является хаотичным, так как отдельные лица в течение определенного промежутка времени работают над кодом, после чего прекращают работу, возлагая обязанности по продолжению разработки на других.
Однако, в данном случае все еще уместно создавать план разработки и публиковать его. Он может помочь в координации действий разработчиков в том случае, ели они работают над реализацией взаимосвязанных возможностей, он может быть показан потенциальным спонсорам, а также он может помочь желающим поучаствовать в развитии проекта лицам в размышлениях о том, чем именно им стоит заняться.
При составлении плана не следует обозначать точные даты и промежутки времени; даже в том случае, если кто-либо проявляет энтузиазм при работе в определенном направлении, очень маловероятно то, что люди смогут гарантировать работу в течение полного рабочего дня в течение такого длительного промежутка времени, который позволит завершить работу до выбранной даты.
По этой причине не нужно цепляться за план в случае истечения указанных в нем сроков. В долговременной перспективе в рамках разработки проекта GDB был составлен план реструктуризации приложения и выделения библиотеки libgdb с четко заданным API, которая могла бы связываться со сторонними приложениями (в особенности с приложениями, реализующими графические интерфейсы); при этом даже был изменен процесс сборки с целью компиляции библиотеки libgdb.a на промежуточном шаге. Несмотря на то, что идея о создании библиотеки периодически озвучивалась впоследствии, преимущества интегрированной среды разработки Eclipse и машинного интерфейса отодвинули обоснование необходимости создания библиотеки на второй план, а в январе 2012 года мы отвергли концепцию библиотеки и на данный момент занимаемся удалением теперь уже не нужных фрагментов кода.
Все было бы идеально, если бы мы обладали незаурядным умом
После обзора некоторых произведенных нами изменений, вы можете подумать: "Почему с самого начала все не было сделано правильно?" Ну, мы были просто не достаточно умны.
Конечно же, мы могли ожидать, что отладчик GDB станет чрезвычайно популярным и будет перенесен на десятки и десятки архитектур для осуществления и непосредственной и удаленной отладки. Если бы мы знали это, мы начали бы разработку с создания объектов gdbarch вместо усовершенствования старых макроопределений и глобальных переменных в течение нескольких лет; то же самое можно сказать и о векторах целевых систем.
Конечно же, мы могли догадываться о том, что GDB будет использоваться с графическими интерфейсами. Кроме того, в 1986 году как Mac, так и X Window System уже существовали в течение двух лет! Вместо проектирования традиционного интерфейса командной строки, мы могли создать интерфейс для асинхронной обработки событий.
При этом в реальности урок заключался не в том, что разработчики GDB были глупы, а в том, что мы, возможно, не были достаточно прозорливы и не имели представления о том, как должен развиваться проект GDB. В 1986 году вообще не было очевидным тот факт, что использующий мышь оконный интерфейс начнет применяться повсеместно; в том случае, если бы первая версия GDB была в совершенстве адаптирована для использования с графическим интерфейсом, мы бы выглядели как гении, но это была бы всего лишь случайная удача. Вместо этого, улучшая работу GDB в одной ограниченной области, мы сформировали пользовательскую базу, которая позволила нам в будущем увеличить темпы разработки и повторного проектирования.
Следует учиться жить с незавершенными переходами к использованию новых технологий
Пытайтесь довести до конца переход к использованию новых технологий, хотя этот процесс и может занять некоторое время; будьте готовы работать в условиях незавершенных переходов.
На саммите разработчиков GCC в 2003 году Zack Weinberg сожалел о "незавершенных переходах к использованию новых технологий" в рамках проекта GCC, при осуществлении которых новая инфраструктура была введена в строй в то время, как старая инфраструктура не могла быть свернута. В проекте GDB тоже присутствуют такие переходы, но в то же время мы можем привести в пример несколько переходов, которые были успешно завершены, таких, как переход к использованию векторов целевых систем и переход к использованию gdbarch. Несмотря на это, для их реализации потребовалось несколько лет и в течение этого времени приходилось поддерживать отладчик в работоспособном состоянии.
Старайтесь не сильно привязываться к коду
В ситуации, когда вы в течение длительного промежутка времени работаете с отдельным фрагментом кода, причем вы работаете с важной программой, достаточно легко привязаться к этому коду, причем в этом случае вы будете даже формировать свои мысли в соответствии с этим кодом, а не наоборот.
Старайтесь избегать таких ситуаций.
Любой фрагмент кода создавался на основе осознанных решений: некоторые из решений приняты в большей степени под впечатлением от чего-либо, некоторые - в меньшей степени. Умное принятое в 1991 году решение, заключающееся в уменьшении объема используемой оперативной памяти, является лишим усложнением кода в 2011 году, когда вполне доступны объемы оперативной памяти, исчисляющиеся гигабайтами.
Когда-то отладчик GDB мог работать с суперкомпьютером Gould. Когда примерно в 2000 году была выведена из строя последняя подобная машина, пропал весь смысл поддержки этой системы. Данный эпизод является иллюстрацией процесса удаления кода из состава GDB, причем на сегодняшний день при выпуске большинства релизов та или иная часть кода считается устаревшей и удаляется.
Фактически существует список радикальных изменений, которые уже запланированы или реализуются и варьируются от применения языка Python для реализации сценариев до поддержки отладки приложений на многопроцессорных системах с высокой степенью параллелизма и перехода к использованию языка программирования C++. Для реализации этих изменений могут потребоваться годы; поэтому у нас есть еще больше оснований для начала работы над их реализацией прямо сейчас.
Вернуться к началу статьи.