Мова програмування C# сьогодні лежить в основі величезної екосистеми .NET, корпоративних застосунків, ігор на Unity та хмарних сервісів. В інтерв’ю на каналі The Pragmatic Engineer творець C#, TypeScript, Turbo Pascal і Delphi Андерс Гейлсберг розповів, як саме організували роботу над дизайном C# — і чому для цього вистачило всього шести людей.
Команда з шести: чому «малий штаб» працює краще
На старті розробки C# не було великої армії інженерів. Замість цього зібрали невелику групу — приблизно шість–сім людей. Усі вони вже мали досвід створення або розробки мов програмування. Це означало:
- глибоке розуміння типових помилок у дизайні мов;
- знання перевірених рішень, які працюють у реальних проєктах;
- спільну професійну мову, що зменшує непорозуміння.
Такий формат дозволив уникнути класичної проблеми «дизайну комітетом», коли десятки учасників розтягують обговорення на роки. Натомість невелика команда могла швидко рухатися, зберігаючи цілісне бачення мови.
Робочий ритм: три зустрічі на тиждень по дві години
Процес був чітко структурований. Команда:
- збиралася в одній кімнаті;
- зустрічалася тричі на тиждень;
- працювала в сесіях по дві години.
Цей режим створював постійний, але керований темп. З одного боку, зустрічей достатньо, щоб не втрачати контекст і швидко розвивати ідеї. З іншого — двогодинні слоти не перетворювалися на виснажливі марафони, де продуктивність падає.
Такий підхід добре підходить для складних інженерних задач, де потрібні як глибокі обговорення, так і час на «переварювання» рішень між зустрічами.
Дизайн через критику: ідеї мають витримати «обстріл»
Ключовим принципом роботи була не генерація максимальної кількості ідей, а їх систематичне випробування. Механіка виглядала так:
- хтось пропонує нову ідею для мови;
- завдання решти — не підтримати її, а навпаки, спробувати «збити»;
- команда шукає, що не так: крайові кейси, складність для розробників, потенційні конфлікти з іншими можливостями мови.
Якщо ідея витримувала таку критику, її вважали «пристойною» — тобто достатньо сильною, щоб потрапити в дизайн.
Це створювало культуру, де:
- критика — не особиста атака, а частина процесу;
- мета — не «протиснути» свою пропозицію, а знайти рішення, яке працює в довгостроковій перспективі;
- якість важливіша за кількість фіч.
Для мов програмування, які живуть десятиліттями і підтримують мільйони рядків коду, такий підхід критично важливий: виправляти помилки дизайну заднім числом надзвичайно дорого.
Чому цей підхід досі актуальний
Історія створення C# показує, що:
- невелика, досвідчена команда може ефективно вирішувати задачі системного рівня;
- регулярний, але обмежений за часом ритм зустрічей допомагає тримати баланс між швидкістю та якістю рішень;
- свідома культура «агресивного рев’ю» ідей підвищує шанси створити продукт, який витримає випробування часом.
Ці принципи виходять далеко за межі мов програмування й можуть бути корисними для будь-яких складних технічних продуктів — від фреймворків до хмарних платформ.
Джерело
Anders Hejlsberg: C# was designed by 6 people — The Pragmatic Engineer