Что представляет себе человек, не связанный с разработкой приложений, слыша про неё? Для него при “Разработке приложения” программист просто пишет код в специальном поле специального приложения, после чего у него, потребителя, появляется сразу готовый к работе сервис. Естественно, такое мнение очень далеко от истины. Разработка приложения - это полноценный процесс, состоящий не только из написания кода, но и из сборки проекта из исходных файлов, тестирования и отладки, написания документации, дополнительных демонстрационных файлов. Часто эти пункты многократно повторяются: написал код, собрал, начал тестировать - всё сломалось. Снова пишешь код с иправлениями, снова собираешь, снова тестируешь и так далее. Вот весь этот цикл - это разработка as is.

В курсе мы пройдём по каждому этапу разработки отдельно (как выглядит это самое разделение на этапы, мы описали ниже), немного поговорим о том, как сделать нормальную сборку продукта. Акцент на наличии сборки здесь не просто так: на практике наряду со схемой разработки полного цикла применяется метод “написать исходники и оставить сборку пользователям”. Это позволяет конечному потребителю самому настроить необходимый ему комплект услуг собираемого сервиса или даже дописать свой модуль (если лицензия позволяет). Однако такая разработка подразумевает умение будущих пользователей самостоятельно проводить сборку конечного продукта, что требует и необходимых сборочных приложений, и просто понимания, что и как нужно делать. Так что это на любителя.

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

Этапы разработки приложения

Курс разработки состоит из трёх этапов: Редактирование - Сборка/Запуск - Тестирование

Когда где-то говорят о разработке, рядовой слушатель представляет себе под всем процессом только редактирование. При этом, как мы уже упоминали, для большинства этот процесс напрямую связан с IDE - Integrated Development Environment - средами разработки. Вообще говоря, современные среды разработки объединяют в себе все или почти все этапы разработки: в них “из коробки” (или из встроенного установщика расширений) идут тонны рецептов сборки, тестирования, там удобно писать многофайловые проекты, запускать и отлаживать их.

НО. Для нас важно изучить процесс разработки, а не просто пользоваться уже написанными благами, поэтому мы будем использовать отдельные компоненты и разбираться с каждым по очереди.

Сборочное Окружение

В отрыве от больших IDE разберёмся, что из себя составляет всё сборочное окружение, с которым мы будем сталкиваться:

• Текстовый редактор, в котором нам удобно будет разрабатывать. Не столько кода обычно пишется, сколько после читается, перечитывается и исправляется при тестировании и отладке. Поэтому удобство пользования стоит выше всего;
• Компилятор и компоновщик - основные инструменты сборки программы. Мы в курсе работаем с компилируемым Си (а бывают не только такие), поэтому для разработки нам необхомима утилита для проверки “исправности” кода и его перевода в исполняемые файлы;
• Дополнительные библиотеки, с которыми мы компилируем программу;
• Сборочные библиотеки. Для сборки недостаточно иметь саму библиотеку, нужно иметь её сборочную версию, чтобы с ней компоновать программу;
• Система Контроля Версий. В процессе разработки часто необходимо обращаться к предыдущим версиям программы, добавлять новый функционал к точно рабочим копиям, проверять разные способы реализации и т.д. Более того, ресурс хранения должен быть доступен нескольким участникам проекта единовременно, чтобы можно было вести совместную разработку. Для всего этого и нужна СКВ. В нашем курсе мы будем работать с системой git;
• Непрограммные компоненты. Кроме написания самого приложения нам нужно обеспечить его ресурсами и информацией, которыми оно будет пользоваться. Переводы, документация и другие данные, не связанные с программой непосредственно, входят именно в этот пункт;
• Инструменты автоматической сборки сложного проекта. Сборка - это этап объединения множества исходных файлов в единое работающее звено, и ручками делать это в большой разработке если не невозможной, то, как минимум, неблагодарное дело;
• Информационные инструменты для исследования. Невозможно знать всё. Поэтому в процесс разработки входит обязательный раздел поиска и сравнения различных ресурсов и используемых утилит;
• Отладчик. Невозможно с первого раза написать большой проект, не совершив где-нибудь ошибку. А даже если написано без ошибок, всегда понадобится добавить в старый код новый функционал, который вполне может конфликтовать с предыдущим. Для того, чтобы конкретизировать проблемные точки и исправлять их, существуют программы по отладке кода.

