Лекция 11. Информационное-технологическое обеспечение разработки

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

// О! Я нашёл нормальный, вкусный мел! Ну ладно...

До сей поры, когда мы разговаривали на разные темы, связанные с разработкой программ под Линукс, мы изучали инструменты, которые непосредственно влияют на эту разработку, но не очень глубоко касались информационной составляющей: всяких сайтов и т. п.

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

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

Чего мне не хотелось бы касаться в этой лекции:

Анекдот: Я не поехал читать лекции в Моторолу по Embedded Linux. 3 месяца подряд они не могли понять, что им не подходит график. И все эти 3-4 месяца, пока они искали тренера по Линуксу, у них не было ни одного человека, который понимает, что такое Линукс. И при этом они выпустили несколько телефонов на Линуксе.

Это я привёл пример неправильной организации труда.

В Windows поддержка разработки со стороны ОС всегда была никакая, а понятие комьюнити — оно совсем другое, когда речь идёт о закрытом софте.

Информационное пространство

О чём вам может потребоваться информация, когда вы занимаетесь программированием?

  1. ЯП. Ну разумеется о языке программирования.

  2. Инструментарии. Это громадный набор всяких инструментов и немыслимо программировать на том же Qt без годной справочной системы.

  3. ОС. Даже если вы делаете свой проект совсем в отрыве от ОС, что-нибудь кроссплатформенное, вам как минимум потребуется информация об ОС, чтобы не запрогать что-нибудь _не_кроссплатформенное.

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

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

Где искать?

И вот только если ничего не помогает, вообще-то говоря, не плохо бы спросить. У кого спросить?

В первый раз за сегодня я ссылаюсь на текст, прекрасно написанный Саймоном Г. Тетхемом. В чём идея? Если вы задаёте свой вопрос, имейте в виду, для чего вы это делаете. Есть две такие подспудные цели, которые есть у человека, который задаёт вопрос:

  1. Человек хочет излить свои эмоции. Никогда так не делайте. Никому от этого не будет лучше. Ни вам, ни разработчикам.
  2. Решить проблему здесь и сейчас любыми средствами. Привлечь народ. Так тоже не делайте. Возможно и найдутся люди, которые напишут вам код, но правильная цель состоит в том, чтобы научиться решать такие проблемы самому.

Что должно быть в правильно заданном вопросе?

Необходимая, но не полная информация. Все вещи, участвующие в возникновении ошибки должны быть указаны. Но при этом не надо сообщать всё, что вы видели и чувствовали от своего компьютера сегодня. И довольно чётко должно быть сформулировано, что вы хотите.

Всем советую почитать этот документ. Речь идёт о том, что ваш вопрос могут решить в списках рассылки и других интерактивных ресурсах, если вы его достаточно правильно зададите.

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

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

Замечание первое: очень часто поиск по гуглу, поиск по ошибке или по основным ключевым словам, приземляются в места, содержащие исходный код или места, где ведётся разработка. Это может означать то, что либо с вашей проблемой никто не сталкивался, либо то, что этот кусок кода на самом деле не связан с вашей ошибкой. Это не хорошо или плохо. Это просто такой кивок в сторону.

Второе. Как сказал Дима Левин: «На Си уже никто не пишет, только форкают готовое». Но факт остаётся фактом, когда вы начинаете разработку, вы используете уже готовые куски кода и дорабатываете их. Особенно это относится к ситуации, когда вы не только дорабатываете код, но также и обнаружили в вашем инструменте какие-то ошибки или хотите от него новой функциональности — то есть каким-то образом включились в разработку этого инструмента.

При условии отсутствия нехватки времени, это довольно хорошая ситуация, если вы сами можете взять и поправить эту ужасную багу.

Есть два решения:

Опенсорс в стиле 90-х годов прошлого века представляет собой следующую картину. Люди просто складывают все необходимые инструменты в одно место и начинают всё там переправлять, включая gcc. Особенно этим славятся американские разработчики, работающие на военку.

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

Здесь совмещаются две ваших роли: роль ваша как разработчика собственного проекта, так и роль ваша как разработчика того софта, который вы используете. Большие и серьёзные люди как правило являются участниками очень большого числа проектов. Такие разработчики являются участниками как минимум нескольких сообществ, участвуют в разработке своего дистрибутива и т. д.

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

Ещё очень полезно брать и читать чужой код. Особенно тем, кого от этого не тошнит в духе «Ну что это такое? Как это можно читать? Этот человек писал ногами».

Отдельным пунктом нашей программы является то, что я бы назвал «велосипедным паком». Я уже говорил о том, что большинству профессиональных программистов приходится изготавливать за свою жизнь кучу велосипедов. В этом есть смысл, потому что программирование таких велосипедов на новом инструментарии позволяет хорошо разобраться с инструментарием и при этом никому от этого не будет больно. Попробуйте разобраться с Qt в процессе реальной активной разработки!

Разработка проекта

Давайте мысленно пробежимся по тем штукам, о которых мы уже говорили на лекциях. И подумаем, какое инструментальное обеспечение нам может понадобиться.

Вторая опция состоит в том, чтобы развёртывать собственное хранилище кода.

Когда вас становится больше троих, внезапно выясняется, что у каждого должно быть своё хранилище кода и возможность работать с общим репозиторием. У вас должна быть некоторая услуга предоставления хранилища кода. Типичный пример такого инструментария — это gitalite. На нём ведётся разработка ядра. У gitalite'а есть ещё одна удобная особенность — он управляется гитом. Вот тот же гит, только администраторский. Помимо gitalite есть ещё gitlab — это такое поделие, представляющее собой gitalite + морда на RubyOnRails. Это уже модно, это всякие фишечки и плюшечки.

Это всего лишь примеры. На самом деле любой приличный CVS и DCVS имеют серверную составляющую и для них написано некоторое количество обвязок.

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

Наконец два последних пункта:

  1. Мы ничего не поговорили про управление разработкой проекта. Инструментов, которые управляют разработкой, бесконечно много. Это называется project management. Во-вторых, это дело уже не совсем программиста, а скорее менеджера. В-третьих, в зависимости от особенностей процесса разработки может быть выбран тот или иной инструмент. А в-четвёртых, я теряюсь..

  2. Комбайны. Они существуют разные. trac — это такая штука, в которой есть и вики, и система отслеживания ошибок, и система отслеживания процесса разработки, и ручки к VCS’у. Это такой комбайн, достаточно простой, который позволяет быстро развернуть процесс разработки, как с информационной поддержкой, так и с инструментальной. Ещё один пример: roundap. Другая группа комбайнов, которая вообще совмещает в себе всё и сразу. В них есть составляющая для работы с кодом, составляющая для работы с пользоваталями и т. д. Я знаком только с одним гнездом, свободным в этом плане. Это redmine и его форк, который называется chilyproject. Это здоровенные комбайны, обучение эффективному использованию которых — отдельная серьёзная

    задача. Она написана на RubyOnRails. Ещё она каким-то образом привязана к мозгам менеджеров. Ещё менеджеры любят Atlassian, но она несвободная.

LecturesCMC/LinuxApplicationDevelopment2012/Conspects/11 (последним исправлял пользователь Nyarcel 2013-01-25 07:48:35)