Лекция 8. Инструментарии

В воображаемом пути изготовления продукта мы уже дошли до всяких модульных тестирований и самопроверки, воркфлоу по выпуску — в общем, большой проект. Маловероятно, что мы его написали с нуля на языке цэ. Линукс как конструктор от юникса как конструктора отличается — современное состояние свободно лицензируемого софта таково, что мало мальски актуальная инструментальная задача имеет существенно более одного решения. Вам может показаться, что библиотеки делают немножко не то, но ситуация, когда есть тех задание о разумных вещах и нет инструментов почти не случается. Гораздо чаще заказчик считает, что у него феерически новая задача, а потом оказывается что для её решения надо прикрутить обычную нейронную сетку к обычным датчикам, обычной базе и обычному веб интерфейсу. Все эти задачи имеют очень много готовых решений — десятки и тысячи. Встает проблема не разработки, а поиска и выбора подходящего инструментария. Это сильно отличается от проблемы реализации алгоритмов, встававшей 30 лет назад. Кстати, видимо этим и объясняется качество научного кода — люди, которые пишут на C в помощь своей теореме, они считают, что пишут это впервые. В хорошем исследовании так и будет, процентов для 10 кода. Но многие ученые пишут с нуля всё.

Выбор инструментария

За последние лет 10 проблема выбора инструментария изменилась от игры по интересам, когда ты заходил на freashmeat и там перечислялись все новости про свободное ПО, эта задача резко усугубилась и становится knowledge deeping.

Помимо всем известного sourceforge есть googlecode, есть github и gitorius, bitbucket, savanna. Различные среды программирования имеют свой собственный портал — Python, Ruby, Perl.

Есть три класса

• хостинги проектов, тип sourceforge
• хостинги с поддержкой работы с исходным кодом, типа github
• целевые хостинги, например по языкам программирования

Для выбора можно воспользоваться ***меркой, например, ohloh.

Есть две вредные тенденции, побуждающие разрабатывать свободный инструментарий:

• NIH. То, что не написали мы с братом, это по определению отстой, и пробовали мы читать этот код — точно отстой. В корпоративном секторе это не сильно отличается. У самого отношения к свободному коду как к потенциально опасному есть рациональное зерно, но его доля в мотивации создавать свои велосипеды очень мала.
• люди, которые тренируются. Любая инженерная деятельность, связанная с разработкой, провоцирует изобретение велосипедов для повышения скилла. Если залезть на тот же самый sourceforge, вы увидите, что там много таких заброшенных проектов.

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

Признаки годного проекта

• размер и активность сообщества — закон больших чисел. Главный показатель удобства работы с инструментом — не качество и количество кода, а качество сообщества. Чем больше людей, тем больше вероятность найти единомышленников со схожими задачами.
• что у них с release engineering. Насколько люди заинтересованы в том, чтоб их кодом кто-то пользовался. Готовятся ли анонсы, есть ли багфиксы. Иногда бывает так, что команда профессионалов пилит какой-то продукт и на всех плевать хотела, пушат в свой гит или свн, тэгов не ставят, и т. д. Это не самые удобные ребята для взаимодействия. По русски пункт будет — работа с выпусками. На сегодняшний день это довольно частая тенденция. Например, у людей был сайт, они на нем выкладывали версии продукта. Потом открыли для себя гитхаб, забили на сайт, релизы делать перестали, про теги в гите не знают. Был хороший сайт, стало никакого. И надо выяснять, с какого commit id надо собирать, чтобы получился годный код.
• возраст. Например, на сурсфорже много проектов, которые прожили год или полтора. Дипломные работы, что ли?
• только после этого идет качество кода. Почему это не первая причина?
  1. О вкусах не спорят
  2. Инструмент надо выбирать так, чтобы ваше вмешательство в нем было минимально. В таком случае качество кода для вас не слишком важно. Если вы не видите совсем уж феерию.
  3. В старых проектах код ужасный — хакеры писали 30 лет назад. Они все тогда только открывали, но были гениями. Это ужасный код с костылями, но за 30 лет все ошибки оттуда выковыряли и замазали.
  4. Не забудьте про лицензию. В нашем мире лицензионная чистота дело очень важное.
  5. Весьма важен язык программирования. Вряд ли вы умеете программировать на всём.

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

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

Опишем цели создания комбайнов

1. сделать набор инструментов кроссплатформенным. Довольно большое число инструментов все таки предназначены для оперделенной платформы, если это не какие-то математические библиотеки. А хотелось бы не просто кросс платформенность исходного кода обеспечить но и кроссплатформенность процесса разработки, что важнее. Пример — нужно написать программу одновременно под вин-лин-мак. Вы можете либо писать три программы и одинаково их называть. Общим будет только платформонезависимая логика, а всю привязку делат средствами ос. Этим вы умножите работу почти в три раза и получите необходимость иметь три набора разработчиков. Либо вы используете кроссплатформеные библиотеки и получаете проблему, что оно по разному собирается на разных платформах. Если вы хотите унифицировать этот процесс, то надо искать не только набор библиотек решающий задачу, но и набор инструментов решающий все подзадачи, возникаюшие в процессе разработки.
2. Переписать стандарт. В ос с которой вы работаете есть некий программный стандарт на то, как можно с ней обшаться. Стандарты разные для разных ос, зачастую старые и не все охватывают. Например, позикс. Первый способ — писать новый стандарт. За 15 лет как раз успеете. Второй способ — писать инструментарий, вытесняющий стандарт дефакто. Идея — дать новый подход к задачам, которые нэффективно решаются стандартными инструментами.
3. Информационное пространство. Вам надо смотреть за размножением разноцветных ежиков и публиковать результаты. Подзадачи — работа с датчиками, складывание результатов в базу, уход за ежиками и логика, публикация. Решается несколькими инструментами. А вот если у вас офисное приложение, которое работает с диском, изображениями документами, или программа настолько сложна, что требует объектного планирования, в общем когда задача слишком сложна и распадается на подзадачи из разных областей, то решать её большим количество разношерстных библиотек чревато — теряется унификация и связность информационного пространства. Свойства из этого информационного пространства.
4. общая идеология разработки. Хорошо тем, что те, кто будет в команде будут понимать, как будет выглядеть кусок кода, написанный другим человеком.
5. Основная цель разработчика инструментария — разработать инструментарий. Они хотят потом на нем программировать. Основная идея сделать его не только мощным, но и удобным к освоению — привлечение сообщества. Если мы имеемдело со свободной разработкой, то немаловажным подспорьем будет привлечение в него программистов, которые будут помогать в разработке. Или люди говорят — мы полгода будем писать инструментарий, а потом за год напишем вам на нем проект.

