Командная разработка ПО.

[BDK]

ПО пишут коллективы. Но я всегда писал ПО в одиночку. Как результат - абсолютно другая конфигурация мозгов. Я не умею работать в команде, но я умею легко делать вещи которые при командной работе превращаются в дорогие и громоздкие проекты. У одиночной и командной работы есть свои плюсы и минусы. Было бы интересно обсудить эту тему. Для меня мир командной работы это интересная но совершенно не понятная экзотика, которую мне тем не менее хотелось бы изучить и понять.

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

[Андрей Карпишин]

upstairs

[BDK]

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

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

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

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

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

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

[BDK]

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

[BDK]

Андрей. Твоё мнение по теме?

[Андрей Карпишин]

BDK, если на Lazarus 4.0, я готов работать в команде. Если на других языках, ну нафиг. Я тоже ленивый.

[BDK]

Ну да знакомая тема. Ты тоже одиночка как и я. Правда я программирую на большом количестве языков. Но для себя выбрал один оптимальный для большинства нужд - C#.Если разработчики в команде пишут на разных языках - это реальное препятствие. Действительно сложно что-то затевать совместное если не использовать один язык и общие исходники. Мы попытались это сделать при помощи DLL но получилось плохо и трудно. Если разработчики не оперируют общим кодом то процесс усложняется многократно и затея превращается в неосуществимую.

Как же преодолеть этот барьер?

Есть мысли?
=====

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

То есть мой пайплайн такой - на C# я обычно пишу симуляцию будущего продукта а не сам продукт. А когда на симуляции отладил и отработал подходы то затем перевожу это на низкоуровневые. Например какие-то процессы вообще есть смысл перевести на GPU. Но писать сразу под GPU - ты закопаешься и с концами - уже не выкопаешься. А если алгоритмы сначала отлажены на медленной но надежной симуляции - вот после этого перевести их в привередливый но производительный код на низкоуровневом железе - это работает отлично. Я даже делаю автоматическую генерацию кода для GPU, то есть я вообще не касаюсь программирования GPU вручную.

И кажется вот - это может быть решением. Автоматическая генерация или конвертация кода с языка на язык.

[BDK]

Сейчас Phyton в мире на первом месте по популярности. На Python я тоже пишу. Он примерно схож с C# по удобству и скорости прототипирования. Наверное даже удобнее. Но он еще менее производительный и еще меньше подходит для конечного продукта. Ну такое мое мнение.
https://habr.com/ru/news/937856/

[BDK]

Вообще картина вырисовывается такая - вся трудность коммуникации между людьми - из-за использования разных языков. Но привести всех к одному языку - ошибочное решение потому что теряются сильные стороны разных типов мышления. Решением видится - использование автоперевода с языка на язык.

То есть можно сделать автоперевод C#-Lasarus туда и обратно и тогда мы могли бы одновременно работать в общем пространстве и при этом каждый в своём любимом без необходимости компромиссов. Но перевод должен быть полностью автоматически чтобы не терять время на ковыряния в этом процессе вручную иначе это будет убивать время. Переводиться должен весь проект целиком со всей структурой а не только отдельные исходники. И перевод должен быть 100% надежный всегда и во всех случаях. Без сбоев. Только тогда это может действительно работать на практике. То есть перевод туда-обратно вообще не должен порождать трат времени и труда на себя. Должен быть максимально незатратным. Перевод с помощью LLM не годится - будет давать кучу ошибок на исправление которых будем тратить больше времени чем на сам проект. Нужен специализированный инструмент.

[BDK]

И да, уточню - это обсуждение мнений. Речь не идёт о том чтобы на что-то подряжаться и что то реально затевать.

Самые мертворожденные проекты - это всегда начинающиеся из желания кому-то что-то доказать. Делать нужно только то в чем действительно есть необходимость. Желание кому-то что-то доказать ни разу не является реальной необходимостью. Везде где возникают такие гниловатые мотивации я сразу сбегаю как с Титаника который уже обречён даже если энтузиастам это ещё не очевидно.