Можно ли написать код программы с первого раза и всё будет работать? Нереально, скажете вы.
Но вот подумайте, если взять инженеров в космической сфере – им приходится делать ракеты такими безопасными, чтобы люди полетели и снова вернулись. И их продукт «ракета» должен быть сделан с первого раза правильно.
Тут будем говорить о точности проектирования. Как добиться высокой точности?
Ключевых тренда два:
- чаще проверять модель инкремента. Небольшие куски кода легче перепроверить, исправить. Не стоит ждать пока будет написана целый модуль или вся программа.
- поменьше людей в кодировании, в сборке готового продукта. Да-да именно так. Люди вносят ошибки.
Многочисленность проверок начинается с того, что разработчик не принимает решения лично. Так же, как архитектура может быть представлена как набор архитектурных решений, так и проект системы (design в классической инженерии, или в программировании исходный код, в инженерии предприятия это могут быть скрипты маршрутизации работ, и т.д.) может быть представлен как набор решений разработчика.
Принцип такой: чужие глаза проверяют инкремент прямо в ходе написания, а не после, когда принято множество попутных решений. За моделер сажают сразу двух разработчиков. Эта практика стала известна под названием pair programming, она пришла из подхода eXtreme programming как результат идеи «если что-то хорошо, то мы доводим это до экстремума».
Причем это не то, что эксперт и программист сидят за одним компьютером, а именно два разработчика: один проверяет другого, даёт советы по альтернативным решениям (например, предлагает альтернативные концепции системы или помогает пройти развилку в уже имеющихся альтернативах, напоминает о каких-то ограничениях в части интересов внешних проектных ролей и т.д.). Такое парное программирование на практике не принесло падение производительности вдвое – даже проводились специальные эксперименты по этому поводу.
Такое парное программирование одно время стали брать на себя моделеры – где то проверять орфографические и грамматические ошибки, где то предлагают дописывать слова. Проверяется даже синтаксис языка программирования.
Но дальше пришли системы искусственного интеллекта, которые так и получили имя «парный программист». К первым таким системам относятся GitHub Copilot и Amazon CodeWhisperer, которые встраиваются в программистские IDE как плагины. Можно ожидать, что аналогичные плагины «парных программистов» появятся и в CAD «железных инженеров».
А что можно ждать дальше? Ещё меньше человеческих рук на пути от идеи к детальной модели, готовой к изготовлению или приложению, программе, работающей и удовлетворяющей пользователей.
Речь не о том, что программистов заменят, а о том, что стоит думать в сторону ускорения, улучшения своей работы с помощью искусственного интеллекта. Глядишь, и код с первого раза можно будет написать!