Что такое проект в программировании

Понятие проекта

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

Цель проекта определяет задачи, решаемые в результате реализации проекта, содержание — что является результатом проекта. Управление проектом определяет, как будет достигнута цель и создан необходимый результат. Управление проектом есть постоянная деятельность, осуществляемая на всем его протяжении по определенной методике. Достижение результата проекта и достижение его цели — разные вещи. Например, результат проекта — разработка информационной системы, цель — автоматизация определенной деятельности. Можно создать информационную систему, не обладающую нужной функциональностью, и цель проекта достигнута не будет, в отличие от результата. Успешным проект будет лишь тогда, когда результат соответствует заданному содержанию и его целям.

Часто связанные проекты объединяются в проектные программы. Если же проекты характеризуются единым или пересекающимся набором ресурсов и единым центром управления, то они объединяются в портфели проектов.

Масштаб проекта оценивается по количеству людей, в нем задействованных, и по конечной стоимости. Любой проект, как правило, имеет руководителя (проектного менеджера), который несет ответственность за проект в целом. Успешный проект должен уложиться в рамки так называемого тройственного ограничения (рис. 1.1).

Рис. 1.1. «Тройственное ограничение»

Важны следующие аспекты управления проектами:

• • ограничения являются следствием приоритетов, расставленных заказчиком с учетом имеющихся ресурсов;
• • приоритеты заказчика и исполнителя в общем случае могут не совпадать (противоречить);
• • анализ компромиссов определяет баланс приоритетов сторон, заинтересованных в проекте;
• • ограничения являются неотъемлемой частью проекта;
• • ограничения порождают риски;
• • ограничения рассматриваются в контексте уровня детализации проекта.

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

В области управления проектами существует ряд нормативов и рекомендаций, среди которых можно выделить результаты деятельности следующих организаций:

• • PMI — Project Management Institute, Inc. — американский Институт управления проектами;
• • IPMA — International Project Management Association — Международная ассоциация управления проектами;
• • АРМ — Association of Project Management — одна из крупнейших независимых профессиональных ассоциаций по проектному менеджменту в Европе;
• • Ассоциация по управлению проектами СОВНЕТ.

Проект с позиций программной инженерии (IT-проект) — это совокупность действий, необходимая для создания артефактов программного продукта. Проект включает в себя взаимодействие с заказчиком, написание документации, проектирование, кодирование и тестирование. На рис. 1.2 представлены перечисленные параметры проекта в виде лепестковой диаграммы. Следует отметить, что в отличие от «тройственного ограничения» IT-проект характеризуется еще одним ограничением — качеством.

Рис. 1.2. Пример лепестковой диаграммы параметров проекта

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

Верификация и валидация

Управление кон ф и гу ра ция м и

SWP (План экспертизы проекта)

SQAP (План контроля качества программного обеспечения)

SCMP (План управления конфигурациями программного обеспечения)

SPMP (План управления программным проектом)

Ориентированная на заказчика

SRS (Спецификация требований к программному обеспечению)

Ориентированная на разработчика

по тестированию программного

Рис. 1.3. Документация проекта в соответствии с требованиями IEEE

Краткая характеристика каждого документа приведена ниже.

SWP (Software Verification and Validation Plan) — план экспертизы программного обеспечения, определяющий, каким образом и в какой последовательности должны проверяться стадии проекта и сам продукт на соответствие поставленным требованиям (верификация — проверка правильности сборки приложения; валидация — проверка на соответствие требованиям).

SQAP (Software Quality Assurance Plan) — план контроля качества программного обеспечения, определяющий, каким образом проект должен достигнуть соответствия установленному уровню качества.

SCMP (Software Configuration Management Plan) — план управления конфигурациями программного обеспечения, который определяет, как и где должны храниться документы, программный код и их версии, устанавливает их взаимное соответствие.

SPMP (Software Project Management Plan) — план управления программным проектом, который определяет, каким образом следует управлять проектом.

SRS (Software Requirements Plan) — спецификация требований к программному обеспечению, которая определяет требования к приложению, утверждается совместно заказчиком и разработчиком и служит отправной точкой для реализации функциональности программного продукта.

SDD (Software Design Document) — проектная документация программного обеспечения, которая представляет архитектуру и детали проектирования приложения с использованием диаграмм.

STD (Software Test Documentation) — документация по тестированию программного обеспечения, в которой указывается, каким образом должно проводиться тестирование приложения и его компонентов.

При реализации IT-проекта важно следующее:

• 1) грамотное управление персоналом: адекватный подбор участников проекта с обозначением для каждого его должностных обязанностей, указанием круга взаимодействия с коллегами и зоны ответственности;
• 2) умение управлять рисками: все риски должны быть как можно раньше идентифицированы; устранимые риски необходимо предотвратить, например модифицируя требования, а неустранимые — преодолеть, применяя определенные технологии программирования и/или проектирования.

