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

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

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

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

    Ну. И что?
    Реклама
    Комментарии 20
    • +1
      Начинаем с менеджмента разработки, отвлекаемся на детали разработки (это при том, что Анонимное это значит что вы не пишете A.draw.apply(this)), думаем о судьбах компиляторов, вспоминаем о Delphi, вспоминаем про линкус, но Проблема была в том, что никак не удавалось достичь нормальной скорости, FPS. Автор, о чем вы?
      • +1
        В принципе неплохой укол, но тогда надо уже роль непонятливого простолюдина выбившегося в программисты доигрывать до конца. Например так: «ах ты, мразь интеллигентская, очки нацепил, а вот я тебя рожей по асфальту вместе с этими очками, будешь тогда эмпирику с конгруэнтностью кровавыми соплями заедать!»

        Сразу всё станет на свои места.
        • 0
          О повсеместном несовершенстве?
        • +2
          Статья очень вредная. Особенно, для тех кто не совсем в теме.
          Вначале я подумал, прочитав заголовок, что это из области управления проектами.
          От интерпретации автором стандартных терминов «проект» и «продукт», волосы встали дыбом.

          (Автор совсем не понимает ни что такое «проект» ни что «такое „продукт“. Рекомендую ему почитать учебники PMI, и не придумывать свое уникальное понимание очень стандартных и весьма четко сформулированных терминов.)

          Прочитав чуть дальше, я понял, что это довольно бессвязный текст из „области“ треп под пиво и „тут Остапа понесло“.
          Жаль потраченного времени на такие статьи. Заголовки попроще нужно „Мой опыт в программировании и ответ на главный вопрос жизни, вселенной и всего такого».

          • –2
            А в учебнике по PMI не рассказали о зависимости смысла слов от контекста?
            • +2
              (если это не ваша статья, то считайте, что я обращаюсь к автору)
              Вы не придумали новый контекст. Начали Вы исключительно в контексте деятельности, которая однозначно попадает под то, что пытаются классифицировать, обобщить и стандартизировать в том же PMI.
              Изобретать новую терминологию исходя из своего незнания чего то, и опираясь исключительно на свой ограниченный опыт — это не верный подход. Вас просто не поймут, если вы придумаете свою собственную терминологию пересекающуюся со стандартной.
              «ограниченный опыт» — это не оскорбление и не принижение. Опыт у всех ограничен. Но не повод…

              И не надо говорить о контексте и приводить примеры «а Лобачевский свою геометрию придумал в другом контексте». Он, по крайней мере Эвклидову геометрию знал. А Вы похоже с управлением проектом как деятельностью, или с поддержкой продуктов не сталкивались. Или сталкивались, но даже не пытались изучать чужой опыт, а полагаетесь исключительно на свой собственный опыт «наступить на грабли» и «свой здравый смысл».

              Я Вас заверяю, в этой области очень много наработок.

              А насчет сумбура в тесте… Перечитайте его сам. Просто бессистемный поток сознания с перескоками с мысли на мысль.
              • 0
                Нет, статья не моя, мой интерес чисто энтомологический.
                Все же мне кажется, что вы не уловили контекст цикла статей автора, возможно я тоже не уловил. Но я и не берусь рассуждать. Вы же, опираясь на некие стандарты, ощущение адекватности и собственную самоуверенность, начинаете «отыгрывать роль» властного Взрослого-тоталитариста, попутно раздавая подзатыльники-минусы за мнение, отличное от вашего. Бытовой шовинизм, если проще. Спасибо за материал для наблюдений, такие статьи очень полезны самим фактом своего существования.
                • 0
                  Я не любитель доморощенной философии.
                  Философстовать на кухне, в курилке и ЖЖ — пожалуйста.

                  Но на хабре я все же ищу статьи не уровня ЖЖ.

                  • 0
                    У вас PMP или PMI-SP? Давно последний раз подтверждали?
                    • 0
                      Кажется PMP (специализации точно не было). Среди прочих курсов и той напряженной учебы даже не помню точно.
                      Значок и сертификат где то дома валяются.
                      Было обострение по учебе и проектным работам на работе…
                      3-4 года точно как прошло. Но на данный момент практического смысла подтверждать не вижу (работу не планирую менять...)

                      А что?
                      • 0
                        Может быть, сравнение огранизации PMI с псевдорелигиозной культовой организацией не совсем корректно, но оно напрашивается само собой. Ну посудите сами: тоталитарная иерархия, форматирование мозгов, нетерпимость к неправильным формулировкам, строгий языковой код, слепое преклонение перед авторитетами и самое главное, занимающее первое место в структуре организации в её бизнес- и опер- логике это не в меру развитая система сбора денег с паствы. Даже экзамен трудно сдать не купив брошюру за сто баксов «как правильно ходить на PMI экзамен». Может быть так было не всегда, лет двадцать назад организация была радикально «модернизирована», скорее всего чтобы более широко выйти на китайский, индийский и арабский рынки. Азиаты очень любят получать всякие бумажки от белых господ, и готовы платить каждый год подтверждая свои TOEFL, PMI, «you name it». Люди вышедшие из такой структуры, особенно вне США, (где это котируется примерно как ПТУ для менеджеров), автоматически считают себя высшими существами и требуют к себе особого отношения.

                        Даже ваши первые высказывания уже характеризуют сектантскую логику: «статья вредная» (претензия на безотносительную истину), «те кто не в теме» (объявление себя принадлежащим к особой касте).

                        • +1
                          Ясно. Т.е. реальной практики видения крупных проектов Вы не имеете, что такое стандарты и технологии в проектной деятельности не знаете. Про PMI слышали только краем уха.
                          И просто рефлексируете по этому поводу.

                          Агрессивное невежество… как это типично.
                          • –1
                            Ну совсем недавно автор вообще на комментарии не отвечал. Так что развитие налицо.
                            • +1
                              Наш госсектор через мясорубку таких курсов менеджмента пропустил тысячи и тысячи людей, в результате они могут только эффективнее воровать. Это же общая логика тумба-юмбы, «сделаем как у них». А то что «они» НИКОГДА не объяснят вам как они дела делают, это тумба-юмбе не вдомёк. Пример Голливуда как бы намекает. Пинжаки в офисе потеют, галстуки поправляют и не понимают, что джентельмен за кадром позвонил директору тренингового центра и сказал:

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

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

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

                              А ситуация с алгоритмическими исследованиями постоянно возникает. Нужен продукт, в нём необходим уникальный алгоритм, его могут за сутки разработать, а могут за пять лет, и никто этот срок не может предсказать, ни программист, ни тем более менеджер. Менеджер только будет беситься после того как пройдёт «первое приближение срока» названное девелопером. И второе. И будет орать на девов, а они его будут ненавидеть. Придут к владельцу фирмы в его кабинет и будут молить «убери его, всё портит, везде лезит, ничего не понимает». А всё от чего? А человек думает, что он умный. А у него просто туфли дорогие.

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

                              В том то и дело, что обычные программисты, даже новички после универа сталкиваются с типом проблем которых в учебнике менеджмента 60-х годов быть не могло в принципе. В то время такой тип проблемы, как планирование непланируемого, уникальные исследования с неопределённым результатом решали лишь несколько структур в мире. Манхеттенский проект, НАСА, Минатом, авиаконструкторы…
                              • –1
                                Сколько злобы и эмоций…
                                Вас наверное часто обижают и недооценивают?
                                Судя по некоторым намекам Вам уже не 20 лет.

                                А отвечать за более менее крупный проект, планировать сроки и контролировать ход проекта вам точно не приходилось.

                                К большому огорчению таких программеров как Вы, я программизмом занимаюсь последние 20 лет. И в каких только областях и каким только инструментарием не пользовался. И в проектах иногда и роль кодера выполняю (а что делать..). Поэтому всегда могу оценить что кому можно поручать и за какие сроки и с какой вероятностью он это сделает. И сложность задачи могу оценить. 90% задач — это типовые задачи.

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

                                И не надо мне сказки рассказывать. 99% программных продуктов это рутина, не требующая никаких фундаментальных исследований и уникальных алгоритмов.

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

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

                                Пример пожалуйста. Описание (входные данные, ожидаемый результат, производительность, среда выполнения).
                                А я скажу сколько приблизительно понадобится. Или скажу, что неопределенно (если Вы мне малую теорему Ферма для численного решения подкинете. Но это уже не алгоритмический класс задач, а математический).
                                • +2
                                  Вы используете слово скандалист, с неправильным смыслом. Скандал, это публичное обвинение в преступлении получившее резонанс в общесте. Если бы вы присвоили себе Макбук компании, купленный для программера Васи, а Васе всучили свой старенький дешёвый Асер, а я бы поднял шум и сделал вашу жизнь невыносимой в этом месте, вот это был бы скандал. В данном случае вы хотели сказать просто «вы мне не нравитесь», это была бы честная констатация факта. Но российский менеджер никогда не может так сказать, ведь для этого надо признать, что ты разговариваешь с живым человеком, а не с винтиком своей воображаемой машины «серьёзных проектов».

                                  Видите ли, когда человек вам пишет в своём ответе «сколько злобы и эмоций» это по факту значит лишь одно, он в этот момент сам зол и полон эмоций и просто характеризует своё состояние. Это факт. Ведь невозможно определить по тексту эмоции собеседника, вам любой лингвист это скажет. Ну поставлю я десять восклицательных знаков, и что, я возбуждён? Рад? А может мне просто нравится как они выглядят!!!

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

                                  Ваша эмоциональная реакция, кроме всего прочего ещё и показывает что менеджер вы плохой. И это не оскорбление, это элементарное умозаключение. Моё. И с ним тоже можно совершенно спокойно не соглашаться. Но при имеющейся скудной информации, именно такой вывод я делаю попыхивая трубочкой. Вот как идёт мысль: менеджера в самом начале обучения, первым делом НАТАСКИВАЮТ не проявлять эмоций, он должен сидеть перед лицом начальства или переговорщиков смирно сложив ручки, и чтобы ни она складочка не шевельнулась на форменном пиджаке. То есть от него ожидается каменное лицо и отсутствие эмоций в любой ситуации. Это минимально необходимо для приёма комманд от вышестоящих в пищевой цепочке, и для того, чтобы партнёр по совещанию, тот же программист, имел возможность до конца высказать свою, даже неадекватную, точку зрения. А вам уже хочется меня уволить, в голове слово «зло» появляется. Где выдержка элементарная?

                                  Ваша просьба о примерах подтверждает вывод о степени вашего аутизма. Мы обсуждаем сорока-килобайтную статью напичканую примерами. Работа с Xlib из Node.js, буфер обмена, вывод на экран, цепочечное наследование, написание своего эмулятора терминала XTerm. Но могу добавить ещё парочку.

                                  Надо написать конвертор из формата ААА в HTML. Причём документации по ААА нет, приложения геренирующего AAA тоже нет. И то и другое, может быть можно найти, а может быть и нет.

                                  Надоразделитьрусскийтекстнасловатоестьвставитьнедостающиепробелы.

                                  • –2
                                    Ваше описание «менеджера» и представление о «нем», лично мне показывает, что вы живете в каком то своем собственном мире, созданном вашим воображением. Складочки… аутизм… безэмоциональность.
                                    Где же Вас жизнь то так обидела… Что у вас на все есть ярлык.

                                    Надо написать конвертор из формата ААА в HTML. Причём документации по ААА нет, приложения геренирующего AAA тоже нет. И то и другое, может быть можно найти, а может быть и нет.

                                    Типичная задача реверсинженеринга. Только слишком абстрактно сформулирована. Сплошь и рядом протокол приходится востанавливать по логам. Только вот «нет приложения» генерирующего ААА" — это Вы надуманно ограничение добавили. Нет приложения генерирующего/принимающего и реагирующего на протокол ААА — нет программной задачи разбора протокола ААА…

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

                                    Надоразделитьрусскийтекстнасловатоестьвставитьнедостающиепробелы.

                                    Опять же не хватает критериев. Например, среднее количество ошибок в выходном/входном тексте, быстродействие, ограничением по памяти и пр.
                                    Поскольку этих критериев, ограничивающих способ реализации нет, то эта задача влет решается простым перебором по словарю корней суффиксов и слов. Словарь, например, от одного из бесплатных русско-английских или морфологических словарей.
                                    До 200 строк исходного кода с хранением словаря в памяти. 2-3 ч/д среднему программисту если с 0.

            • 0
              Если вы планируете делать революционный продукт, можете добавить шаг назад в отладчик, сложные условные остановы(остановится, если были исполнены определенные точки программы в определенном порядке), возможность написать отладочный скрипт(изменяет состояние программы в заданных точках, позволяет проверить, правильно ли изменится поведение без остановки отладки и перекомпиляции), запоминание(классификация) частых сценариев использования среды(или хотя бы запись макросов) и поддержку управления и настройки среды из скрипта(как в VS на F#)
              • +1
                Превосходная серия статей, читаю с большим удовольствием!
                Некоторая сумбурность изложения и перескакивание с темы на тему статьям абсолютно не вредит.
                Плюсануть не могу, просто скажу спасибо автору.
                • +1
                  Первая статья в серии, которая у меня не вызвала отторжение. Потому что она о внутренних проблемах, которые понятны, а не отношениях с другими людьми, где автор идёт поперёк всех норм и стандартов.

                  Наверное каждый, наигравшись с более-менее сложными программами, начинает свой тёплый ламповый проект «для себя». Обязательно чтобы супер-комбайн с текстовым редактором, подсветкой синтаксиса не хуже Colorer, файловым менеждером, всеядным парсером всех форматов (начиная с поддержки архивов, до входа в образы дисков ext4 своим драйвером ФС или файлы ресурсов любой игры, до которой можно дотянуться). Обязательно кроссплатформенный, чтобы запускался на любом калькуляторе, и со своим STL, а то вдруг на одной из целевых платформ будет кривой. Крайний случай — своя ОСь со всеми приложениями.

                  Гиблое это дело. Энтузиазма хватит на несколько лет, затем ужас от всего понаписанного, желание отрефакторить в корне, а то и переписать заново.

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое