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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LecturesCMC/LinuxApplicationDevelopment2012/Conspects/08 (last edited 2013-01-25 06:22:14 by Nyarcel)