Что такое пет-проект и где искать идеи: опыт студентов Хекслета

Пет-проекты — еще одна возможность для джуна получить реальный опыт работы. Это собственные проекты, которые иногда становятся глобальными сервисами (например, Gmail и AdSense когда-то были пет-проектами), но чаще помогают в процессе саморазвития и закреплении изученного материала. Придумать идею для собственного проекта бывает не просто. Для вдохновения рассказываем о пет-проектах наших студентов: от аналога Trello до программы для интерактивного дисплея на клавиатуре.

Что такое пет-проекты

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

Пет-проекты полезны и для студентов, которые только изучают программирование, и для разработчиков с опытом.

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

Для студентов

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

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

Для разработчиков

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

В некоторых крупных компаниях существует практика поощрения собственных проектов сотрудников. Например, введенное в 2004 году Google «Правило 20%» позволяло разработчикам тратить пятую часть рабочего времени на пет-проекты. Так появились Gmail и AdSence. Стоит отметить, что в случае с Google такая политика предполагала, что все разработки становятся интеллектуальной собственностью компании.

Где взять идеи для проекта

Универсальный ответ на этот вопрос — попробовать автоматизировать процессы или решить проблемы, с которыми приходится сталкиваться каждый день. Однако на практике поиск идей может оказаться не самой простой задачей.

Мы попросили студентов Хекслета рассказать о своих пет-проектах: вероятно, эти кейсы помогут вам придумать идею для собственного проекта.

Рустем Тарасевич, JS/TS-разработчик

В моем GitHub репозитории около 10 пет-проектов. Первые три — помидорный таймер, сервис для составления списков задач и приложение погоды — своего рода Hello, World в портфолио каждого начинающего фронтенд-разработчика. Не буду останавливаться на них подробно, а расскажу про более сложные проекты.

Чат для комьюнити. Упрощенный аналог чата комьюнити Хекслета в Slack, который я сделал в качестве четвертого, финального учебного проекта. Приложение представляет собой чат с входом по регистрации и отдельными комнатами для обсуждений. Сообщения в нем можно редактировать и удалять.

На проект я потратил больше двух недель — за это время успел разобраться в вебсокетах, интернационализации, кастомных хуках, Redux Tool Kit и другими технологиями.

Трекер задач. Идею для этого проекта я взял из книги Fullstack React with Typescript. На русский язык она не переведена, так что во время чтения подтянул английский до уровня B1\B2.

Проект похож на доску Trello: это канбан-доска с возможностью перетаскивать задачи курсором (Drag and drop). Для реализации этого функционала я использовал библиотеку React-DND, а стэйт-менеджмент написал с помощью Redux Tool Kit, самостоятельно типизировал логику с помощью документации. Это потребовалась, поскольку в оригинале предполагалось реализовать приложение на чистом Redux.

В ходе проекта я также изучил библиотеку styled-components , которая позволяет писать стили компонентов прямо в tsx-файле.

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

Читайте также: Как сохранять фокус на протяжении всего обучения: советы от Хекслета

Иван Иванов, разработчик на С++

Свой первый проект я сделал около семи лет назад, когда самостоятельно учил C++. Тогда я купил игровую клавиатуру Logitech с черно-белым экраном и столкнулся с тем, что для нее доступно очень мало программ. Я решил сделать свою программу, которая будет выводить на экран сообщения из Skype (на тот момент главной платформы для общения геймеров, по аналогии с Discord) и позволит отвечать на них, не сворачивая окно с игрой.

Рядом с экраном находилось четыре кнопки: первую я использовал для того, чтобы открыть окно с сообщениями, вторую — для автопрокрутки. Третья кнопка перехватывала ввод с клавиатуры и перенаправляла его на экран клавиатуры, а четвертая — отправляла сообщение.

Для работы над проектом я изучил API Windows, которое использовал Skype, и API клавиатуры — это была библиотека на языке C, с которым я раньше не сталкивался. Нужно было разобраться, как подключать C-библиотеки и использовать их в программах, написанных на C++, и как работать с пиксельной черно-белой пиксельной графикой.

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

Константин Мамонтов, PHP-разработчик

Мой пет-проект — интернет-магазин, точнее, интернет-склад. Он не решал никакую конкретную проблему и всегда был некоммерческим. Его целью было закрепление знаний и поиск подводных камней при разработке подобных продуктов.

Основа проекта — база данных, написанная на моем основном языке PHP. В процессе работы над складом я изучил JavaScript для создания пользовательского интерфейса и добавил формы приема заказа и регистрации через Bootstrap.

