Разница между продуктом и проектом в том, что при разработке продукта есть план, а при разработке проекта — исследование.
Если у вас есть какая-то нерешенная проблема, скажем, вы еще не решили, какую базу данных использовать в своем проекте, то вам нужно будет изучить этот вопрос, то есть исследовать его.
Это называется технологическим исследованием.
Исследования, это совсем не обязательно, что-то совершенно новое в мировом масштабе, если вы строите мост, то вам нужно изучать почву именно в этом месте, и пока эта почва не изучена, мост, как продукт, пока не существует, пока это - проект. Пока неизвестно, что это за грунт, а значит неизвестно, из чего сделать мост, как его укрепить, невозможно рассчитать бюджет и спланировать график работ. Конечно, любой проект — это как план, есть последовательность действий, могут даже ставить какие-то сроки, но пока в нем есть неизведанные белые пятна, это план с дырами, то есть проект. Если вы смогли разработать продукт и в процессе исследовать множество технологий, то вы получаете конкурентное преимущество на рынке, поэтому желание заниматься не разработкой продукта, а проектом похоже на болезнь.
Программист думает: вот, вот эту штучку изучим, придумаем и всех уничтожим.
А любое исследование имеет неопределенный срок, и если вы или программист говорите себе «нужно еще придумать, как это сделать», сразу отметьте для себя: здесь речь идет об исследовании, то есть не о продукте, а о продукте.
а о проекте.
Проект имеет неопределенные временные рамки, в частности, из-за исследований.
Работая над проектом, мы склонны мыслить в духе: мы долго исследуем суперфичу, мегатехнологию, а затем быстро собираем все воедино и получаем продукт. Яркое отличие продукта в том, что в нем этап «собрать все воедино» начинается очень рано, практически сразу, и большая часть графика посвящена доработке всех деталей.
В проекте, наоборот, этот этап происходит гораздо ближе к концу графика.
График проекта похож на забивание десяти тысяч гвоздей, можно сразу прикинуть, сколько времени это займет, и методично забить.
Вообще в проекте возникает ощущение, что «мы это уже сделали, нам просто нужно сделать это еще раз для этого конкретного продукта».
Более того, процесс можно повторить по тому же графику, создав еще один аналогичный продукт. Многие успешные проекты добились успеха именно потому, что человек, который уже видел весь график от начала до конца, уходит из команды и клонирует весь организационный проект, график работы и просто делает то же самое, только лучше, сознательно избегая исследований и экспериментов.
Если, скажем, ваше поле ввода иногда вдруг теряет фокус или неправильно перемещает его, то с точки зрения проекта это незначительная деталь, а с точки зрения продукта это недоработка, которая может серьезно испортить его репутация.
Или на форме две одинаковые кнопки, но одна десятая точка, а другая одиннадцатая.
Это мелочь, это можно исправить за 10 минут, нужно найти нужный файл, нужное место, исправить, проверить.
Никаких супер-технологий, но минимум в 10 минутах ходьбы.
А таких мелочей в продукте обычно сотни и тысячи, они маленькие, их много, и это позволяет использовать главное оружие разработчика продукта — создать график.
Сегодня исправим тридцать косяков, завтра и так сто дней, со всеми известными коэффициентами получим две тысячи наворотов и деталей.
А времени на это в проекте не останется.
Если бы я хотел сказать, что проект плохой, а продукт хороший, я бы так и сказал.
Я просто хочу четко разделить эти два понятия, мне кажется, это может сэкономить немало усилий.
Сам проект – замечательное явление, исследования – это тоже настоящее творчество.
Причем проект можно реализовать, осознавая всю вероятностно-игровую суть исследования, грамотно распределяя и оформляя даже эти неопределенные условия.
В конце концов, это всего лишь неопределенная проекция, но вам просто нужно четко осознавать, что именно вы делаете.
Лично я по опыту привык проводить все исследования перед началом планирования продукта, все используемые технологии, принципы и правила должны быть исследованы, вопросов не должно оставаться, в конце исследования должно быть принято принципиальное решение, что все , мы принимаем эти решения, осознавая их преимущества и недостатки, и переходим к этапу планирования, то есть разработки продукта.
Исследования включают в себя поиск подходящих технологий и инструментов, создание уникальных алгоритмов и обучение персонала, первичные исследования производительности, составление списка функций, необходимых заказчику или рынку, и даже поиск удобного режима работы.
То есть все, что заранее неизвестно и не может быть формально определено.
То есть к тому моменту, когда вы приступите к разработке продукта, то есть составлению плана и графика работ, у вас уже не должно быть слепых зон, вопросов, а план складывается из прочных, осязаемых, увесистых кирпичиков.
Как только у вас возникнет ощущение, что все понятно и вам просто нужно поработать, забить гвозди или клонировать фичу из фичи продукта конкурента, тогда можно говорить, что продукт состоялся.
Конечно, позже может оказаться, что она не увенчается успехом, и были допущены ошибки в планировании или определении технического задания, или ошибки в самой практической работе, но это уже будет учтено в следующем проекте/продукте.
.
Умение накапливать опыт и переносить алгоритм работы от продукта к продукту, от проекта к проекту вообще отличает человека, вставшего на правильный путь в развитии.
Например, я давно знаю, что смена шрифта в кнопке занимает в среднем не менее десяти минут; раньше мне казалось, что это дело секунд. Набор кирпичиков расписания, умение сортировать все задачи и подзадачи по сложности выполнения, времени выполнения, требуемой квалификации — базовый навык планирования.
Некоторые типы головоломок не очень сложны, но они способны сильно утомлять память и тогда требовать увеличения времени для перехода к следующим головоломкам.
Являетесь ли вы руководителем целой конторы программистов или одиноким человеком, в любом случае вам нужно постоянно смотреть на себя со стороны, и не только радоваться тому, что следующий шаг выполнен, а сразу думать о следующем.
один, но нужно постоянно осмысливать и даже произносить вслух и записывать, какая задача была решена, сколько времени ушло на ее решение, как она типизируется, какой опыт можно почерпнуть для дальнейшего планирования.
В этом смысле руководитель разработки, который сам не является программистом и не может правильно оценить кольца в цепочке разработки, — это катастрофа.
Такой человек сразу появляется и его нужно прогнать, обычно ему достаточно несколько раз задаться вопросом, почему так долго? Удивление менеджеру-программисту позволено испытать только в случае неожиданно быстрого прохождения определенного отрезка дистанции.
А это не желательно.
Понятно, что если у программиста все в голове и ему не нужно глубоко переключаться на момент новой строки в плане, то он может что-то сделать практически мгновенно.
То есть вы починили кнопку в трех разных местах, все это заняло десять минут, но произошло это так быстро только потому, что это была однотипная работа, и так получилось, что все три кнопки были закреплены подряд. Но если вам нужно было исправить кнопку в одном месте кода, следовательно, исправить глюк в протоколе, затем еще одну кнопку, затем найти деление на ноль и снова исправить еще одну кнопку, то каждое исправление кнопки могло занять десять минут. Причем можно учитывать не только процесс разработки за один шаг и время переключения, но и приступы энтузиазма и срывы.
Важнейший талант менеджера, будь то самоуправитель или руководитель команды, — это умение отслеживать, когда работа замедляется из-за внезапно появляющихся исследований.
Обычно морщинистый лоб или желание отдохнуть от работы – хороший знак.
Это значит, что у разработчика что-то не складывается в голове, не сохраняется в памяти и плавное движение по пунктам плана блокируется.
Вот здесь-то и нужно проявить опыт и глубокое понимание, и «решить» вопрос – либо осознать, что исследование неизбежно, и добавить в таблицу плана жирную строку неопределенного размера, и бросить все силы на ее решение, либо обойти задачу.
проблему, используя проверенное альтернативное решение.
Если вы делаете продукт, ваша задача не «сделать лучше», а настроить процесс до полной предсказуемости.
Интересное житейское сравнение, хотя надо понимать, что любое сравнение – это всего лишь сравнение и может лишь проиллюстрировать определенный принцип – приготовление ужина.
Когда вам нужно накормить себя, вы можете приготовить еду очень быстро, а по пути экспериментировать и исследовать.
Добавляйте больше соли, меньше, пробуйте новую приправу, но если вам нужно приготовить праздничный ужин и накормить дорогих гостей, то ситуация совсем иная.
Кажется, что затраты должны быть линейно масштабируемыми, 5 гостей, а это значит, что ориентировочные затраты на праздничный ужин в пять раз больше, чем на собственный обеденный перекус, но на самом деле затраты будут отличаться на порядок, как в выбор ингредиентов, а также забота об исполнении и подаче - пустая трата времени.
Это проект и продукт. Никто не будет экспериментировать с праздничным борщом, а если и сделает, то пожалеет об этом.
Гости приедут ровно в пять, то есть срок есть.
Затраты на сервировку и детализацию, нарезку сыра тонкими ломтиками, выкладывание варенья ровным слоем – это дела, которые за обычным домашним ужином делаются в десятки раз проще, чем в праздничной обстановке.
Это продукт, это праздничный ужин.
Сложность исполнения праздничного обеда или ужина компенсируется тем, что в нем все предопределено, каждая операция отлажена годами, в лучшем случае хозяйка решается на одно необычное блюдо, а на это уходит много времени.
времени и усилий и сопровождается стонами по принципу: «Я никогда раньше этого не делал».
, решил попробовать, не судите строго», ищу конкурентное преимущество, так сказать.
Кроме того, все прекрасно масштабируется, ведь большинство операций стандартны и их может выполнить любой, кто окажется на кухне.
Прошел год с тех пор, как я представил сообществу свой проект Deodar. Изначально это был типичный «Проект»; Я сразу же определил, что объем исследований, которые необходимо было провести, чтобы реально приступить к реализации продукта, огромен.
Начнем с того, что отсутствие качественных прорывов в интересующих меня инструментах разработки угнетало меня на протяжении многих лет, даже десятилетий.
Сколько раз, устанавливая новую версию любимого средства разработки, редактора, IDE, отладчика, вы удивлялись, как много сделали разработчики, и как опять ничего по сути не изменилось? В open source проектах вообще основная тенденция — избегать фундаментальных изменений, тотального рефакторинга, а вместо этого прикреплять к машине все новые и новые ручки, озонаторы и каждый раз перекрашивать двери.
В то время как здоровый процесс итерации версий должен время от времени включать фундаментальные изменения по всем направлениям.
Одним из таких фундаментальных изменений является решение проблемы, которую на обычном языке можно назвать «не хватает мелочи».
То есть есть отличный инструмент, все устаревает, но не хватает одной привычной мелочи, которая вам нужна, и из-за этого продукт, разработанный с ресурсом в сотни тысяч человеко-часов, не вызывает нареканий, из-за функционал, разработка которого занимает один человеко-день.
Для разработчика, как человека, решающего нетривиальные задачи, очень важно опираться на инструмент, а зависимость от этого инструмента определяет принятие стратегических решений при планировании.
Сколько раз вы слышали фразу «мы решили отказаться…»? Моя юность пришлась на период расцвета продуктов Borland в России, я научился профессионально программировать и пользовался Turbo Pascal, а позже Delphi. В связи с этим у меня выработались некоторые навыки работы, привычка полагаться на такие инструменты среды, как F4 (Выполнить до курсора), Control+Enter (Открыть файл по курсору), мгновенную компиляцию.
Для меня стало критично, что я могу одной кнопкой скомпилировать, поставить остановку под курсором и запустить программу, затем также одной кнопкой завершить ее и продолжить редактирование кода.
Когда я пробовал работать в обычном режиме на Visual Studio, помимо более медленной на порядки компиляции, меня сильно смущала необходимость запускать отладчик одной кнопкой, запускать программу другой, сначала удалять предыдущую точку останова и установить новый, это целый процесс, на который я уже не мог отвлекаться.
В течение нескольких дней я написал макрос, который как-то решил проблему.
Конечно, это мои личные предпочтения, но проблема в том, что у каждого программиста есть свои личные предпочтения, без них нет программиста, даже у маляра есть свои личные предпочтения в методах и инструментах.
Один мой знакомый, наладчик станков, не мог бы работать, если бы у него не было под рукой ванночки с бензином, в которой он мог мгновенно, в любой момент полностью вымыть руки до их чистоты до обеда.
Он ужасно страдал, когда ему пришлось работать в другой мастерской, где такой ванны не было.
Это мелочь, но именно из таких мелочей складывается рабочий процесс.
Я всегда постулировал такое понятие, как совершенство средств разработки.
Знаете, как производство средств производства у марксистов, которое отличает развитую экономику от просто механизированной.
Я убежден, что правильно улучшенный инструмент разработки способен ускорить разработку не на проценты, а на порядки, и не только ускорить ее, но и дать возможность разработчику браться за задачи разной степени сложности.
Около пяти лет назад я предпринял амбициозную попытку создать C++ IDE, отвечающую моим требованиям.
Он назывался DaoIDE. Для этого мне пришлось решить несколько принципиальных задач.
Для начала создайте свой собственный текстовый редактор или научитесь эффективно использовать Scintilla или другой аналог с открытым исходным кодом.
Сколько себя помню, я создаю текстовые редакторы.
В общем, создание текстового редактора — это пример сложной задачи программирования.
На экране все видно, причем самая сложная структура, это идеальная задача для продвинутых учеников.
Моя любовь к текстовым редакторам расцвела, когда я работал с приложением Aldus Page Maker, я открыто восхищался тем, на что способна эта программа, а ведь написана она была в конце 80-х, начале 90-х.
У меня была возможность написать десятки текстовых редакторов с нуля, то есть с нуля.
И это не считая сотен быстрых прототипов.
От самых простых блокнотов для DOS, до систем со сложной разметкой и особыми требованиями.
Так что с редактором особых проблем не возникло.
Дальше мне пришлось разобраться с отладчиком, я сделал множество прототипов взаимодействия среды с отладчиком на базе dbghelp.dll, на чистом ассемблере, через GDB, GDB-MI, WinDbg и различные готовые комплекты поверх них.
Я ужаснулся в процессе — насколько это сложно, как плохо всё документировано, очевидно, что ни один отладчик изначально не был сделан для встраивания в сторонние приложения.
Затем мне пришлось иметь дело с компилятором C++; моим главным требованием была скорость компиляции.
Пришлось детально разобраться в истории развития существующих компиляторов и убедиться, что самый быстрый компилятор (именно в смысле скорости компиляции, а не в смысле скорости компилируемой программы) — это Digital Mars C++ (DMC).
, ранее Symantec C++.
Мои рассуждения просты, в процессе разработки приложения его нужно запускать много тысяч раз, а оптимизированный исполняемый вывод нужен только один раз во время релиза.
DMC часто работал в несколько десятков раз быстрее своих конкурентов, обеспечивая производительность, близкую к обычному реактивному компилятору Delphi. Но он не давал возможности отлаживать эти исполняемые файлы из-за формата объектных файлов, лицензированного несколько десятилетий назад. MSVC, особенно ранние версии, был во много раз быстрее, чем GNU C++.
Но не было никаких шансов на кроссплатформенность и жуткую расплывчатую документацию; каждый чих, например определение типа переменной, нужно было расследовать.
Этот проект занял у меня как минимум год, почти все время ушло на Проект среды C++ Tao застопорился именно потому, что я был убежден, что все существующие в мире строительные блоки IDE, в первую очередь компиляторы и отладчики, неприменимы.
Решая эту проблему, я потратил много времени на изучение не только исходного кода, но и сообщества и истории развития этих инструментов.
Например, я понял, что GCC никогда не будет компилироваться быстро, более того, с каждой версией он будет компилироваться медленнее, это требование рынка и это фокус развития.
Не говоря уже о том, что сам оргкомитет работает весьма специфично и никогда принципиально не пересматривает конструкцию компилятора.
Логика простая, все уже сделано по науке: лексер, AST, бэкенд, кодеген и т. д., тут придумывать нечего.
Когда я увидел первое видео LLVM/Clang, я подпрыгнул от радости, было очевидно, насколько более креативно и решительно мыслят Apple и Google. Устройство GDB также является кошмаром как исторически, так и технически.
Здесь я должен уточнить, что если я констатирую ужас этих проектов, это не значит, что они мне не нравятся или что я считаю идиотами тех, кто их сделал.
Вовсе нет, это глобальные проекты, в том числе и MSVC, компиляторы C++ настолько сложны, что их в мире единицы, и все, кто над ними работает, — супер-люди! Перечислить проекты такого уровня можно буквально на одной руке.
Просто стало понятно, что люди работают в другом направлении, чем то, которое было близко мне лично.
И мы снова возвращаемся к мысли о совершенстве средства разработки и личных навыках разработчика.
Это просто мой стиль, мне важно дать процессу идти своим чередом, важно ощутить немедленный эффект и запускать приложение после каждого малейшего изменения, чтобы почувствовать его.
Это не плохо и не хорошо, это просто мой личный стиль.
Между прочим, оно не столь уж эмпирично по своей сути; есть также исследования психологов.
Например, доказано, что для успешной работы ума, закрепления памяти человеку необходимо мгновенно получать результаты, это согласно теории обучения и плодотворного труда.
Здесь мы снова затрагиваем тему психологии, я уверен, что без глубокого изучения процессов памяти, принятия решений, настроения и прочего детального изучения работы программиста наше совершенствование инструментов разработки будет крайне неэффективным.
Отчасти это объясняется маркетинговым сознанием западных производителей: если есть рынок, люди используют инструмент разработки, то зачем его кардинально менять? Это основы маркетинга.
Если человек привык курить махорку, то не надо пытаться продать ему сигары, не лишайте себя рынка, лучше перемолоть сигары в махорку и продать улучшенную махорку.
Зачем улучшать компилятор в неожиданных направлениях, если имеется огромная база пользователей, уже обученных полагаться на то, что есть? Вам останется только подпилить и подкрасить.
Сейчас даже есть маркетинговая стратегия, направленная на еженедельные, например, обновления, но то, что опять только «забор перекрасили» или кнопку сдвинули – это мелочь, главное, что это «гиф-проект».
Получается, что обычно какие-то новые смелые решения появляются на рынке с новым продуктом, а не с новой версией существующего.
Столь радикальных изменений, которые привнесли Ruby и Python, невозможно было бы ожидать от новой версии любой существующей системы.
Когда я писал YaUI, где нужно было использовать сразу четыре языка программирования и три разные платформы и соответственно ни один один отладчик не мог все это охватить, я уже полностью освоился и полюбил отладку без отладчика, путем модификации кода.
Более того, всю разработку я перенес на обычный блокнот++, с компиляцией в командной строке, через скрипты, в результате мне удалось добиться одинакового подхода к разработке на всех трех платформах и четырех языках.
(Java, ObjC, C++, JavaScript, Android, Windows, iOS).
Когда я понял, что можно вообще кодить без чудовищных IDE, убрать зависимость от этих огромных медленных миров, можно вообще не компилировать и использовать Node.js, а не ждать, пока в отладчике исправят очередную оплошность, я понял, что Я хотел создать минималистичный инструмент для такого стиля программирования.
Так родилась идея Деодара.
Еще мне хотелось отказаться от Windows и снизить зависимость от еще одной корпорации, то есть источника непредсказуемых изменений.
Здесь, собственно, я возвращаюсь к основной теме статьи — проекту и продукту, потому что мне сразу стало понятно, что написать нечто подобное можно только после очень долгих исследований.
То есть я хочу на своем примере показать, как я старался сознательно проводить долгосрочные исследования, прежде чем реально работать над продуктом.
Первая задача, с которой я столкнулся и на решение которой потратил около полугода, понимая, что могу не справиться, — это работа с окнами, экраном и клавиатурой.
У меня уже был опыт разработки под XWindow System, и когда я только решил этим заняться, то еще раз убедился, что вся документация для Unix построена по мана-принципу, то есть если знаешь, что печатать, ты печатаешь, и тебе написано, как это сделать, но если ты не знаешь названия функции, которая делает то, что тебе нужно, ты проделаешь очень долгий путь.
В итоге я научился работать с экраном и окнами через сокет по протоколу XWindow, просто прочитав старую спецификацию.
Но мне не удалось сделать главное — нарисовать Anti Aliased Text. Что делается в Windows или на Mac вызовом одной функции — это целая история в мире X. Мне пришлось создавать контекст OpenGL и вручную рендерить там буквы с помощью FreeType или HarfBuzz. Проблема была в том, что невозможно было добиться нормальной скорости и FPS. Я исследовал несколько десятков альтернатив, всевозможных наборов инструментов и оберток, начиная от общепринятых GDK, Qt, FLTK, SDL и заканчивая очень сложными гибридными решениями, включая GLUT, Pango в различных сочетаниях.
И каждая такая попытка занимала дни и даже недели.
До сих пор валяются десятки папок с прототипами.
В конце концов я разобрался и решил использовать текстуры Xlib+FreeType+OpenGL. Затем возникла проблема с буфером обмена.
Оказалось, что на чистом Xlib это целая история и мне снова потребовались недели, чтобы решить эту проблему.
Мне кажется, в мире есть всего несколько человек, которые понимают, как работает буфер обмена в Linux на X-уровне.
Опять невероятно неуловимая документация.
В итоге я создал демо hello world на эту тему и выложил на Github, теперь любой желающий может увидеть в двадцати строках, как это делается на C. Меня поразило, что на Stackoverflo люди не смогли сказать ничего вразумительного по этому вопросу.
Потом возникла проблема ввода текста в Юникоде и снова дни и недели исследований, десятки чужих примеров, которые все работали не так, как обычно, и наконец удалось разобраться и в этом.
Кстати, рассматривался и вариант запуска Деодара из-под консоли.
Но поймите, терминал — это древняя технология, он до сих пор совместим с телетайпами шестидесятых годов.
Это рудимент, а основная проблема терминала - неумение отлавливать нажатия клавиш, то есть элементарный onKeyDown, onKeyUp в принципе невозможен на терминале, который по сути является потоковым символьным устройством, не связанным напрямую с железом.
Недавно автора BASH спросили, каким он видит будущее своего детища.
Знаешь, что он ответил? Я хочу, говорит он, чтобы BASH как можно скорее исчез, чтобы все забыли о нем и создали наконец что-то более современное, соответствующее современным задачам.
Затем мне пришлось изучить вопрос, использовать ли чистый движок V8 или Node.js? Как это решить? Пришлось написать оба варианта и выбрать лучший.
Оказалось, что возможностей Noda вполне достаточно и возможность подключения npm-модулей является большим плюсом в пользу этого решения.
И только тогда стало возможным перейти к реальной работе над продуктом.
Хотя оставалось еще изобрести свой аналог Turbo Vision, что тоже оказалось делом весьма нетривиальным.
Оказалось, что в JavaScript прототипическое наследование не является цепным, то есть если вы пропустили переопределение метода в промежуточном потомке, то он автоматически переопределяется как копия.
Поясню: у вас есть классы A-> B-> C и вы написали A.draw() и C.draw(), а из C.draw() нужно вызвать A.draw(), тогда вы не сможете сделать это в любом случае анонимно, если вы ТОЧНО не знаете, был ли написан B.draw().
А для аналога Turbo Vision с его цепным анонимным наследованием это был критический вопрос.
Анонимный означает, что вы не пишете A.draw.apply(this), а пишете this.inherited.draw().
В конце концов, B.draw() может существовать, а может и не существовать.
Перечитал все, что было в Интернете по вопросу наследования в JavaScript, оказалось, что это не так уж и много, все в основном ссылаются на одни и те же две-три работы, и в них эта проблема тоже не решена.
Мне потребовалось еще несколько недель, чтобы разобраться в самых тонких деталях наследования в JavaScript и понять, как решить эту проблему, в результате на GitHub появился репозиторий dnaof. Фактически Deodar как продукт представлял собой гибрид классического двухпанельного файлового менеджера с его реактивной слепой навигацией и очень удобного текстового редактора, не уступающего Notepad++, SublimeText и другим по интересующим меня параметрам.
Еще одним важным моментом стало введение терминала внутри Деодара.
То есть, нажав Escape, пользователь видит работающий BASH, и все три компонента — редактор, файловые панели и консоль — очень тесно связаны в единую систему.
И главная фишка, конечно, это сам JavaScript, то есть этой среде не нужны никакие API для разработки плагинов, весь исходный код у вас под рукой, и он минималистичный, это не миллионы строк, а всего несколько тысяч.
К моменту прошлогоднего релиза прошел ровно год с момента релиза, оставались еще две принципиальные проблемы, которые не были решены.
Желаемой скорости рендеринга, то есть приемлемой, добиться не удалось, но хотелось еще большего FPS и не мог придумать, как попасть хотя бы в репозиторий Ubuntu. Поэтому Деодар пока остается проектом.
Недавно мне довелось переписать рендеринг и добиться желаемого показателя производительности.
Сейчас вся эта эпопея продолжается, потому что я сразу понял, что это ПРОЕКТ и он будет длиться годами и надо понимать, что каждый шаг включает в себя исследования с открытой датой.
Вообще уровень продукта еще впереди, для меня это вопрос интерфейса, потому что как говорит наш Линус Торвальдс, если в твоей программе есть фича, но ее нет в интерфейсе, то НЕТ ФУНКЦИИ.
А в Деодаре до сих пор нет даже меню, калькулятора, редактора палитр, работы с архивами и так далее.
Кстати, работа с архивами вещь необходимая, просто в работе программиста она второстепенная, моей целью было создать не столько файловый менеджер как таковой, сколько рабочую среду программиста с файловым менеджером внутри.
Но это тоже необходимо для продукта.
Что ж, надеюсь, вам был интересен этот небольшой экскурс в философию программирования и небольшой пиар моего проекта.
Ко мне неоднократно обращались в комментариях с жалобой, что в серии «Философия программирования» уже есть статья, но о программировании собственно пока ничего нет. Моя цель — писать именно о программировании, разбираясь в этом явлении комплексно, а не только чисто технически.
Ведь большинство текстов о программировании крайне односторонние, из серии «Я установил новую версию X, подскажу, какие ошибки мне пришлось допустить».
Опять же, я не оцениваю, что хорошо, а что плохо; такие тексты хороши сами по себе и решают свои проблемы.
Но нам нужно вникать в более сложные вопросы, развивать язык, вводить новые понятия, расширять существующие.
Сегодня я попытался взять, казалось бы, избитые понятия «Проект» и «Продукт» и публично обсудить, чем они отличаются.
Ведь то, что происходит в голове программиста, нуждается в умении это выразить, а мы все равно просто показываем пальцем на экран и бормочим: «Ну, ты не понимаешь» или «посмотри на код», «Ну , что ты можешь сделать, если люди не знают какЭ» Программа.
Может быть, могут, просто вы не знаете, как объяснить, что вы думаете об этом куске кода? Это вопрос развития языка.
Возьмем в качестве примера замыкания, потому что в языках программирования нет такого ключевого слова, но есть замыкание! То есть понятие внедряется исключительно гуманитарным путем, в головы программистов, мол, посмотрите, вот как можно написать и получится «замыкание», можно сделать и это.
что с ним потом развивается концепция, добавляются дочерние понятия и расширяется набор ассоциаций.
В общем, мы будем работать и двигаться в выбранном направлении.
Я очень надеюсь, что если мы будем двигаться целенаправленно, то рано или поздно у нас получится.
найти правильный тон обсуждения темы и значительно обогатить наше понимание профессии И огромное спасибо всем, кто принимает участие в комментариях, даже тем, кто меня минусует, критикует, и особенно тем, кто читает и ждет продолжения.
! Философия программирования 6: Продукт и проект 5: Реактос и Колибри 4: Технология Шапито 3: Чичиков и программка 2: Миф и язык 1: Трехстороннее программирование Теги: #философия программирования #программирование
-
Развлечения По Коммутируемому Доступу
19 Oct, 24 -
Netapp Ontap И Vmware Vvol
19 Oct, 24 -
Ember.js — Прощай, Mvc (Часть 1)
19 Oct, 24 -
Ключ К Информационной Революции
19 Oct, 24 -
Решение Проблемы Тысячи
19 Oct, 24
