Мы часто читаем о бэст практикс в программировании, о новых функциях фреймворков или о том, что нового в очередной версии PHP. Читаем, как поменять «то на это», почему какая-то техника хороша или плоха, или какой новый пакет вы можете использовать в своём проекте. Но всё это — рассуждения только о прошлом или настоящем.
Сейчас я заканчиваю чтение книги «The Inevitable», написанной основателем журнала Wired, речь в которой исключительно про будущее. Вдохновившись этой книгой, предлагаю посмотреть на будущее программирования.
Сегодня мы боремся с техническим долгом (что бы это ни означало), с устаревшим кодом, который сложно поддерживать и дорого изменять, но, в то же время, он генерирует много денег. На регулярной основе мы должны рефакторить код, следовать принципам DDD, писать тесты, обновлять в целях безопасности версию PHP, устанавливать свежие версии ПО на сервер и автоматизировать выкладку.
Так много текущей рутинной работы, что совершенно нет времени посмотреть на десятки других проектов, которые поддерживает наша компания… или, по крайней мере, хранит где-то на наших серверах. Нам стоило бы нанять эксперта, который поможет хотя бы немного улучшить каждый аспект. Не потому, что эти проекты плохие, а просто потому, что существует очень много технологий, которые мы можем использовать, и ещё больше кода, который мы должны просто поддерживать.
А как это всё будет происходить в будущем?
IDE будет использовать искусственный интеллект
В будущем набирать код станет проще. Наша IDE будет работать на основе искусственного интеллекта, который учится на анонимных данных других PHP-проектов и на всех проектах с открытым исходным кодом на Github и Gitlab.
Благодаря этому ИИ, когда мы начнём набирать «class HomepageC ...», IDE будет знать, что мы создаём контроллер домашней страницы, что мы используем Symfony, а также его версию из composer.json, и предложит автоматически дополнить оставшуюся часть кода модификаторами финализации и строгими типами, основываясь на знании используемой версии PHP, тоже из composer.json. Он сгенерирует шаблон для шаблонизатора, который мы используем, и будет имитировать содержимое, найденное в других шаблонах, которые уже есть в нашем проекте.
Благодаря огромному количеству анонимных данных и данных из публичных хранилищ кода, ИИ будет знать как лучше протестировать контроллер и будет использовать эти знания для создания оптимального теста контроллера.
Best Verified Practice
Когда мы говорим про «бэст практикс», то не имеем в виду то, что я или кто-то другой написал в посте или книге, основываясь исключительно на личном опыте. Эти мнения часто основаны на опыте, полученном всего лишь в нескольких проектах, и эмоционально окрашены.
В будущем понятие «бэст практикс» сменится на «верифайд практикс» и будет основано на реальных данных, связанных с двумя жёсткими показателями — техническим долгом и эффективностью написания кода. У технического долга будет финансовый эквивалент, который покажет, сколько будет стоить поддержка каждой строки кода в будущем. Вы свободно пишете статический код без типизированных классов? Строка может «стоить» $10. Вы пишете финальные классы со строгими типами и одним публичным методом? В таком случае, строка обойдётся в $2.
Эти цифры не будут случайными, а будут основаны на постоянном анализе колоссального объёма больших данных, анонимных для всех проектов, которые захотят использовать эту функцию. Код будет сравниваться с денежными затратами, которые были необходимы для поддержания и улучшения проектов. Благодаря этой обратной связи ИИ также будет знать, какая версия выгоднее для вашего конкретного проекта.
ИИ будет знать о контексте вашего проекта и сравнит данные соответствующим образом. У вас CLI проект? Он будет сравниваться с кодом других CLI проектов в этой предметной области. Вы делаете сайт? Он будет сравниваться с проектами других сайтов.
Эффективность написания кода будет определяться метрикой «ремонтопригодности» проекта. Она будет измеряться шкалой от 0 до 100 баллов, где 0 баллов означает, что понимание кода занимает много часов, а чтобы внести изменения могут потребоваться дни или даже недели. Код с оценкой 100 будет легко понять джуниор разработчику, и он или она сможет изменить код практически мгновенно.
IDE верифицированное автодополнение
IDE будет знать об этих показателях, а также будет следовать шаблонам, используемым в вашем коде. Когда вы начинаете писать кусок кода, чья эффективность равно 40-50 баллов, всплывёт автодополнение с предложением кода с тем же функционалом, но с эффективностью уже 80-90. Это похоже на ту работу, которую Rector или PHPStan выполняют сегодня.
Анализ производительности также будет выполняться наряду с анализом эффективности кодирования. Производительность будет автоматически измеряться при каждом изменении кода в фоновом режиме в контейнере Docker, а вы будете проинформированы о любых утечках памяти или росте времени исполнения. Этот анализ будет настолько точным, что пометит определённую строку или символы, вызвавшие утечку, и предложит исправление, которое вам останется только принять.
AST рефакторинг
Рефакторинг тоже будет более мощным, чем сегодня. Он будет основан на абстрактном синтаксическом дереве (ASТ). IDE предложит лучший вариант рефакторинга, который вы планируете сделать сейчас, на основе анонимных данных из всех открытых и закрытых проектов.
Вместо того, чтобы ссылаться на «бэст практикс», вы будете знать, что:
- решение А обойдётся вам в $3 за строку в рамках технического долга, и будет иметь рейтинг 95 баллов по эффективности и 45 баллов по производительности
- решение B обойдётся вам в $1 за строку в рамках технического долга, рейтинг эффективности составит 70 баллов, а производительности — 50 баллов
Вы строите стартап и хотите проверить свою идею? Тогда вы выберете вариант A. А если ваша компания является стабильной и она должна оставаться таковой в будущем? Тогда стоит перейти на более дешёвый в поддержке и производительности, но чуть более медленный в развитии вариант Б.
Вам не придётся спорить с коллегой или с вашим боссом, почему вы должны использовать то или иное решение. Вы сравниваете цифры, а затем решаете, основываясь на ваших приоритетах на данный момент.
Контекстная архитектура
Ваш код будет иметь контекстную архитектуру. ИИ будет знать, когда лучше переходить между контекстами, основываясь на данных из других проектов и окончательной стоимости миграции в них. Вы начинаете делать проект на WordPress? Это ок. Но что если ваш проект станет более популярным, и вам потребуется перейти на какой-то фреймворк PHP, который будет лучше удовлетворять ваши потребности? IDE предложит вам перейти на Laravel. Один клик и всё готово.
Три года спустя ваш проект разрастается, и у вас появится много задач по интеграции сторонних сервисов, которые уже встроены в инфраструктуру Symfony. IDE предложит вам мигрировать… нажимаете… и бум, вы на Symfony 9. Вы обнаружили, что на рынке недостаточно Symfony разработчиков, которые могли бы справиться с разработкой вашего проекта? Один щелчок и IDE переведёт проект на фреймворк, для которого достаточно разработчиков по разумной цене.
Версионированные ответы StackOverflow
IDE будет сканировать ваш код и анализировать ваши привычки кодирования. Обычно Вы пишете функцию за 15 минут, но сейчас это занимает уже почти 2 часа? В последующие годы IDE будет настолько хороша, что заметит даже небольшое снижение скорости написания кода за считанные секунды.
Затем IDE проверит ваш код, отсканирует ответы на StackOverflow, сопоставит ответы с версиями в вашем composer.lock, и предложит использовать конкретный фрагмент кода как наиболее подходящий.
Вы волнуетесь, что этот фрагмент кода просто скопирован случайным образом и сломает ваш проект? Рейтинг ответов больше не основан на голосовании пользователей, а теперь учитывает процент использования ответа в случае его успешного интегрирования в код проекта.
Протестированные фрагменты кода
Кроме того, фрагменты кода ежедневно тестируются самим StackOverflow, а также перед копированием в ваш проект. Именно с версией вашей локальной среды, так что вы можете быть уверены в том, что код будет работать. Люди сами уже не пишут версии этих ответов, как это было в прошлом. Код в ответе обновляется автоматически при каждом релизе технологии или фреймворка, которые он использует. Какой-то ответ дан для Symfony 5. А что будет, когда выйдет Symfony 6? Старый код в ответе обновится с помощью рецепта AST, который был выпущен вместе с Symfony 6. Таким образом, человек и IDE смогут легко с ним работать.
Финансирование Open-Source, основанное на активности
Будет создан новый проект, который свяжет коммерческие компании и контрибьюторов открытого исходного кода. Проект с открытым исходным кодом будет финансироваться компаниями, его использующими. Разработчики, которые вносят свой вклад, будут финансироваться посредством единой системы, основанной на поступающих потоках денег, без дополнительных комиссий на покрытие издержек.
Размер финансирования будет определяться с помощью метрик, таких как: влияние функции, объём работы, затраченное время, эффективность кода и т.д. Таким образом, код будет разрабатываться гораздо более последовательно, чем когда разрабатывался независимыми контрибьюторами в их свободное время. Разработчик в проекте с открытым исходным кодом, по сути, получит работу на full-time, финансируемую этим проектом.
Что эти компании получат в награду? Продвижение в конкретном сообществе, предрелизные выпуски новых версий и прямой доступ к экспертам-консультантам, создавшим проекты с открытым исходным кодом, которые они (эти компании) используют.
Консолидация фреймворков
~10 фреймворков PHP, которые сейчас есть, будут консолидированы. Сообщества вокруг фреймворков PHP научатся больше сотрудничать, вместо того, чтобы разрабатывать почти идентичные копии фреймворков с MVC-подходом.
Благодаря AST-миграциям можно будет переключаться на любой PHP-фреймворк. Это позволит сузить выбор до 3-4 фреймворков. Если миграция между фреймворками — это вопрос 1 клика в вашей IDE, то больше не будет конкуренции, основанной на утверждении, что «так исторически сложилось», и привычках, а только на качестве.
Сокращение количества фреймворков приведёт к их большей узконаправленности — один фреймворк будет преуспевать в API, другой в CLI, третий в сайтах с прекрасным UX.
Когда всё сообщество PHP сосредоточится на меньшем количестве фреймворков, это позволит нам инвестировать сэкономленные усилия в разработку новых технологий и функций.
Только 1 стабильная версия PHP
Благодаря автоматическим AST-миграциям, будет только две версии PHP — stable и dev. Поскольку обновление любого пакета или проекта станет очень быстрым и дешёвым, не будет никаких причин не обновляться до последней версии. Возможно, PHP-сообществу потребуется год или два, чтобы принять это и синхронизировать все проекты. Но когда это произойдёт, то уже через месяц после выпуска новой версии PHP вся экосистема с открытым исходным кодом будет использовать её как минимальную версию.
Полностью автоматические и мгновенные обновления кода
Код PHP не нужно будет обновлять вручную. У каждой версии PHP будет полный «рецепт» обновления на основе AST, который можно будет использовать для автоматического обновления кода на своём проекте. GitHub будет обрабатывать эти «рецепты», поэтому, когда выйдет новая версия PHP, GitHub начнёт автоматически отправлять pull-запрос в ваш репозиторий. Автоматические обновления будут не только для PHP, но и для любого фреймворка или пакета. Как Dependabot, который недавно был интегрирован в GitHub, но теперь с обновлением кода и решением всех проблем обратной совместимости.
GitHub upgrader
Если вы не хотите принимать все PR самостоятельно, вы можете зарегистрироваться в программе автоматических обновлений, чтобы GitHub справлялся с этим за вас. Также он как следует будет обновлять релизы и их SemVer.
Автоматизированные SemVer
Не будет никаких споров относительно того, является ли изменение прерыванием обратной совместимости или только патчем. ИИ будет анализировать код до и после, и на основе этого будет принимать решения. Он будет настолько умён, что сможет определять, насколько существенное влияние оказывает то или иное изменение. Если это не повлияет на какой-либо код в других проектах, он будет выпущен как патч.
PHP RFC на основе накопленного опыта
Такой же анализ прерывания обратной совместимости будет возможен для любого RFC в коде ядра PHP. Хотите предложить типизированные константы? ИИ подскажет вам, сколько проектов из топ-10 000 на Github будет сломано в процентах. Нечто подобное сейчас делается вручную в некоторых RFC.
Переосмысление «прерывания обратной совместимости»
ИИ также поможет вам генерировать «рецепты» миграции AST, поэтому мгновенное обновление может полностью справиться с прерыванием обратной совместимости. Это приведёт к изменению самого понятия. Прерывания обратной совместимости будет происходить только тогда, когда не может произойти автоматическое обновление, а для изменения кода требуется человек.
Попробовать RFC локально
Кроме того, любой может попробовать функцию из RFC локально сразу после создания PR в GitHub. Как? Github автоматически создаст временную версию со специальным тегом dev и отправит эту версию PHP в реестр пакетов. Вы создаёте RFC на добавления типизированных констант, отправляете его как PR на GitHub и через 1 минуту можете запустить sudo apt-get install php-dev-typed-constant, чтобы получить PHP с этим RFC на свой локальный компьютер.
Таким образом, программисты смогут попробовать эту функцию ещё до включения в основную ветку и даже до голосования по RFC. В таком случае даже голосование по новым функциям будет основано на реальных данных и опыте, а не на эмоциях, субъективных мнениях и аргументах.
Что ждёт нас в будущем?
В будущем наши возможности не будут ограничены нашей историей, прошлым выбором или быстро развивающимися технологиями, из-за которых наш код быстро устаревает. Всего за один клик все наши инструменты станут самыми современными на рынке на сегодняшний день.
Это позволит нам больше экспериментировать, проверять наши предположения и получать реальную обратную связь. Это приведёт к ещё более совершенной автоматизации процессов кодирования и изобретениям в языке, паттернах и архитектуре приложения, которые сегодня мы даже не можем себе представить.
«Лучший способ предсказать будущее — это создать его».
Счастливого создания!
Автор: Oleg Zolotarev
