В сентябре 2018 Никита Прокопов, рассказал почему считает, что с современным ПО всё плохо (и не останавливается 2). Никита констатирует текущее положение дел, описывает неприятные ситуации диких программ (видео).
К моему сожалению в повестке сообщества разработчиков нет намерения это исправить, и обсуждения как это сделать, а хочется чтобы было! Последнее из того что как-то конкретно касалось этой темы было опубликовано 11 июля, 2016.
Уже несколько лет сложно заговорить о сегоднящних (и завтрашних) проблемах близкого мне фронтенда, без того чтобы в качестве решения не возник React, GraphQl. (Да, Андрей Ситник верно отмечает, что во фронтенде застой)
Давайте, отвлечемся от текущих проблем, и рассмотрим перспективу разработки ПО (глобального) лет так на 10-30. Предлагаю ниже пофантазировать о том
-
какими хотелось бы видить программы с точки зрения
- пользователя
- разработчика
-
как этого достичь
Ниже я изложил максимум желаний и идей из идеального далекого будущего. Да, сложно представить чтобы все они исполнились, так же как и способ их достижения.
- были безопасными
- программа не могла в принципе прочитать то, к чему не было предоставлено ей доступа, если программа не работает без к определенным данным, то ей легко было подсунуть поддельные
- программа не может просто так передать данные куда-либо, если доступ к данным был предоставлен, а доступ на передачу - нет
- не требовала бы доверия к себе, её создателю, удостоверяющему центру, т.е. её можно было бы запустить без риска получения проблем без посредников
- не требовали установки
- могли встраивать документы друг друга
- без труда комбинировались друг с другом самими пользователями, интегрировались друг с другом программистами
- обновлялись на лету без перезагрузки и без потери состояния
- позволяли изменять себя на лету
- позволяли заменять себя на альтернативные, аналогичные, и делать это на лету. позволяли себя откатывать на предыдущие версии
- РАБОТАЛИ БЫСТРО. Быстро работали. А также работали всё быстрей и быстрей со временем без вмешательства их непосредственных создателей.
- не занимали много места
- быстро получали и передавали данные. если у соседа скачан фильм, то его не нужно скачивать с сервера. если кто-то поблизости уже скачал новости, то мне не нужно обращаться за ними в интернет (особенно если он для меня дорогой или медленный - я в африке, монголии, тибете)
- скачивали и отображали данные новых форматов на лету (если не экономлю трафик) - тоже быстро
- работали бы примерно одинаково с точки зрения интерфейса, возможностей, навигации и модели данных на любых устройствах
- имели встроенную историю и разрешали конфликты
- позволяли вести совсестную работу над любыми документами
- синхронизировали бы мои данные между устройствами как боги
- работали офлайн, не требовали интернет когда он не требуется
- чтобы когда я что-то делаю на мобильном можно было подключить мощь домашнего десктопного компьютера, простаивающего без дела, и его канал передачи данных
- А умные часы на лету могли бы передать отвественность за ещё больше вычислений как на телефон, так и на ноутбук
- чтобы без проблем можно было за деньги получить вычислетельные мощности (если у меня нет домашнего компьютера) и никто не получил бы доступ к моим данным
- Могли бы использовать разные стратегии использования ресурсов, например
- у меня сейчас есть интернет, а скоро его совсем не будет, тогда разумно скачать сейчас все что только можно, никуда не распаковывая, не устанавливая - т.е. запастись материалом, который будет обрабатываться потом
- у меня телефон использует домашний компьютер, а потом не будет, и не будет интернета
-
приложение как отдельное окно со своим набором состояний, экранов прекратили бы существовать
-
имели сквозную, последовательную навигацию
- не требовали установки и настройки всякого разного
- не требовали ожидания для просмотра вносимых изменений
- не требовали бы доп. усилий на реализацию штук из списка сверху. Например
- синхронизации данных и разрешение конфликтов
- получения данных для программы не только с http
- встраивания сторонних программ в свою
- реализацию разных стратегий для использования ресурсов
- показывали все взаимосвязи моделей данных
- показывали какие зависимые связи ломаются при внесении изменений
- позволяли состредоточится на бизнес логике, на моделях и не думать о производительности
- позволяли трать меньше усилий на написание приложений - поддержание корректного состояния приложения, взаимодействия состояния с внешними вещами, отображение его для пользователя
Огромный список проблем и желаний. Если вы задумывались об этих проблемах, то вряд ли скажете что эти проблемы можно решить для всех и сразу. Наверно не хватает чего-то , про то чтобы данные не исчезали, а личные сообщения безопасно и мгновенно передавались.
Думаю, что этого будущего не достичь, если решать эти проблемы по одной. Т.е. без комплексного подхода не обойтись. «Unix way» (одна проблема - одно решение) не подходит (по крайне мере если каждое мини решение не будет согласовано со всеми другими мини решениями).
Комплексный подход легко обесценить, если забыть о цели, если цели вообще не стоит, он будет казаться излишним. «Зачем что-то изобретать, если для X есть Y?» «О чем беспокоиться, если у нас есть дешевый уголь и нефть?» Алан Кей: «Будущее нельзя построить постепенно»
Большинство текущий решений для сегодняшних и завтрашних проблем выглядит примерно, как использование угля вместо древесины, именно по той причине, что в них нет видения, задачи попасть в будущее.
Первое - необходимо понять есть ли желание, задача попасть в будущее; определиться с тем, чего хочется. Второе - использовать инструменты которые идут в будущее вместе с нами, осведомлены о нем, могут рассказать о нем другим и последовательно придерживаются этого пути в своих решениях. Это важная часть. Это критерии для выбора библиотек и способ запустить новый цикл инноваций во фронтенде (об этом в Андрей Ситник говорит своем докладе и также предлагает критерии). Это способ получить что-то дейсвительное новое.
Приняв задачу попасть в будущее и новые критерии можно иначе смотреть на инструменты, которые решают текущие проблемы. Приближают ли они будущее быстрей будучи популярными? Можно ли несколько уступить в качестве текущего решения, сейчас, чтобы приблизить будущее (и позже наверстать упущенное)? Можно ли позволить себе сделать паузу и заточить тупой топор, чтобы он таки начал рубить? React - это вперед или вбок?
Ниже, исходя из своего опыта, я с более прикладной стороны описал что можно было бы сделать для достижения будущего:
-
разделить описание взаимосвязей и код, поддерживаюего актуальное состояние приложения
-
разделить состояние от взаимодействий с сайд эффектами
-
разделить состояние на мельчайшие смысловые единицы
- для эффективной инкрементальной передачи данных
- кеширования
- разрешения конфликтов
- чтобы проще было совершать миграции/обновления
-
описывать взаимосвязи между единицами так что бы их можно было анализировать без запуска приложения
-
чтобы было при вычислении единицы необходимой "единицы" было понятно
- какие связанные единицы нужно вычислить
- какие данные данные запросить
-
чтобы было понятно к каким серверам и сетевым ресурсам будет обращаться приложение
-
какие данные пользователя буду прочитаны
-
какие данные пользователя будут переданны
-
к каким файлам приложение будет обращаться на чтение, на запись
-
- подробно описывает взаимосвязи структуры данных в приложении, а также как эти данные получить
-
выполняет эти описания.
-
анализирует и понимает как привести приложение в необходимое состояние
-
анализирует как используются данные и безопасно ли это
-
осуществляет все необходимые оптимизации производительности
- кеширование
- индексирование
- параллелизм
- автоматический выбора SOA/AOS
- и т.д.
-
может улучшаться в не зависимости от программиста, улучшать производительность приложений. может гарантировать безопасные миграции
-
может гарантировать синхронизацию, разрешение конфликтов и т.д.
-
реализовать эффективное сетевое взаимодействие, различные стратегии использования ресурсов и т.д.
P.S. с 2009 года я разрабатываю музыкальное приложение seesu.me (уже почти нет). (Вот для сравнения года выхода популярных в разное время фрейморков: backbone - 2010, angular - 2010, emberjs - 2011, react - 2013)
Помимо самого приложения я последовательно и методично развиваю подход и способ описания взаимосвязей для разработчиков (1, видео 2015), которые пригодны для
- полноценного анализа без выполнения
- производительного выполнения системой
А также разрабатываю систему, выполняющую эти описания.