Библиотека сайта rus-linux.net
Проект Yocto
Глава 23 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: The Yocto Project
Автор: Elizabeth Flanagan
Перевод: А.Панин
23.3. Заключение
После моих дискуссий с членами сообщества и личных исследований, я установила несколько областей, в которых некоторые вещи, возможно, должны были быть реализованы иначе, а также усвоила несколько ценных уроков. Важно отметить, что оценка десятилетней разработки не участвующим в ней человеком не является критикой тех, кто вложил свое время и усилия в весь этот замечательный набор программного обеспечения. Говоря от лица разработчиков, наиболее сложной частью нашей работы является прогнозирование того, что нам понадобится спустя годы и как мы могли бы спроектировать фреймворк, чтобы эти возможности работали прямо сейчас. Без некоторых проблем это удается только единицам.
Первый усвоенный урок заключается в том, что нужно быть уверенным в необходимости разработки соответствующей стандартом документации с четкими формулировками, которая понятна сообществу. Она должна проектироваться с учетом максимальной гибкости и последующего развития.
Одной из областей, где я лично столкнулась с недоработкой документации является моя работа над классом создания отметки лицензии из состава OE-Core, а в особенности данная недоработка проявилась при работе с переменной LICENSE. Так как не существовало четко документированной стандартизации того, что может содержать переменная LICENSE, обзор множества доступных рецептов показал значительные различия в объявлениях. Различные строки, являющиеся значениями переменной LICENSE, содержали все что угодно, от значений, использующих абстрактно-синтаксисические деревья Python в строковом представлении, до значений, вероятность извлечения полезных данных из которых была крайне мала. Существовало соглашение, которое обычно использовалось в сообществе; однако, это соглашение предполагало различные варианты, некоторые из которых были менее корректными, чем другие. Эта проблема не была вызвана действиями разработчиков, которые создавали рецепт; она была вызвана неспособностью сообщества выработать стандарт.
Хотя небольшая предварительная работа со значением переменной LICENSE помимо проверки ее существования все таки была проведена, о стандартизации значений данной переменной никто не позаботился. Большую часть проблем удалось бы избежать в случае заблаговременной разработки поддерживаемого всеми стандарта в масштабе проекта.
Следующий усвоенный урок является более общим и относится к недоработке, наблюдаемой не только в рамках проекта Yocto, но и в других крупномасштабных проектах, находящихся в зависимости от архитектуры системы. Одна из наиболее важных идей для разработчиков, позволяющая ограничить трудозатраты по копированию, рефакторингу и удалению кода, с необходимостью которых они могут столкнуться при работе над проектом, формулируется следующим образом: тратьте время - много времени - на проектирование интерфейсов и проработку архитектурных решений.
Если вы думаете, что потратили достаточно времени на работу над архитектурой, вероятно, это не так. Если вы думаете, что потратили недостаточно времени на работу над архитектурой, то это несомненно так и есть. Затраты большего количества времени на проектирование интерфейса не усложнят последующие операции по удалению кода или даже реализации значительных архитектурных изменений, но, несомненно, сократят объем повторной разработки в долгосрочной перспективе.
Проектируйте свое программное обеспечение так, чтобы оно было настолько модульным, насколько это возможно, ведь рано или поздно вы будете возвращаться к некоторым участкам кода для проведения любых операций начиная с небольших исправлений и заканчивая повторной разработкой, а когда вам все таки придется работать с кодом, его замена станет менее сложной.
Очевидной областью, в которой такой подход мог помочь проекту Yocto, является установление потребностей конечных пользователей, эксплуатирующих системы с малым объемом оперативной памяти. В том случае, если бы реализация хранилища данных BitBake была заранее более тщательно продумана, возможно, нам удалось бы спрогнозировать вероятность появления проблем, связанных с тем, что хранилище данных занимает большой объем памяти, и заранее доработать его.
Данный урок заключается в том, что хотя и практически невозможно предугадать каждую из проблем, с которой столкнется ваш проект в период своего существования, выделение времени для серьезного планирования его интерфейса может помочь в снижении последующих трудозатрат. Проекты BitBake, OE-Core и Yocto являются удачными в этом плане, так как большое количество работы над их архитектурой было произведено на ранних стадиях развития. Это обстоятельство позволило нам произвести значительные изменения архитектуры проекта без больших сложностей и ущерба проекту.
23.4. Благодарности
Во-первых, благодарю Chris Larson, Michael Lauer и Holger Schurig, а также многих других людей, которые вносили свой вклад в развитие BitBake, OpenEmbedded, OE-Core и проекта Yocto в течение многих лет. Также благодарю Richard Purdie за то, что он предоставил в мое распоряжение свой мозг и помог разобраться как в исторических, так и в технических аспектах OE, а также за его постоянную поддержку и руководство, особенно в случаях исследования некоторых магических аспектов BitBake.
Далее: К началу статьи