Командная разработка с ИИ. Часть 1 — диагностика проблем

Как вы развиваете свой ИИ пайплайн в команде? Например,кто-то настаивает на том, что спеку нужно делать не фэблом, а свармом из квенов. Как вы такие противоречия улаживаете?

Командная разработка с ИИ. Часть 1 — диагностика проблем

Не надо всё-таки говорить за всех: вкусовщина конкретного лида вполне может устраивать его команду, но из этого не следует, что она нравится программистам вообще :) Я могу понять стандарт предприятия для ОС, IDE и плагинов — максимум кому-то будет неудобно. Но AI унификация harness/model уже непосредственно влияет на результат и потому гораздо опаснее. Если всем навязать один harness, одну модель и общий набор скиллов, ты сильно ограничиваешь разработчиков в возможности экспериментировать с тем, как вообще решать задачи с помощью AI. А в настолько быстро меняющейся области зафиксировать один «правильный» способ работы сверху — по-моему, заведомо тупиковый путь.

Командная разработка с ИИ. Часть 1 — диагностика проблем

Табы или пробелы — это вообще не вопрос выбора IDE, а вопрос кодстайла. Чтобы гарантировать единый формат кода, совершенно не требуется заставлять всех пользоваться одной IDE с одинаковым конфигом.

Хочет один работать в VS Code, другой в IDE от JetBrains, третий в Visual Studio — какая мне разница, если на входе у них одна задача, а на выходе код соответствует одним требованиям и проходит одни проверки?

Если конкретная компания умеет закупить всем только одну IDE, но не умеет купить разные лицензии разным разработчикам — окей, это ограничение конкретной компании, но из него совершенно не следует, что одинаковая IDE — краеугольный камень профессиональной разработки.

И «код должен одинаково собираться» это был пример абсурдного обоснования требования одинаковых хоткеев/плагинов и прочего.

Командная разработка с ИИ. Часть 1 — диагностика проблем

Мне кажется, ты смешиваешь две совершенно разные вещи.

Унификация окружения, в котором код собирается, запускается и проверяется, — да, тут я вообще не спорю. Docker/VM/Nix, единые версии зависимостей, воспроизводимый CI — всё это как раз и нужно, чтобы не было «у меня работает, а на проде нет».

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

Командная разработка с ИИ. Часть 1 — диагностика проблем

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

Управление несколькими профилями Codex: небольшой CLI на bash

Для этого есть норм комбайны типа https://github.com/diegosouzapw/OmniRoute/ - там и статистика, и гибкие стратегии роутинга, да и не только для кодекса

Заметки по книге «Философия разработки ПО»

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

Atomic — свежий взгляд на разработку игр Unity и C#

Таким подходом можно, например, «превратить боевого персонажа в овцу», просто изменив набор его данных и логики без пересоздания объекта или сложных зависимостей.

Не выйдет.​ Придётся ещё вытащить CharacterViewInstaller и SheepViewInstaller (разумеется, это MonoBehaviour), дернуть Uninstall/Install и молиться, что view‑поведения овцы синхронизированы с логикой…​

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

И главное - на практике такая гибкость почти не нужна: боевой персонаж превращается в овцу заменой сущности, а не переконфигурацией.

Aspid.MVVM — производительный MVVM фреймворк для Unity

ну да, если хочется подписок на изменения, а не только при инициализации, то R3

[ViewModel]
public interface IMomentSpeakerViewModel : IDisposable
{
    ReadOnlyReactiveProperty<string> OutTextChangable {get;}
   IObservableCollection<IAnotherViewModel> AnotherViewModels {get;}
}

Aspid.MVVM — производительный MVVM фреймворк для Unity

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

[ViewModel]
public interface IMomentSpeakerViewModel : IDisposable
{
    string OutText {get;}
    string InputText {get; set;}
    void Say();
}

и полностью кодогенерился бы public class MomentSpeakerViewModelBinder_Generated, как дополнительная прослойка между вью и вьюмоделью

Следуй за белым кроликом: как устроена матрица компетенций в ЕВРАЗе

Очередная матрица компетенций - любимая игрушка менеджеров, когда надо ранжировать программистов, но нет желания или умения по-настоящему погружаться в работу команды. Поставил галочки в Excel, раскрасил ячейки - и вот уже "объективная оценка" готова.