Получается довольно мощный набор инструментов, обычно отсутствующий в “коробке” Linux-системы.

Разделим весь этот список на три эшелона:

1. Инструментальные зависимости - ПО, в котором нам удобно разрабатывать (Всё, что нужно для редактирования, но не для сборки);
2. Сборочные зависимости - Инструменты по преобразованию исходников в исполняемые файлы;
3. Эксплуатационные зависимости - Узкий класс программ, необходимых для непосредственной работы программы

Из такого разделения понятно, что все эти три куска вообще могут быть на разных устройствах. Редактируем код в одном месте, затем загружаем его в сборочную систему, после вообще на третьих устройствах проверяем работоспособность проекта. Однако мы будем использовать old-school-ный вариант, где у нас будет одно общее сборочное окружение.

Поговорим немножко про git

Книжка про него

Git относится к Системам Контроля Версий и обеспечивает три основных класса действий с данными:

• Их непосредственное хранение;
• Версионирование - возможность обращаться к предыдущим состояниям данных, смотреть конкретные изменения, создавать отдельные ветви с различными изменениями этих данных;
• (Самое важное) Совместную разработку на основе этих данных.

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

Кратко, как работать с git

Для того, чтобы понять, как работает git, мы рекомендуем пройти курс “Совместная разработка приложений на Python”. Там подробно описываются и прорабатываются основные аспекты работы с системой контроля версий: ветвления разработки, патчи, конфликты итд. У нас git - это инструмент для сохранения классной и домашней работы, поэтому в смысл работы мы вникать не будем, но основные команды, и что они делают, разберём.

Давайте создадим и загрузим в созданный вами git-репозиторий новый файл

Создадим папку, соответствующую нашей лекции, перейдём в неё

user@localhost:~> cd LinuxAppDev/
user@localhost:~/LinuxAppDev> mkdir 00_BuildEnv
user@localhost:~/LinuxAppDev> cd 00_BuildEnv/

Сымитируем нашу домашку просто любым файлом, например, календариком

user@localhost:~/LinuxAppDev/00_BuildEnv> cal > cal
user@localhost:~/LinuxAppDev/00_BuildEnv> cat cal
   September 2024   
Su Mo Tu We Th Fr Sa
 1  2  3  4  5  6  7
 8  9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30               
                    

Посмотрим, как добавление (да и, вообще, любое изменение) нашего локального хранилища определяется системой контроля версий

user@localhost:~/LinuxAppDev/00_BuildEnv> cd ..
user@localhost:~/LinuxAppDev> git status
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	00_BuildEnv/

nothing added to commit but untracked files present (use "git add" to track)

Git заметил, что у нас есть изменённые данные (новый файл в новой директории), которые ещё не запомнены нами даже локально (сохранить файл мы сохранили, но в git, даже в локальное хранилище, об изменениях не сообщили).

Добавим наши изменения с помощью git add:

user@localhost:~/LinuxAppDev> git add 00_BuildEnv/
user@localhost:~/LinuxAppDev> git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	new file:   00_BuildEnv/cal

Теперь наши изменения добавлены, но надо оформить как бы полноценное сообщение о наших изменениях - коммит.

Оформляем его с помощью git commit, добавляя комментарий о проделанных действиях (комментарий пишется в кавычках после флага -m)

user@localhost:~/LinuxAppDev> git commit -m "Add cal"
[master 3156780] Add cal
 1 file changed, 8 insertions(+)
 create mode 100644 00_BuildEnv/cal

user@localhost:~/LinuxAppDev> git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

Git от нас больше ничего не требует, все изменения у него записаны и внесены в реестр наряду с другими.

Однако эти изменения сделаны лишь локально. Чтобы выгрузить их на удалённый сервер, где они отобразятся на сайте и откуда их можно будет прислать на другое устройство, нужно явно отправить изменения командой git push

user@localhost:~/LinuxAppDev> git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 438 bytes | 438.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To github.com:UsamG1t/LinuxAppDev.git
   e4d2ae9..3156780  master -> master
user@localhost:~/LinuxAppDev> 

Отлично! Как отправлять домашку, разобрались, теперь вперёд изучать материал!