Разница между продуктом и проектом в том, что при разработке продукта есть план, а при разработке проекта есть исследования. Если у вас есть какая-то не решённая проблема, скажем вы ещё не решили какую базу данных использовать в своём проекте, то вам понадобится этот вопрос изучать, то есть исследовать. Это называется 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. Теперь вся эта эпопея продолжается, потому что я сразу осознавал, что это ПРОЕКТ и длится он будет годами и надо понимать, что каждый шаг включает исследования с открытой датой.

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

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

Философия программирования
6: Продукт и Проект
5: Реактос и Колибри
4: Технология «Шапито»
3: Чичиков и программиат
2: Миф и язык
1: Трёхнаправленное программирование