Этот опыт пригодился мне на собеседовании, которое благодаря курсам и проекту я прошел почти моментально, и во время выполнения тестового задания. В результате я нашел первую работу PHP-программистом на Laravel.

Бесплатные курсы по программированию в Хекслете

• Освойте азы современных языков программирования
• Изучите работу с Git и командной строкой
• Выберите себе профессию или улучшите навыки

Учебники. Программирование для начинающих.

Programm.ws — это сайт, на котором вы можете почитать литературу по языкам программирования , а так-же посмотреть примеры работающих программ на С++, ассемблере, паскале и много другого..

Программирование — в обычном понимании, это процесс создания компьютерных программ.
В узком смысле (так называемое кодирование) под программированием понимается написание инструкций — программ — на конкретном языке программирования (часто по уже имеющемуся алгоритму — плану, методу решения поставленной задачи). Соответственно, люди, которые этим занимаются, называются программистами (на профессиональном жаргоне — кодерами), а те, кто разрабатывает алгоритмы — алгоритмистами, специалистами предметной области, математиками.
В более широком смысле под программированием понимают весь спектр деятельности, связанный с созданием и поддержанием в рабочем состоянии программ — программного обеспечения ЭВМ. Более точен современный термин — «программная инженерия» (также иначе «инженерия ПО»). Сюда входят анализ и постановка задачи, проектирование программы, построение алгоритмов, разработка структур данных, написание текстов программ, отладка и тестирование программы (испытания программы), документирование, настройка (конфигурирование), доработка и сопровождение.

Delphi для начинающих

Введение

Структура проекта

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

Главный модуль представляет собой файл с расширением dpr. Для того чтобы увидеть текст главного модуля приложения, нужно из меню Project выбрать команду View Source.

В листинге ВЗ приведен текст главного модуля программы вычисления скорости бега.

Листинг ВЗ. Главный модуль приложения Скорость бега program vrun;

Forms, vrun1 in ‘vrunl.pas’ ;

Начинается главный модуль словом program, за которым следует имя программы, совпадающее с именем проекта. Имя проекта задается в момент сохранения проекта, и оно определяет имя создаваемого компилятором исполняемого файла программы. Далее за словом uses следуют имена используемых модулей: библиотечного модуля Forms и модуля формы vrunl.pas.

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

Файл ресурсов не «является текстовым файлом, поэтому просмотреть его с помощью редактора текста нельзя. Для работы с файлами ресурсов используют специальные программы, например, Resource Workshop. Можно также применять входящую в состав Delphi утилиту Image Editor, доступ к которой можно получить выбором из меню Tools команды Image Editor.

Исполняемая часть главного модуля находится между инструкциями begin и end. Инструкции исполняемой части обеспечивают инициализацию приложения и вывод на экран стартового окна.

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

В листинге В4 приведен текст модуля программы вычисления скорости бега.

Листинг В4. Модуль программы Скорость бега

unit vrun1;

Windows, Messages, SysUtils, Variants, Classes,

Graphics, Controls, Forms, Dialogs, StdCtrls;

TForm1 = class(TForm) Edit1: TEdit;

Edit2: TEdit; Label1: TLabel;

Label2: TLabel; Label3: TLabel;

procedure ButtonlClick(Sender: TObject);

procedure Button2Click(Sender: TObject);

implementation

// нажатие кнопки Вычислить

procedure TForm1.ButtonlClick'(Sender: TObject);

dist : integer; // дистанция, метров

t: real; // время как дробное число

min : integer; // время, минуты

sek : integer; // время, секунды

// получить исходные данные из полей ввода

dist := StrToInt(Edit1.Text); t := StrToFloat(Edit2.Text);

// предварительные преобразования

min := Trunc(t); // кол-во минут — это целая часть числа t

sek := Trunc(t*100) mod 100; // кол-во секунд — это дробная часть

v := (dist/1000) / ((min*60 + sek)/3600);

// вывод результата

label4.Caption := ‘Дистанция: ‘+ Edit1.Text + ‘ м’ + #13

+ ‘Время: ‘ + IntToStr(min) + ‘ мин ‘

+ IntToStr(sek) + ‘ сек ‘ + #13 +

‘Скорость: ‘ + FloatToStrF(v,ffFixed,4,2) + км/час’;

// нажатие кнопки Завершить

procedure TForm1.Button2Click(Sender: TObject)

Начинается модуль словом unit, за которым следует имя модуля. Именно это имя упоминается в списке используемых модулей в инструкции uses главного модуля приложения, текст которого приведен в листинге ВЗ.

Модуль состоит из следующих разделов:

• интерфейса;
• реализации;
• инициализации.