Давайте начнём снизу. Пример обшего инструментария для программирования на C

• libc. С точки зрения программиста это обёртка над системными функциями. Правильно завернутые системные вызовы во вкусной обертке. Она является инструментарием в смысле 40-летней давности. Аналогичное API есть в любом языке программирования.
• шаг вверх, всё ещё на языке C. glibc. Содержит реализацию разных типов данных, строковые функции, случайные числа, регулярные выражения. Пауза. Зачем делать собственные строкоые операции? Надежность и кроссплатформенность. Недостаток строк в Си — это сишные строки, последовательности байт с нулем в конце, и вообще массивы. А хотелось строки переменной длины, и уметь из делить, тасовать итп. Отдельно — работа с интернационализацией(адоптация к другим языкам) — классический пример расширения стандарта. Отдельные примитивы для работы с памятью. Зачем? Кто отменил free и malloc? Рефкаунтеры. Поддержка атомарных операций. Процессы, нити, таймеры — чистый замах на кроссплатформенность. Встроенные лексический и синтаксический анализатор. Не хочется писать читалку ини-файла. Переписывается ввод-вывод. Если взять существуюший input output в ОС — то окажется, что они очень сушественно отличаются. А данные передавать надо, да ещё и кроссплатформенно. Далее — отладка и диагностика. Накопление и вывод ошибок, процедуры. Когда вы пишете много, без этого не обойтись. ЗАпускаете приложение гткщное, оно начинает сыпать ассертами, но продолжает работать.
• поверх glib есть ещё gobject. Там есть и классы, и контейнеры, и метаданные. Относительно полноценное ооп, с учетом того, что оно происходит на си и содержит синтаксический шум. Нужно чтобы писать развесистые ооп программы, например, интерфейсные.

Представляется естественным писать на яп, имеющим большую историю промышленной разработки. На ооп языке удобней писать реально большие объекты. В частности, есть такой здоровенный инструментарий, под названием

• boost. Это очередной большой комбайн, на этот раз для C++. Что умеет? Алгоритмы. Хитрые заранее заданные. Сразу видно, что библиотека уровнем выше. Туда же относится подсистема работы с графами. Поддержка различных компиляторов. Довольно важно, когда вы имеете дело с каким-нибудь вижуал це. Модульное тестирование есть и в глибе, и в бусте. Функциональное программирование, функторы. Переписана работа с памятью, ввод-вывод, обработка строк, синтаксический и лексический анализатор, свои структуры данных. Переписаны указатели — есть отдельный блок — умные указатели, которые обеспечивают безопасную работу с памятью в C++.
• Qt.
  • базвый модуль — переписаны основные функции, введено понятие приложения.
  • виджетсет — самая известная часть Qt.

  • QtNetwork. Работа с сетью, всякие прикладные протоколы, сервисы которые слушаают порты из коробки, бац объект, шлеп объект, оно работает.

  • OpenGL, работа с графикой
  • SQL, интерфейс к SQL’ным базам данных, разным.
  • поддержка разных форматов — svg, xml
  • test — библиотека для тестирования.
  • некоторое количество привязанных к подзадачам модулей. можете броузер встроить. Организация просмотра документации, проигрывание мультимедии, полнотекстовый поиск, активикс элементы, поддержка скриптового языка встроенная, декларативные языки можно самому создавать, чтобы интерфейс описывать и всякое такое. Всякие странно себя ведущие виджеты, которые не умеет ОС (например, полупрозрачная лягушка).

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

Главная фишка кутэ — это вообще не C++. У кутэ объектов динамическая типизация и много всего ещё. Вы пишите программу якобы на с++, а потом натравливаете специальные компилятор, который учитывает мета-штуки. С точки зрения профессионала которому надо быстро закодить специальную функциональность — очень круто.

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

Ешё один пункт Java, .NET — у них всё в себе. Помимо языка программирования такие штуки содержат ещё и все остальное. Когда пишете на Java — ничего не надо знать про ОС, да и цикл разработки полностью поддержан. То же самое относится к любым современным скриптовым языкам общего назначения, особо это очевидно для питтона. В базовой поставке это несколько сотен модулей. Плюс привязки к библиотекам pyqt, pygtk.

Последняя часть — помимо комбайнов, существуют дисциплины, среды программирования. Ruby-on-rails. "Философии программирования в вики". Можно регламенировать всё, что угодно, вплоть до ограничений на внешний вид мозга программиста. Или, например, есть громадная область — дизайн паттерны — давайте программировать только готовыми паттернами. Есть целая дисциплина программирования, которая повелевает программировать только паттернами, и тогда не бывает коредампов.