Такое можно услышать от многих молодых и взрослых людей. Однако после недолгого гугления выясняется, что понятие «программист» такое же огромное как «доктор». Все сразу и одновременно охватить невозможно, поэтому давайте разберемся в основных направлениях по которым можно развиваться.
Если говорить в-кратце, то программирование это написание программ (ваш кэп). Эти программы нужны для того, чтобы автоматизировать какую-либо деятельность или для развлечения. Например, программы управления станками на заводе, автопилот в самолете, браузер в интернете, операционная система, программы управления бухгалтерией, программы для создания 3D моделей, игры, видео, проведение научных экспериментов, распространение информации… В общем, практически во всех видах деятельности человека присутствует программирование.
Правильнее говорить разработка программного обеспечения (ПО). Я, например, занимаюсь разработкой ПО для автоматизации инженерных и производственных процессов. Все, чем вы пользуетесь, скорее всего было создано на какой-либо фабрике или заводе. Изделия могут быть совершенно разными: смартфон, автомобиль, шампунь, пакетик чипсов, самолет, куртка, велосипед, телевизор и т.д. Практически все изделия производятся массово, хотя возможны некоторые изменения под конкретных людей или некоторые требования.
Так устроена производственная компания
Например, чтобы создать автомобиль, для начала надо придумать концепт и желательно показать его работоспособность и преимущества перед уже существующими аналогами (Research, Proof of Concept). Дальше этот концепт начинают прорабатывать, если изделие состоит из множества сложных компонентов, то разрабатываются технических требования на эти компоненты (Requirement Decomposition), в сложных система используется системное моделирование (Systems Modeling). Далее начинается процесс проектирования: создаются 3D модели на компьютере (Computer Aided Design); эти модели рассчитывают на различные характеристики (Computer Aided Engineering), чтобы изделие и его компоненты не сломались при первом же использовании (а сломались ровно после гарантийного срока и не позже :)), и, наконец, создаются технологические процессы для производства всего этого (Computer Aided Manufacturing), чтобы потом произвести на заводах и собрать (Planning and Execution). Как известно, в автомобиле есть огромное количество различных компонентов (деталей). И на каждую деталь существует документация: виртуальные модели, расчеты, производственные процессы. А еще надо не забывать, что не все получается с первого раза, и в процессе проектирования возникают корректировки, новые решения (Revision Management). В этих процессах участвуют огромное количество людей. И всеми этими данными, процессами и людьми надо управлять, и все это надо хранить. Для этого существуют системы управления данными (Product Data Management), системы планирования производства и системы управления производством (Manufacturing Execution System). А все вместе это называется управление жизненным циклом изделия (Product Lifecycle Management). И это я еще не касался управлением самой компанией, бизнесом, бухгалтерией, поставками и продажами клиентам (Enterprise Resource Planning).
А как же компании, которые занимаются разработкой ПО, ведь у них продукт — это ПО? Да, и для этого есть свой мир управления жизненным циклом приложений (Application Lifecycle Management, ALM). Здесь применение средств автоматизации процессов еще более необходимо, так как наплодить кучу файлов куда проще чем кучу бумаги. Про ALM многие знают, и, чтобы не раздувать статью, я отправлю вас по ссылке за знаниями.
Application lifecycle
Ну, так вот, о чем это я. Ах да, разработка ПО. Как видно, систем много, и они, мягко говоря, не особо понятны. Но без них вы бы вряд ли сейчас вообще читали эту статью, так как читать ее было бы не с чего.
Итак ПО — это целая система, которая состоит из отдельных модулей, которые отвечают за разные функции системы.
Для того, чтобы создать ПО, надо вначале понять, что вообще должно делать это ваше ПО. Практически все программы состоят из различных модулей, которые отвечают за те или иные функции системы. Например, на любимом вашем смартфоне есть модуль для вывода картинки на экран, есть модуль для пересылки файлов, для передачи и получения данных по интернету, для распараллеливания задач и о-о-чень много чего еще.
Понять, как различные компоненты должны взаимодействовать, — это важнейшая задача, и она называется проектирование архитектуры ПО. Это самое главное! Причем архитектура есть как у всей системы, так и у отдельной маленькой программы. Например, какой вид обхода графа вы создадите и как будете обрабатывать информацию его узлов (последовательная обработка на лету, раскидывание по потокам, колбэк функции и т.д.). Любой разработчик ПО обязан это понимать. Если он это не понимает, то он еще не разработчик ПО.
Но и это еще не все. Как можно понять, какая архитектура будет лучше, если не понимаешь, какие задачи должно решать это ПО? Например, создание 3D моделей состоит не просто в создании точек, линий и поверхностей. Все эти объекты должны быть связаны между собой. Даже простейший кубик: если я изменю координаты одной точки, то должны измениться также связанные с ней кривые и поверхности. Если для создания скругления между двумя поверхностями пользователь должен вырисовывать каждую поверхность скругления вручную, то он просто ахренеет и пошлет все это дело. Он хочет просто выделить поверхности, между которыми надо сделать скругление и задать радиус (в простейшем случае). Также пользователь хочет иметь возможность изменять значения радиуса в будущем, чтобы при этом не разрушались ассоциативные связи в моделе.
Note: В компьютерной графике можно выделить 3 основных вида моделей геометрии: полигональная модель, математическая модель и параметрическая модель. Чтобы было понятно я приведу примеры, как выглядит модель, состоящая из нескольких поверхностей:
- Полигональная модель (STL, OBJ) — это просто координаты точек (с полигонами (треугольниками), построенными по этим точкам), по информации этой модели невозможно понять (без дополнительных данных), какая точка принадлежит какой поверхности;
- Математическая модель (STEP, IGES) — здесь ребра и поверхности заданы математическими формулами, но все они не связаны между собой, то есть, изменив один объект — другие не изменятся;
- Параметрическая модель (NX, CATIA) — здесь используется математическая модель + подходы, которые позволяют связать разные математические объекты, то есть изменив один объект — другие, если их это коснется, также изменятся
Все это требует от разработчика ПО знание области, которую он автоматизирует. В случае с созданием 3D моделей для инженеров — он должен понимать принципы проектирования (mechanical engineering) и производства (manufacturing engineering). То есть он должен думать и как инженер и как разработчик ПО.
А не дохрена ли навесили на разработчика ПО? — спросите вы. Действительно, не мало. Однако есть и приятные моменты — фреймворки. Это такие, уже запрограммированные шаблоны архитектур, абстрактные реализации. Не стоит путать их с библиотеками. Библиотеки — это наборы не связанных или мало связанных между собой функций или объектов. Например: библиотека для работы с матричным представлением данных в python — NumPy; фреймворка OpenCASCADE — для параметрического 3D моделирования.
И тут мы подходим к двум важным понятиям: разработчик ПО и программист. В русском языке нет устоявшейся разницы между этими понятиями. В цивилизованном же мире она давно известна: разработчик ПО — Software Engineer, программист — Software Developer.
Если в кратце, то Software Engineer — это тот, кто придумывает, как должно работать ПО в целом, как оно решает поставленные проблемы, продумывает архитектуру на верхнем уровне и создает задачи по реализации компонентов для Software Developer'ов, а в определенных случаях сам же их и реализовывает. Также существуют другие роли: project manager, team lead, software architect, database administrator, devops, qa engineer, reliability engineer и можно напридумывать еще много кого. Основная причина разделения — это большой объем работ по конкретным задачам. Например, если есть несколько баз данных, и их надо администрировать и следить за их безотказностью, или компания разрабатывает и поддерживает несколько версий продукта, который состоит из нескольких больших модулей (разработка операционной системы, системы автоматизированного проектирования о которых я писал выше и т.п.).
Казалось бы, что Software Engineer на много круче, но это не правильно вот так вот разделять. Да, у него больше знаний из различных дисциплин и больше ответственности. Задача Software Developer'а написать быстро работающий код, отладить его, покрыть его тестами и уложиться в сроки. Я бы сравнил это с управленцами и исполнителями — и те и те не могут существовать по одиночке.
В заключении хочу отметить, что основная проблема в автоматизации — это человек. Человеку свойственно совершать ошибки, у него бывает разное настроение, разные физические и умственные возможности, разный менталитет. Это главная причина по которой в бизнесс процессах происходят сбои и задержки. Однако, существуют фундаментальные ограничения из-за которых невозможно создать полностью автоматизированный процесс разработки изделий. Например постановки задачи оптимизации или упрощение 3D модели для гидрогазодинамического конечно-объемного расчета. А связано это с фундаментальными проблемами алгоритмов, которые невозможно распараллелить, либо вообще алгоритмы, которые невозможно завершить в общем случае за полиноменальное время (NP-класс). И я не говорю к сожалению это или к счастью, потому что если искусственный интеллект сможет создавать себе подобные машины будет совсем другое время. Но это уже рассуждения для другой статьи..