Раздел интерфейса (начинается словом interface) сообщает компилятору, какая часть модуля является доступной для других модулей программы. В этом разделе перечислены (после слова uses) библиотечные модули, используемые данным модулем. Также здесь находится сформированное Delphi описание формы, которое следует за словом type.
Раздел реализации открывается словом implementation и содержит объявления локальных переменных, процедур и функций, поддерживающих работу формы.
Начинается раздел реализации директивой , указывающей компилятору, что в процессе генерации выполняемого файла надо использовать описание формы. Описание формы находится в файле с расширением dfm, имя которого совпадает с именем модуля. Файл описания формы генерируется средой Delphi на основе внешнего вида формы.
За директивой ($R *.DFM> следуют процедуры обработки событий для формы и ее компонентов. Сюда же программист может поместить другие процедуры и функции.
Раздел инициализации позволяет выполнить инициализацию переменных модуля. Инструкции раздела инициализации располагаются после раздела реализации (описания всех процедур и функций) между begin и end. Если раздел инициализации не содержит инструкций (как в приведенном примере), то слово begin не указывается.
Следует отметить, что значительное количество инструкций модуля формирует Delphi. Например, Delphi, анализируя действия программиста по созданию формы, генерирует описание класса формы (после слова type). В приведенном примере инструкции, набранные программистом, выделены фоном. Очевидно, что Delphi выполнила значительную часть работы по составлению текста программы.

Философия программирования 6 — Продукт и Проект

Разница между продуктом и проектом в том, что при разработке продукта есть план, а при разработке проекта есть исследования. Если у вас есть какая-то не решённая проблема, скажем вы ещё не решили какую базу данных использовать в своём проекте, то вам понадобится этот вопрос изучать, то есть исследовать. Это называется technology research. Исследование, это вовсе не обязательно, что-то совершенно новое в мировом масштабе, если вы строите мост, то вам надо исследовать грунт в данном конкретном месте, и пока этот грунт не исследован, мост, как продукт, ещё не существует, пока что это — проект. Ещё не известно, какой грунт, а значит не известно из чего делать мост, как его укреплять, невозможно посчитать бюджет и распланировать график работ.

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

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

При проекте свойственно мышление в духе: долго исследуем супер-фичу, мега-технологию, а потом быстро всё собираем и получаем продукт. Яркое отличие продукта в том, что в нём стадия «всё собираем» начинается очень рано, чуть ли не сразу, и большая часть графика отводится на доводку до ума всех частей. В проекте, наоборот, эта стадия наступает намного ближе к концу графика. График проекта похож на забивание десять тысяч гвоздей, можно сразу прикинуть как долго это займёт, и методично вколачивать. Вообще в проекте возникает ощущение, что «мы это уже делали, надо просто сделать ещё раз для данного конкретного продукта». Более того, процесс можно повторить по тому же графику создав ещё один схожий продукт. Многие успешные проекты, удались именно потому, что человек уже видевший весь график от начала до конца, уходит из коллектива и клонирует весь организационный проект, график работ и просто делает всё то же самое только качественнее, сознательно избегая исследований и экспериментов.

Если, скажем, у вас поле ввода иногда внезапно теряет фокус или неверно его перемещает, то с точки зрения проекта, это несущественная деталь, а с точки зрения продукта, это недостаток, который серьёзно может испортить его репутацию. Или там две кнопки однотипных на форме, но одна десятым кеглём, а другая одинадцатым. Мелочь, устраняется за 10 минут, надо найти нужный файл, нужное место, исправить, проверить. Никаких супер-технологий, но как минимум 10 минут долой. И в продукте таких мелочей обычно сотни и тысячи, они мелкие, их много и это позволяет применить главное оружие разработчика продукта — составить график. Сегодня исправляем тридцать косяков, завтра, и так сто дней, со всеми известными коэффицентами получим две тысячи рюшечек и деталей. А в проекте на это не останется времени.

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

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

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

В этом смысле менеджер разработки, который сам не программист и не может правильно оценивать колечки в цепочке разработки, это бедствие. Такой человек сразу проявляется и его надо гнать, обычно достаточно чтобы он несколько раз удивился, почему-же это заняло так много времени? Менеджеру программистов разрешено испытывать удивление только в случае неожиданно быстрого прохождения определённого отрезка дистанции. И то — не желательно. Ясное дело, что если у программиста всё в голове и ему не требуется глубокое переключение на момент новой строчки в плане, то он может сделать что-то практически мгновенно. То есть вы исправили кнопку в трёх разных местах, на всё ушло десять минут, но это произошло так быстро только потому, что это однотипная работа, и так случилось, что все три кнопки исправлялись подряд. Но если бы вам надо было исправить кнопку в одном месте кода, потому исправить глюк в протоколе, потом ещё кнопку, потом найти деление на ноль, и снова исправить ещё одну кнопку, то каждое кнопочное исправление могло занять по десять минут. Более того, можно учитывать не только процесс разработки на одном шаге и время переключения, но и приступы энтузиазма и упадки сил. Самый главный талант менеджера, будь то само-менеджер, или менеджер коллектива, это умение отследить, когда работа тормозится из за внезапно появившегося исследования. Обычно наморщеный лоб или желание отвлечься от работы хороший признак. Значит у разработчика, что то не складывается в голове, не удерживается в памяти, равномерное движение по пунктам плана затыкается. Тут то и нужно проявить опыт и глубокое понимание, и «разрулить» вопрос — либо осознать, что исследование неизбежно и внести жирный ряд неопределённого размера в табличку плана, и бросить все силы на решение, либо обойти вопрос, применив проверенное альтернативное решение. Если вы делаете продукт, ваша задача не «лучше работать», а наладить процесс до полной предсказуемости.

Любопытное бытовое сравнение, хотя надо понимать, что любое сравнение это только сравнение и может лишь иллюстрировать некий принцип, это готовка обеда. Когда вам надо себя покормить, вы можете очень быстро приготовить еду, и можете позволить себе эксперименты и исследования в процессе. Побольше посолить, поменьше, новую приправу попробовать, но если вам надо сделать праздничный ужин и покормить дорогих гостей, то ситуация в корне другая. Вроде затраты должны быть линейно масштабируемы, 5 гостей, значит предполагаемые затраты на праздничный ужин в пять раз больше чем на собственный обеденный перекус, но на самом-то деле, затраты будут отличаться на порядок, и по выбору ингридиентов, и по тщательности исполнения и сервировки, потраченному времени. Это проект и продукт. Никто не станет экспериментировать с праздничным борщом, а если и станет, то пожалеет. Гости то придут ровно в пять, то есть имеется дедлайн. Затраты на сервировку и деталировку, нарезание сыра тонкими ломтиками, размазывание варенья ровным слоем, это вещи которые в обычном бытовом обеде делаются в десятки раз проще чем в праздничном режиме. Таков продукт, это праздничный обед. Сложность исполнения праздничного обеда или ужина, компенсируется тем, что в нём всё детерминировано, каждая операция отлажена годами, в лучшем случае хозяйка решается на одно необычное блюдо, и оно отнимает массу времени и сил и сопровождается охами по принципу: «я раньше никогда не делала, решила попробовать, не судите строго», ищет конкурентное преимущество, так сказать. К тому же всё прекрасно масштабируется, потому-что большинство операций типовые и их могут делать все кто окажется на кухне.

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

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

Сколько раз вы слышали фразу «мы решили отказаться от. »? Моя юность пришлась на расцвет продуктов Борланд в России, я учился профессионально программировать и использовал Турбо Паскаль и позднее Дельфи. В связи с чем, у меня выработались некоторые навыки работы, привычка опираться на такие инструменты среды как F4 (Run to cursor), Control+Enter (Open file at cursor), мгновенная компиляция. Для меня стало критично, чтобы одной кнопкой я мог откомпилировать, поставить останов под курсором и запустить программу, потом так же терминировать её одной кнопкой и продолжить редактирование кода. Когда я пытался работать в привычном мне режиме на Visual Studio меня кроме на порядки более медленной компиляции сильно сбивало необходимость запускать отладчик одной кнопкой, запускать программу другой, предварительно удалять предыдущий брейк-пойнт и ставить новый, это целый процесс, на который я уже не мог отвлекаться. За несколько дней я написал макрос который кое-как решал проблему. Конечно, это мои личные пристрастия, но проблема в том, что у каждого программиста есть свои личные пристрастия, без них не бывает программиста, даже маляр имеет свои личные пристрастия к методам и инструментам. Один мой знакомый станко-наладчик, не мог работать если у него не было под рукой ванны с бензином, в которой он мог бы мгновенно в любое время полностью вымыть руки до предобеденной чистоты. Он ужасно страдал, когда приходилось работать в другом цехе, где такой ванны не было. Мелочь, но из таких мелочей и складывается рабочий процесс.

Я всегда постулировал такую вещь, как совершенство средств разработки. Знаете, как производство средств производства у марксистов, которое отличает развитую экономику от просто механизированной. Моё убеждение, что верно усовершенствованное средство разработки может ускорить разработку не на проценты, а на порядки, и не только ускорить, но и дать возможность разработчику браться за задачи иной степени сложности. Лет пять назад я сделал амбициозную попытку создать соответствующую моим требованиям C++ IDE. Она называлась DaoIDE. Для этого мне пришлось решить несколько фундаментальных проблем. Во-первых сделать свой текстовый редактор или научиться эффективно использовать Scintilla или другой открытый аналог. Текстовые редакторы я делаю сколько себя помню. Вообще, создание текстового редактора, это образец сложной задачи по программированию. Всё видно на экране, и сложнейшая структурность, это идеальная задачка для продвинутых учеников. Моя любовь к текстовым редакторам расцвела когда мне приходилось работать с приложением Aldus Page Maker, я открыто восхищался тем, что может эта программа, и ведь её написали в конце 80-х, начале 90-х. Мне довелось написать десятки текстовых редакторов from scratch, то есть с нуля. И это не считая сотен быстрых прототипов. От простейших нотепадов для доса, до систем со сложным маркапом и спец-требованиями. Так что с редактором не было особых проблем. Потом пришлось разбираться с отладчиком, я сделал множество прототипов интеракции среды с отладчиком, на основе dbghelp.dll, на чистом ассемблере, через GDB, GDB-MI, WinDbg и разных готовых обвесов над ними. Меня в процессе ужасало — как это сложно, насколько плохо всё документировано, очевидно, что ни один отладчик изначально не делался для встраивания в сторонние приложения. Потом пришлось разбираться с компилятором С++, основное моё требование к нему была скорость компиляции. Мне пришлось детально разобраться в истории разработки существующих компиляторов и убедиться, что самый быстрый компилятор (именно в смысле скорости компиляции, а не в смысле скорости работы скомпилированной программы) это Digital Mars C++ (DMC), бывший Symantec C++. Моё рассуждение простое, в процессе разработки приложения, его надо запустить много тысяч раз, а оптимизированный исполняемый выход нужен только в момент релиза один раз. DMC часто отрабатывал в несколько десятков раз быстрее соперников, давая перформанс близкий к привычному реактивному компилятору Delphi. Но он не давал возможности дебажить эти экзешники, из за лицензированного десятилетия назад формата объектного файла. MSVC, особенно ранних, версий был в разы быстрее GNU C++. Но не было шансов на кросплатформенность и жуткая невнятная документация, каждый чих, типа определения типа переменной, приходилось исследовать сутками. Этот проект занял у меня не меньше года, почти всё время ушло на исследования.

Проект среды С++ Дао заглох именно потому, что я убедился в неприменимости всех существующих IDE-строительных блоков доступных в мире, в первую очередь компиляторы, дебаггеры. Решая эту задачу, я потратил кучу времени изучая не только исходники но и сообщество и историю разработки этих инструментов. Например, я понял, что GCC никогда не будет быстро компилировать, более того, он с каждой версией будет компилировать всё медленнее, таков запрос рынка и таков фокус разработки. Не говоря про то, что сам направляющий комитет работает очень специфично, и пересматривать фундаментально устройство компилятора не станет никогда. Логика проста, там всё и так сделано по науке: lexer, AST, backend, codegen и т. п., нечего тут изобретать. Когда я увидел первое видео с рассказами авторов LLVM/Clang я прыгал от радости, было очевидно, насколько более творчески и решительно мыслят Apple и Google. Устройство GDB тоже кошмар и исторически и технически. Тут я должен разъяснить, что если я констатирую ужасность этих проектов, но это не значит, что мне они не нравятся, или я считаю идиотами, тех кто их сделал. Вовсе нет, это проекты мировые, и MSVC в том числе, компиляторы С++ вещь настолько сложная, что их в мире единицы, и все кто над ними работают это супер-люди! Можно буквально перечислить по пальцам проекты такого уровня. Просто стало ясно, что люди работают в другом направлении, чем то, которое близко лично мне. И мы снова возвращаемся к идее о совершенстве средства разработки и личных навыков разработчика.

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

Отчасти это объясняется маркетинговым сознанием западных производителей, если есть рынок, люди пользуются средством разработки, то зачем его фундаментально менять? Это же основы маркетинга. Если человек привык курить махорку, то не надо пытаться продать ему сигары, не лишай себя рынка, лучше перемолоть сигары в махорку и продавать улучшенную махорку. Зачем совершенствовать компилятор в неожиданных направлениях, если есть огромная пользовательская база уже обученная опираться на то, что есть? Надо просто подпиливать, и подкрашивать. Сейчас даже есть маркетинговая стратегия направленая на еженедельные, например, апдейты, а то, что там опять только «забор перекрасили» или кнопочку передвинули, это мелочи, главное, что — «проект жифф». Так выходит, что обычно сколько нибудь новые смелые решения на рынке появляются с новым продуктом, а не с новой версией уже существующего. Такие радикальные изменения, которые принесли Руби и Питон невозможно было бы ожидать от новой версии любой существующей системы.

Когда я писал YaUI, где надо было использовать сразу четыре языка программирования и три разных платформы, и соответственно, никакой отдельно взятый отладчик не мог это всё покрыть, я уже полностью и привык и полюбил отладку без отладчика, через кодомодификацию. Более того, я перевёл всю разработку в обычный notepad++, с компиляцией в командной строке, через скрипты, в результате мне удалось добиться одинакового подхода к разработке на всех трёх платформах и четырёх языках. (Java, ObjC, C++, JavaScript, Android, Windows, iOS). Когда я понял, что можно кодить вообще без монструозных IDE, убрать зависимость от этих огромных тормозных миров, можно вообще не компилировать и использовать Node.js, и не ждать когда в отладчике опять исправят очередной недостаток, я понял, что хочу сделать минималистский инструмент для такого стиля программирования. Так, собственно, и родилась идея Деодара. Хотелось ещё отказаться и от Windows, и уменьшить зависимость от ещё одной корпорации, то есть источника непредсказуемых перемен. Тут собственно я и возвращаюсь к основной теме статьи — проект и продукт, потому что мне сразу стало ясно, что написать нечто такое можно только проведя очень длительные исследования. То есть я хочу на собственном примере показать, как я пытался сознательно провести длительные исследования перед, собственно, работой над продуктом.

Первая задача с которой я столкнулся и которую решал около полугода, осознавая, что я могу и не справиться, была работа с окнами, экраном и клавиатурой. У меня уже был опыт разработки под XWindow System, и когда я только решил в этом разобраться, я в очередной раз убедился, что вся документация для юниксов построена по принципу манов, то есть если ты знаешь что набрать, ты набираешь и тебе написано, как это сделать, но если ты не знаешь как называется функция которая делает то, что тебе надо, ты будешь идти очень долгим путём. В конце-концов я научился работать с экраном и окнами через сокет по XWindow Protocol просто читая старинную спецификацию. Но мне не удалось главного, отрисовать Anti Aliased Text. То что в Windows или на Маке делается вызовом одной функции, в мире иксов целая история. Мне пришлось создавать OpenGL контекст и ручками рендерить туда буквы используя FreeType или HarfBuzz. Проблема была в том, что никак не удавалось достичь нормальной скорости, FPS. Я исследовал несколько десятков альтернатив, всевозможные тулкиты и обёртки, начиная от общепринятых GDK, Qt, FLTK, SDL и до очень сложных гибридных решений, включая GLUT, Pango в разных комбинациях. И каждая такая попытка занимала дни и даже недели. Десятки папок с прототипами лежат до сих пор. В конце концов я разобрался во всём и решил использовать Xlib+FreeType+OpenGL textures.

Далее возникла проблема буфера обмена. Оказалось, что на чистом Xlib это целая история и у меня опять ушли недели на решение этой проблемы. Мне кажется, людей понимающих как работает клипборд в линуксе на уровне иксов в мире единицы. Опять невероятно трудноуловимая документация. В конце концов я создал демонстрационный hello world на эту тему и выложил на гитхаб, теперь любой может в двадцати строчках увидеть как это делается на С. Поразило, что на Стэковерфло люди не смогли ничего внятного сказать по вопросу. Потом возникла проблема юникодного ввода текста и опять дни и недели исследований, десятки чужих примеров, которые все как обычно не работали и наконец удалось разобраться и с этим. Кстати, рассматривался и вариант работы Деодара из под консоли. Но поймите, терминал это древняя технология, он до сих пор совместим с телетайпами шестидесятых годов. Это рудимент, и главная проблема терминала это невозможность отлавливать нажатия на клавиши, то есть элементарное onKeyDown, onKeyUp в принципе невозможно на терминале в сущности являющимся потоковом символьным устройством на прямую не связанным с hardware. Недавно автора BASH спросили, как он видит будущее своего детища. Знаете что он ответил? Хочу, говорит, чтобы BASH поскорее исчез и его все забыли и создали наконец что то более современное, соответствующее современным задачам.

Потом надо было исследовать вопрос, использовать ли чистый движок V8 или Node.js? Как такое решить? Пришлось написать оба варианта и выбрать лучший. Оказалось, что возможности Ноды совершено достаточны и возможность подключать npm модули это большой плюс в сторону этого решения. И только тогда стало возможно переходить к собственно работе над продуктом. Хотя ещё оставалось изобрести свой аналог Turbo Vision, что тоже оказалось весьма нетривиальным делом. Оказалось, что в JavaScript прототипное наследование не цепочное, то есть если вы пропустили в промежуточном потомке перекрытие метода, то он автоматически перекрывается как копия. Поясняю: у вас есть классы A->B->C и вы написали A.draw() и С.draw(), и из С.draw() вам надо вызвать А.draw() то вы никак не можете это сделать анонимно если ТОЧНО не знаете, был ли написан B.draw(). А для аналога Turbo Vision с его цепочным анонимным наследованием это было критическим вопросом. Анонимное это значит что вы не пишете A.draw.apply(this), а пишете this.inherited.draw(). Ведь B.draw() может существовать, а может и отсутствовать. Я перечитал всё, что было в интернете по вопросу наследования в JavaScript, оказалось, что это не так уж много, все в основном ссылаются на одни и те же две три работы, и в них эта проблема тоже не решена. Мне понадобилось ещё несколько недель, чтобы разобраться в самых тонких деталях наследования в JavaScript и понять как можно эту проблемку решить, в результате появился репозиторий dnaof на Гитхабе.

Собственно Деодар как продукт заключался в гибриде классического двухпанельного файлового менеджера с его реактивной слепой навигацией и очень удобного текстового редактора, не уступающего Notepad++, SublimeText и прочим, по интересующим меня параметрам. Ещё важнейшим моментом было внедрение терминала внутрь Деодара. То есть по нажатию Escape пользователь видит запущенный BASH и все три компонента, редактор, файловые панели и консоль очень плотно соединены в конгруэнтную систему. И главная киллер фича, конечно, это собственно JavaScript, то есть этой среде не нужны какие-то API для разработки плагинов, у вас весь исходный код под рукой, и он минималистичен, это не миллионы строк а считанные тысячи. К моменту прошлогоднего релиза, с даты которого прошёл ровно год, всё ещё оставались две не решённые фундаментальные проблемы. Не удалось достичь желаемой скорости отрисовки, то есть она была приемлема, но хотелось ещё больше FPS и не удалось понять, как попасть в репозиторий Ubuntu, хотя-бы. Поэтому Деодар пока остаётся проектом. Прорисовку мне недавно довелось переписать и выйти на желаемый показатель performance. Теперь вся эта эпопея продолжается, потому что я сразу осознавал, что это ПРОЕКТ и длится он будет годами и надо понимать, что каждый шаг включает исследования с открытой датой.

Собственно уровень продукта ещё впереди, для меня это вопрос интерфейса, ведь как говаривает Линус наш, Торвальдс — если в вашей программе есть фича, но её нет в интефейсе, то и ФИЧИ НЕТ. А в Деодаре до сих-пор нету даже менюшек, калкулятора, редактора палитры, работы с архивами и прочего. Кстати, работа с архивами вещь нужная, просто в работе именно программиста, она вторична, моя же цель была сделать не столько файловый менеджер как таковой, а рабочую среду программиста с файловым менеджером внутри. Но для продукта и это нужно.

Ну вот, надеюсь вам было интересно провести этот небольшой экскурс в философию программирования и небольшой пиар моего проекта. Ко мне тут неоднократно в комментариях обращались с претензией, что уже какая статья в серии Философия Программирования, а собственно о программировании пока ничего нет. Моя цель писать именно о программировании, осмысляя это явление всесторонне, а не только чисто технически. Ведь большинство текстов о программировании крайне однобоки, из серии «вот поставил новую версию Х, позвольте рассказать на какие грабли пришлось наступить». Опять же, я не ставлю оценок, что хорошо, а что плохо, такие тексты сами по себе хороши, решают свои задачи. Но нам необходимо подкапываться к более сложным вопросам, развивать язык, вводить новые понятия, расширять существующие. Вот сегодня я попытался взять заезженные казалось бы понятия Проект и Продукт и порассуждать, прилюдно, чем они отличаются. Ведь, то, что происходит у программиста в голове нуждается в умении высказать, а мы до сих пор только тычем пальцем в экран и мычим, «ну что ты не понимаешь» или «смотри в код», «ну что поделать если люди не умеют программировать». Может они умеют, просто ты не знаешь как объяснить то что думаешь об этом участке кода? Это же вопрос развития языка. Возьмём к примеру замыкания, ведь нет в языках программирования такого ключевого слова, а замыкание есть! То есть понятие вводится исключительно гуманитарно, в голову программистов, мол смотрите, вот как можно написать и получится «замыкание», с ним можно делать и то и это. Потом понятие развивается, добавляются дочерние понятия, расширяется набор ассоциаций. В общем будем работать, двигаться в выбранном направлении. Я очень надеюсь, что если двигаться целенаправленно, то рано или поздно удастся найти правильный тон рассуждения о предмете и сильно обогатить наше представление о профессии. И огромное спасибо всем кто принимает участие в комментариях, даже тем кто меня минусует, критикует, а особенно тем кто читает и ждёт продолжений!