Компьютерное программирование около 2016 г.
Я начал программировать еще в 1972 году. Я пережил несколько крупных изменений парадигмы в отрасли; эти изменения в основном повлияли на то, как программное обеспечение структурировано внутренне и разделено снаружи.
Еще в 70-х и 80-х годах большая часть программного обеспечения работала на мэйнфреймах. Мы начали писать монолитные приложения, которые работали независимо от всего остального. Если бы нам нужны были библиотеки, мы бы включили их в код, над которым работали.
Со временем общие библиотеки развивались; знание их и средства связи с этими библиотеками стали важным способом ускорения разработки. Произошло нечто, называемое революцией «структурного программирования», которая изменила нашу внутреннюю структуру, помогая улучшить не только дизайн и повторное использование, но и снизить затраты на обслуживание.
Мэйнфреймы привели к появлению миникомпьютеров, и малые предприятия теперь могли позволить себе иметь свои собственные системы.
Когда ПК стали преобладать, была принята та же модель, но программное обеспечение работало на настольном компьютере, а не на мэйнфреймах. ПК в конечном итоге привели к закату миникомпьютеров и большинства мейнфреймов.
Потом появился сеттинг. Поскольку дисковое хранилище было относительно дорогим, появились так называемые «серверы», на которые было установлено много дорогостоящих дисковых хранилищ, и приложения, работающие на рабочих станциях, должны были решать проблемы конфликтов на этих общих ресурсах. Это было рождением эры «клиент/сервер».
Затем компании начали создавать «умные серверы», в которых сервер баз данных заменил голые устройства хранения. Теперь клиентские приложения должны взаимодействовать с серверным приложением (например, MS SQL Server, Oracle), а не напрямую с файлами базы данных на сервере. Это уменьшило количество ошибок и позволило оптимизировать серверы для более быстрой обработки запросов. Аппаратное обеспечение было разработано специально для того, чтобы эти серверы обрабатывали как можно больше запросов в секунду, что является способом постоянного масштабирования потребностей на стороне клиента. (То есть всем в бухгалтерии потребуется доступ к данным, хранящимся на одном сервере. По мере того, как потребности компании росли и расширялись от одного офиса до нескольких по всему миру, эти централизованные серверы должны были иметь возможность обрабатывать все данные. нагрузка.)
Это было похоже на эру «клиент/сервер».
Затем компании перешли на так называемые «тонкие клиенты», которые по сути представляли собой рабочие станции без локальных жестких дисков. Это потребовало дальнейшего разделения интерфейса, с которым взаимодействовал пользователь, и сервера, содержащего «бизнес-логику».
Но по мере роста потребности в бизнес-логике становилось все труднее полагаться на один внутренний сервер для обработки всего. Таким образом, рабочая нагрузка должна быть распределена между несколькими компьютерами.
Это привело к эпохе «многоуровневых (или многоуровневых) решений». Теперь приложение могло быть реализовано как серия независимых приложений, разбросанных по сети на совершенно разных компьютерах, иногда с установленными частями, работающими параллельно. Часто разные части писались совершенно по разным технологиям. (например, серверные службы баз данных были сосредоточены на хранимых процессах; службы среднего уровня были написаны на Java, а внешние службы были написаны на любом количестве настольных платформ, таких как C#, C++ и Delphi/Object Pascal.)
Сейчас мы развиваемся до такой степени, что у нас есть набор полностью независимых сервисов, которые могут работать практически в любой точке мира, доступны через Интернет и могут быть включены в любое приложение, которое вы хотите создать. Они называются приложениями «Программное обеспечение как услуга (SaaS)».
«Приложения», используемые «потребителями», стали фрагментированными, поэтому они могут работать полностью на веб-сервере (как «веб-приложения»), почти полностью на стороне клиента в браузерах или как собственные приложения, работающие на (в основном мобильных) устройствах. — которые бывают трех доминирующих (и несовместимых) вкусов.
И вместо того, чтобы создавать автономные серверы с возрастающей сложностью и мощностью, мы полностью заменили потребность в выделенном оборудовании чем-то, называемым «облаком». Поэтому, если вам нужно удвоить численность вашей бухгалтерской команды, вам не нужно заменять сервер, на котором размещена ваша бухгалтерская база данных, на более мощную, мощную и быструю машину; вместо этого вам просто нужно включить (или развернуть) дополнительные узлы в облаке.
С появлением облака ресурсы внутренних серверов стали практически бесконечно расширяемыми и гибкими ресурсами, которые можно настроить по мере необходимости, чтобы добавить как пропускную способность обработки, так и хранилище одним нажатием кнопки.
Это стало эпохой «облачных вычислений».
И это неумолимо ведет к следующей эре, называемой «Интернетом вещей (IoT)», представленной миллиардами и миллиардами «умных устройств», в которые встроена какая-то логика, и все из которых имеют неотъемлемую способность соединяться с миром. широкий Интернет через (в основном беспроводные) соединения, готовые к доступу в любое время из любой точки мира.
Как насчет дизайна?
В этом эволюционном процессе термин «дизайн» был заимствован индустрией для обозначения «визуального дизайна». Я все еще пытаюсь выяснить, какой термин сейчас используется для обозначения «структурного дизайна», отражающего структуру приложений в целом. Кажется, что он был утерян, так как все было заменено «виджетами» — маленькими кусочками блоков функционального кода, которые можно добавлять и заменять более или менее по мере необходимости.
Сегодня «дизайнеры», как правило, являются художниками-графиками, которые используют набор инструментов, которые используются для создания причудливых визуальных пользовательских интерфейсов (UI), которые взаимодействуют с любыми доступными внутренними службами.
Если раньше действия на стороне клиента имели детализацию, отражающую настольные и клиент-серверные приложения, а именно с использованием подхода «страница за раз», то теперь дизайн пользовательского интерфейса стал в высшей степени интерактивным, поэтому при нажатии кнопки на экране (будь то настольное приложение или мобильное приложение), оно может запускать мгновенное обновление на экране, отправляя запрос внутреннему процессу, который запрашивает новые данные. Обновление всего экрана ушло в прошлое. Но в процессе изменился весь подход к структурному проектированию клиентского программного обеспечения.
Инструменты и технологии, используемые сегодня, полностью отличаются от тех, которые использовались всего несколько лет назад. Они развивались с невероятной скоростью, и в отличие от прошлого, когда несколько доминирующих игроков контролировали инструменты, используемые программистами, теперь они эффективно собираются разработчиками со всего мира. Они обновляются ежемесячно, а иногда и еженедельно, а не ежегодно. И если вы не в курсе всего 6 месяцев, ваши навыки могут стать практически устаревшими.
Он превратился в очень неузнаваемую экосистему по сравнению с прошлым.
Само программирование принципиально не изменилось. Но парадигмы, которые используют программисты, и инструменты, которые они используют, полностью изменились, и скорость изменений, которые мы наблюдаем, увеличивается с невероятной скоростью.
Будущее?
Я видел многочисленные оценки того, что к 2020 году в Америке и во всем мире возникнет значительная, если не массовая, нехватка программистов. к 2020 году будет нехватка программистов.
Лично я считаю, что индустрия разработки программного обеспечения должна сделать для себя то, что она уже сделала для преобразования производительности во многих других отраслях. А именно, ему нужно переключиться на парадигму программирования, основанную на визуальном дизайне, а не на переводе идей в текст, который анализируется и транслируется в базовый машинный код.
Изображение выше — это то, что я нашел на сайте Microsoft, и оно показывает их среду разработки Visual Programming Language (VPL). Это шаг в правильном направлении, но он ничего не изменит.
Архитекторы-строители и другие проектировщики механики, например, теперь используют инструменты, которые позволяют им выполнять 100% проектных работ в трехмерной визуальной среде. Они добавляют элементы в чертеж и задают различные свойства, а система достаточно умна, чтобы применять различные правила и определять различные факторы и предупреждать проектировщика обо всем, что кажется нарушением заданных правил.
Это можно сделать в программном обеспечении, но все, что у нас есть, — это инструменты для проектирования пользовательского интерфейса. Вся логика, стоящая за ними, написана в виде скриптов или какого-то скомпилированного языка программирования.
На мой взгляд, программирование сводится к двум вещам: (1) логика; и (2) сантехника. (Визуальный дизайн больше не является программированием как таковым.)
Нам нужны среды программирования, которые автоматизируют сантехнику, поскольку она, кажется, развивается с экспоненциальной скоростью. Все эти SaaS-сервисы должны быть каким-то образом подключены к внешнему визуальному дизайну; они составляют логику, а соединения — сантехнику. Все больше работы по программированию в наши дни, кажется, связано с простой настройкой этой сантехники. Это должно быть так же просто, как нарисовать линию от одного логического блока к другому, при этом все необходимые переводы и преобразования данных будут выполняться автоматически.
Как только мы перейдем к такой парадигме проектирования, нехватка программистов практически исчезнет. И необходимость научиться кодировать будет передана квалифицированным специалистам, которые создают специализированные и высокооптимизированные логические блоки, которые потребляются и используются средами визуального проектирования и их пользователями по всему миру.