В нормальной команде лид и так знает кто что умеет, потому что он видит людей в деле. А матрицы - это просто бюрократический косплей управления: выглядит серьёзно, а а в реальности корпоративный гороскоп, где вместо "Луна в Скорпионе" пишут "Java на среднем уровне".

Разбор интервью с автором TypeScript о портировании его на Go

Короче, чуваки, я тоже очень расстроился, что не портировали на C#, но немного поизучав вопрос понял, почему Go. Там в исходных кодах на TS дофига всяких self-referenced структур, типа:

interface TypeSymbol {
    name: string;
    flags: number;
    parent?: TypeSymbol;
}

которые в Go переходят в

type TypeSymbol struct {
    Name   string
    Flags  int
    Parent *TypeSymbol
}

И фишка в том, что в dotNet у этого нет аналога!
Можно, сделать класс, но это будет не то, потому что нам нужно последовательное хранение в памяти в массивах:

class TypeSymbol {
    public string Name;
    public int Flags;
    public TypeSymbol Parent; // такой код не скомпилируется для struct
}

Вариант делать через unsafe тоже не подходит, потому что в таком случае Parent не будет менеджериться сборщиком мусора, в отличии от TS и Go.

unsafe struct TypeSymbol
{
    // Фиксированный буфер для хранения имени (если хотим полностью unmanaged-структуру)
    public fixed char Name[128];  
    public int Flags;
    public TypeSymbol* Parent;     // нужно делать освобождение памяти самому Marshal.FreeHGlobal
}

Лучшим решением был бы ввод что-то типа NativePtr (в F# такое есть, но и там он не под GC), но я не знаю насколько это реалистично добавить в dotNet.

struct TypeSymbol {
    public string Name;
    public int Flags;
    public NativePtr<TypeSymbol > Parent; 
}

Жаль всё равно, что решили не тратить на это ресурсы, поддержка разрабам AOT не помешала бы, но технические проблемы тут действительно серьёзные, а не просто нежелание писать неидиоматический код на С#.

Pure.DI в Unity

ещё без Start (а с инстаншиэйтом только через фабрику) можно уйти от .Builder()

просто все монобехи у которых есть [Dependency] дописывать в switch. Хотя не очень понятно, что мешает и сейчас генерить BuildUp для них автоматически...

Pure.DI в Unity

с методом Start, который вызывает инициализацию класса, вы как-будто бы нарушаете свой принцип - отсутствие зависимости на фреймворк DI.

По-моему стрёмно, когда каждый монобех сам себя инициализирует - ваш Composition.Shared превращается в какой-то сервис локатор в таком случае. С инстаншиэйтом через фабрики (как сделано во всех di фреймворках на юнити) - можно перейти на pure.di просто изменив атрибут с [Inject] на [Dependency] и не нужно ничего дописывать (ну кроме фабрики).

Pure.DI в Unity

foreach (var innerMonoBeh in GetAllInnerMonobehs(go))
    {
        // вот тут бы тогда кодогенерить switch на все поддерживаемые монобехи,
        // для которых builder зарегистрирован 
       switch (innerMonoBeh)
        {
            case Clock clock:
                   BuildUp(clock);
                  break;
             default: break;
        }
 }

Pure.DI в Unity

и ещё лучше инжектить не через проперти, а через метод, типа

public class Clock : MonoBehaviour|
{
    private IClockService _clockService = null!;

    [Dependency]
    public void Inject(IClockService clockService)
    {
        _clockService = clockService;
    }
}

Pure.DI в Unity

Вот это:

void Start()
{
    // Injects dependencies
    Composition.Shared.BuildUp(this);
}

как будто бы не очень удобно - хочется чтобы был какой-то factory метод для инстаншиэйта, который бы инициализировал все монобэхи на префабе. типа _composition.Instantiate(prefab);

и внутри было что-то типа

public GameObject Instantiate(GameObject go)
{
    var result = GameObject.Instantiate(go);
    foreach (var innerMonoBeh in GetAllInnerMonobehs(go))
    {
        BuildUp(innerMonoBeh);
    }
    return result;
}

Как пройти собеседование на Unity-разработчика: мнение лида

Удивляют те, кто гордится, что в компании одни сеньоры. Ведь всю рутину джунов и мидлов им самим приходится делать.

Как не бояться разработки РПГ

а кого вы видите своими конкурентами? Можно какой-то список рефов/аналогов в вашем жанре глянуть?

Как не бояться разработки РПГ

Рекламу покупали/планируете закупать? Какой cpi и можно ссылку на креатив?