Программная инженерия или информационная безопасность что выбрать

Компьютерные науки или программная инженерия – что выбрать?

На кого учиться: изучать компьютерные науки или постигать навык софт-инженера – вопрос очень популярный. А что вы выберете?

Очень часто можно встретить размышления на тему выбора одного из перечисленных направлений: “Какая разница между вычислительной техникой и программной инженерией?” и “Должен ли я выбрать вычислительную технику или программную инженерию, если хочу стать софт-инженером?”.

В этой статье мы попытаемся понять и проанализировать важность и необходимость обучения этим специальностям.

Быстрый осмотр пациента

Компьютерные науки изучают, как устроен компьютер, как он работает, в основном с теоретической и математической стороны.

Вы должны выбрать это направление, если любите математику и логику или если хотите работать в сфере компьютерных наук, искусственного интеллекта, машинного обучения, безопасности, графики.
Программная инженерия изучает, как устроена операционные и программные системы, затрагивает управление проектами, обеспечение качества и тестирование.
Вы должны выбрать разработку программного обеспечения, если вас интересует практический подход, жизненный цикл и разработка/поддержка ПО.
Обе отрасли учат основам программирования и информатики, что полезно, если вы хотите стать программным разработчиком.

Чтобы понять разницу между специалистами в области вычислительной техники и программного обеспечения, давайте взглянем на их соответствующую учебную программу в Университете Ватерлоо в Канаде.

Какие перспективы?

Давайте сначала сравним виды рабочих мест и стажировок, которые вы можете пройти после каждой программы.

К счастью, на сайте университета Ватерлоо есть несколько примеров. По каждому из направлений предложены места работы после успешного завершения учебы:

Компьютерные науки:

Веб-разработчик / архитектор, The Steele Group
Программист, Harry Rosen Inc.
Мобильный / облачный разработчик, Clearbridge Associates Limited.
Разработка программного обеспечения, General Dynamics Canada.
Разработка программного обеспечения, Microsoft.

Agile Engineer, Pivotal Labs.
Бизнес-аналитик, Canadian Tire Corporation.
Менеджер по продуктам, Dropbox.

Программная инженерия:

Разработчик ПО, Tagged Inc.
Разработчик ПО, IBM Canada
Менеджер продукта, Arius Software Corporation.
Инженер по ПО, VistaPrint USA.
Инженер-программист, Harris Corporation.
Разработчик ПО, Accenture Inc.
Менеджер продукта/Разработка программного обеспечения, NexJ Systems Inc.
Консультант, PureFacts Financial Solutions.
Консультант по реализации, Desire2Learn.

Как вы можете видеть, нет особой разницы между рабочими местами, которые вы можете получить.

Наиболее распространенные предложения работы, на которые можно рассчитывать после получения степени «Компьютерные науки» или «Программная инженерия» – это разработчик программного обеспечения или инженер-программист. Существуют и другие варианты, такие как менеджер продукта, аналитик QA и консультант по технологиям, которые зависят от вашего набора навыков.

Обязательные темы первого года

Теперь давайте посмотрим на курсы каждой программы. Сначала сравним некоторые курсы, которые вам нужно будет посетить в первый год.

Компьютерные науки:

CS 135 – Разработка функциональных программ.
CS 136 – Разработка алгоритмов и абстракция данных.
MATH 135 – Алгебра.
MATH 136 – Линейная алгебра 1.
MATH 137 – Исчисление 1.
MATH 138 – Исчисление 2.
Плюс несколько факультативных.

Программная инженерия:

CS 137 – Принципы программирования.
CS 138 – Абстракция и реализация данных.
MATH 115 – Линейная алгебра для инженерии.
MATH 117 – Исчисление 1 для инженерии.
MATH 119 – Исчисление 2 для инженерии.
MATH 135 – Высшая математика.
ECE 105 – Физика электротехники 1.
ECE 106 – Электричество и магнетизм.
ECE 124 – Цифровые схемы и системы.
ECE 140 – Линейные цепи.

SE 101 – Методы разработки программного обеспечения.

Как вы видите, на первом курсе обе специальности очень похожи. Обе рассматривают основные знания по информатике, алгебре и исчислениям. Отличия в том, что на “Программной инженерии” есть дополнительно физика и электротехника, в то время, как у “Компьютерных наук” еще несколько факультативов.

Обязательные темы второго курса

Теперь рассмотрим предметы второго курса.

Компьютерные науки:

MATH 239 – Введение в комбинаторику.
STAT 230 – Теория вероятностей.
STAT 231 – Статистика.
CS 240 – Структуры данных и управление данными.
CS 241 – Основы последовательных программ.
CS 245 – Логика и вычисления.
CS 246 – Разработка объектно-ориентированного программного обеспечения.
CS 251 – Организация и дизайн компьютеров.
CS 341 – Алгоритмы.
CS 350 – Операционные системы.
Кроме того, некоторые факультативы по компьютерной науке.

Программная инженерия:

CHE 102 – Химия для инженеров.
ECE 222 – Digital Computers (включая язык ассемблера).
ECE 358 – Компьютерные сети.
MATH 213 – Высшая математика для инженеров-программистов.
MATH 239 – Введение в комбинаторику.
STAT 206 – Статистика для разработчиков программного обеспечения.
MSCI 261 – Инженерная экономика: финансовый менеджмент для инженеров.
CS 241 – Основы последовательных программ.
CS 240 – Структуры данных и управление данными.
CS 247 – Принципы разработки программного обеспечения.

CS 341 – Алгоритмы.
CS 349 – Пользовательские интерфейсы.
CS 343 – Параллельное программирование.
CS 348 – Введение в управление базой данных.
SE 212 – Логика и вычисления.
SE 350 – Операционные системы.
SE 465 – Тестирование программного обеспечения и обеспечение качества.
SE 464 – Разработка и дизайн программного обеспечения.
SE 463 – Спецификация и анализ требований к программному обеспечению.
SE 490 – Дизайн проекта.
Кроме того, несколько факультативов по информатике и электротехнике.

Когда дело доходит до математики и статистики, вычислительная техника и программная инженерия почти похожи. Они охватывают комбинаторику, теорию вероятностей и статистику.

Основные требования по обоим направлениям также схожи и рассматривают алгоритмы, структуры данных и операционные системы.

Рассмотрим ключевые различия:

Программная инженерия имеет больше требований в области электротехники и разработки ПО, таких как тестирование ПО, дизайн и спецификации программного обеспечения.
Вычислительная техника позволяет проводить обучение с более широким выбором курсов по информатике высокого уровня. Вы можете выбирать из множества тем, таких как безопасность, основы разработки программного обеспечения, компьютерное зрение, машинное обучение и управление базами данных.

И все-таки, что выбрать, чтобы быть инженером-программистом?

Исходя из набора предметов и курсов в этом университете следует, что лучшим выбором будет “Вычислительна техника”, если вы хотите стать инженером-программистом.

Для простоты предположим, что вы надеетесь получить одну из самых высокооплачиваемых работ (~ 100 000 долларов США в год) в качестве инженера-программиста в Северной Америке. Эти рабочие места обычно находятся в крупных компаниях-разработчиках программного обеспечения (например, Microsoft, Google, Amazon и т. д.). Или в компаниях среднего бизнеса с высокими темпами роста (Dropbox, Lyft, Snapchat, Pinterest и т. д.).

Как правило, они ищут в кандидате на программиста возможность писать хороший код и создавать интересные проекты, а также знание основ компьютерных наук, структур данных и алгоритмов.

Лучший способ активизировать этот набор навыков – быстро изучить основы и тратить свое время на решение проблем и написание кода.

Основываясь на учебной программе для софт-инженера и на занятости инженеров-программистов, это будет сложнее сделать на курсе “Программной инженерии”.

Еще одно преимущество “Вычислительной техники” в том, что она дает больше факультативов. Это здорово, потому что в зависимости от того, что востребовано на рынке труда, вы сможете корректировать свое обучение. Например, если разработка мобильных приложений востребована, вы можете начать изучать ее.

Несколько примечаний

Различные университеты имеют разные требования к данным специальностям. Эта статья должна быть хорошей отправной точкой, но вы все равно должны взглянуть на требования к программе в университете, в котором вы заинтересованы.
Некоторые университеты даже не имеют такого направления, как “Программная инженерия”. Например, Университет Британской Колумбии в Ванкувере может дать вам степень в вычислительной технике и компьютерной инженерии, но не в программной инженерии. Но у них есть концентрация программного обеспечения в рамках своей программы по вычислительной технике, а также в области компьютерной инженерии.

Если в университете, в котором вы заинтересованы, нет специальности программная инженерия, можно остановиться на вычислительной технике, если вы хотите стать разработчиком программного обеспечения. Вычислительная техника больше ориентирована на аппаратное обеспечение, чем на компьютерную науку или программное обеспечение, поэтому она меньше связана с работой типичного разработчика ПО. Перевод на русский осуществлен Библиотекой Программиста.

Оригинал

Другие материалы по теме:

Кто такой Software Engineer. Программная инженерия VS "просто" программирование

Предлагаем вашему вниманию адаптацию статьи Самира Буна (Samer Buna) о различиях между программной инженерией и программированием, или чем разработка концепции программного обеспечения отличается от «просто кодинга». Все программные инженеры могут кодить, но не все программисты способны разрабатывать концепции программного обеспечения. Некоторые люди не любят определение «Программный инженер» (он же инженер-программист, он же Software Engineer) из-за того, что чаще всего слово «инженер» мы используем, говоря о чём-то более физическом — строительстве, например. Наша статья, разумеется, не о самом термине. Если он вдруг вызывает у вас отторжение, его легко можно заменить на что-то связанное с креативностью. «Создатель ПО», «автор ПО» … да хоть «Творец ПО»!

Когда мы говорим о «программном инженере», мы подразумеваем человека, чьей основной задачей является не просто написание кода, но создание качественного приложения. И в этом он видит своё призвание, применяя в работе научный подход и статистические методы. Для него программирование — не просто способ заработка для прокорма.

Умение программировать автоматически не делает из человека программного инженера. Научиться кодить может любой, и это куда проще, чем кажется. Каждый может создать простую программу для собственного использования, но это не дает гарантий, что эта же программа подойдёт другим. Мой любимый пример такой: многие из нас поют в дУше, но, увы, далеко не всегда это исполнение достойно профессиональной сцены. Разумеется, за высокими музыкальными впечатлениями вы, скорее всего, обратитесь к профи. Вам нужны еще примеры?

Все мы учим математику и письмо в школе, но это не делает нас математиками и писателями.
Большинство из нас способны приготовить сносное, а порой — и очень вкусное блюдо, но не каждый рискнёт приготовить стол на 100 персон для званого ужина в посольстве. В этом случае мы нанимаем повара.
Готовы ли вы прямо сейчас всецело доверить постройку нового дома соседскому ребёнку, создающему впечатляющие шедевры из Lego?

Мой главный посыл, который я пытаюсь донести в этой статье: простые программы очень сильно отличаются от программ, спроектированных инженерами. Простейшее определение процесса программирования: составление упорядоченной последовательности действий для компьютера с целью получения чего-то конкретного на выходе, при заданных вводных параметрах. Процесс программной инженерии — это проектирование, написание, тестирование и курирование компьютерной программы с целью решить задачи многих пользователей. Речь идет о создании надежных и безопасных решений, которые выдержат проверку временем и будут работать для некоторых возможно заранее неизвестных задач, помимо очевидных.

Программные инженеры знают все о задачах, которые они решают, решениях, которые они предлагают, ограничениях этих решений, их конфиденциальности и безопасности. По моему мнению, если человек не понимает сути проблемы, ему не стоит даже начинать программировать её решение. Программные инженеры не считают своей главной целью написание программ как таковое. Они думают в масштабах обеспечения потребностей и решения проблем. Это важно, поскольку не каждая проблема требует создания программного решения. С некоторыми из них вполне можно разобраться с помощью уже существующих программ. Возникновение некоторых проблем иногда можно предсказать заранее, а с помощью грамотного проектирования программ - избежать в будущем.

«Интеллектуалы решают проблемы, гении предотвращают их»

- Альберт Эйнштейн

Сложные проблемы зачастую требуют написания множества программ. Существуют задачи, которым нужны параллельно работающие приложения, иные нуждаются в последовательном выполнении нескольких программ. Ряд проблем можно решить, просто обучив пользователей. Перед тем, как приступить к созданию программы, инженер ПО задает себе ряд вопросов:

Какие задачи я должен решить?
Что еще, кроме написания кода, можно сделать, чтобы решить их?
Что я могу сделать для упрощения решения этих задач с помощью приложения?

Хорошие программы понятны и читабельны. Их легко расширять, они отлично ладят с другими программами, и работа с ними не станет вашим ночным кошмаром. Качество кода не является предметом переговоров. Оно должно быть высоким, и всё тут. При его рассмотрении недопустимы отговорки вроде плохого настроения кодера или слишком сжатых сроков исполнения (ох уж эти дедлайны!). Один из самых важных моментов разработки ПО — проектирование программы таким образом, чтобы в дальнейшем её было легко поддерживать и модифицировать (привет, ООП!). Сегодня практически всё ПО модифицируемо, зачастую этот процесс происходит даже без участия пользователя или не требует от него ничего, кроме «пришло обновление вашей программы, нажмите ОК или Отложить». Разумеется, пользователи вправе требовать от приложений новых функций (особенно если речь идёт о долгоиграющем корпоративном ПО, которое пишут на Java, или об онлайн-играх, в которые можно играть годами).

Хотите знать больше о программировании на Java? Вступайте в группу Java Developer!

Сам по себе кусок кода вряд ли можно назвать полезным. Полезные функции ПО начинаются там, где разрозненные куски приложений взаимодействуют между собой, обмениваются данными и работают сообща, выполняя задание представления данных и интерфейсов пользователям.

Программы следует проектировать с учетом этих моментов! Какие сообщения они принимают? Какие события мониторят? Как происходит аутентификация и авторизация? Другой не менее важный признак хорошей программы — понятность кода, а не количество пройденных приложением тестов или даже не хорошее покрытие тестами. Казалось бы, простые вопросы: «Может ли кто-то, кроме меня, разобраться с моим кодом?», «Смогу ли я, написав сегодня этот код, понять его через несколько недель?». Популярная цитата о двух самых сложных вещах в программировании гласит:

«Есть только две действительно сложные вещи: инвалидация кэша и именование сущностей»

— Фил Карлтон.

Читаемость кода куда важнее, чем принято считать. К сожалению, невозможно определить точные показатели или параметры для ясности кода. Отчасти помогут запоминания общепринятых языковых норм, хороших моделей ПО и методов разработки. Но обычно этого недостаточно. У настоящих профессионалов со временем и опытом развивается, если можно так сказать, «чувство ясности», нечто сродни интуиции. Здесь хорошо подойдет метафора с письмом: знание большого количества слов, не поможет вам написать краткий и ясный по смыслу.

«Я написал бы короче, но у меня не было времени»

— Марк Твен.

Возможность легко и быстро исправлять баги — ключевой признак хорошего программного обеспечения. Ошибки в программе должны отправлять четкие сообщения и централизовано регистрироваться для отслеживания. Когда приходит сообщение о новой ошибке, тот, кто будет ее устранять, должен иметь возможность для отладки. Ему нужно легко подключаться к системе, получать доступ к информации о выполнение в любое время, а также иметь возможность легкой проверки работоспособности любой части системы. Когда инженеры-программисты разрабатывают приложения, они делают всё от себя зависимое, чтобы те работали на компьютерах разной архитектуры и с разными ОС. Важно, чтобы ПО работало при разных разрешениях и ориентациях экрана, а ещё — чтобы оно не «ело» больше памяти и процессорных мощностей, чем требуется.

Если речь идёт о веб-приложениях, то они должны работать во всех основных браузерах. Создавая декстопное приложение, нужно удостовериться, что оно запускается и корректно работает и на Mac, и на Windows, и на Linux. Ну а программа, зависит от данных, то приложение должно работать даже в случае медленного соединения с данными либо его отсутствия. Чтобы написать часть программы, инженеры продумывают всевозможные варианты сценария, а также планируют их тестирование. Все начинается с выбора идеального варианта, при котором все работает без ошибок. Затем они документируют всевозможные вероятные проблемы и заносят их в план тестирования. Некоторые инженеры начинают с написания кода, который они называют тестовым примером и в котором имитируются сценарии всех вероятных проблем и ошибок. А затем уже пишется программа, которая сможет работать при любом из рассмотренных вариантов. Уникальной способностью талантливого инженера ПО является не знание, как написать код, а понимание того, что именно приложение должно делать на выходе и как этого добиться. Инженеру необходимо при неполных, а, возможно, и неоднозначных требованиях заказчика к ПО правильно их оценить и «понять». Программный инженер в большинстве случаев может быстро решить проблему. Если вы думаете, что при найме на работу «дорогого» опытного программиста вы увеличите затраты, подумайте еще раз. Чем более опытным окажется нанятый программист, тем быстрее он сможет предоставить простое, аккуратное, надежное и легкое в эксплуатации решение. В долгосрочной перспективе это однозначно уменьшит затраты на разработку ПО.

Также необходимо учитывать затраты на исполнение программы. Любая программа использует вычислительные ресурсы, а они — не бесплатны.

Задача Software Engineer состоит в написании эффективного кода, который не использует вычислительные ресурсы без необходимости.

Например, кеширование часто используемых данных — одна из возможных стратегий, применяемых для получения желаемого результата. Но это — только один из, наверное, сотен инструментов и решений, которые могут сделать программу быстрее и эффективнее. Начинающий программист может предоставить вам дешевое решение, но использование такого решения, в конечном итоге, будет стоить вам и вашим клиентам намного дороже, чем в случаи если бы вы работали с опытным разработчиком, создавшим, в первую очередь, эффективное решение. Хороший программист ведет разработку с мыслью об Опыте Пользователя (User Experience (UX)). Взаимодействие «человек-машина» — тема с бесконечным количеством исследований и решений. Чем больше решений применяется, тем лучше должна получится программа. Вот несколько примеров, просто для того что бы вы прочувствовали, что это за направление такое:

Когда ведется разработка форм для ввода данных, таких, как e-mail, хорошая программа должна игнорировать регистр букв для адреса электронной почты. Она не должна выдавать ошибку, если нажата клавиша CAPSLOCK, поскольку адрес электронной почты уникален в нижнем регистре. Если программа принимает на ввод новый адрес электронной почты, проверяйте его на ранних этапах ввода, чтобы предупредить пользователя о том, что он использует неверный формат адреса. Такое решение включает как очевидные проверки вроде пропущенный знак «@», а также не столь очевидные, как, например, проверка на неправильный порядок символов вроде «gmail.ocm»
Когда пользователь перенаправляется для выполнения какого-нибудь действия, хорошая программа должна запомнить его текущее положение и вернуть его обратно после того, как он закончит. Хорошая программа также должна запомнить уже переданные пользователем данные, важные для дальнейшего с ним взаимодействия.

Допустим, вы ищете авиаперелеты как Гость на Expedia. Позже вы решаете создать учетную запись. Приложение должно сохранить все ваши предыдущие поисковые запросы в новой учетной записи, и вы должны иметь к ним доступ с других устройств.

Хорошая программа разрабатывается с мыслью о сценариях поведения пользователя. Не нужно просто добавлять новые возможности по принципу «чтобы было», поставьте себя на место пользователя. Однажды я бронировал билеты на самолет и забыл указать мой номер часто летающего пассажира. После получения подтверждения я решил пойти на сайт авиакомпании и добавить его, чтобы получить скидку. Чтобы понять, как это сделать, я возился на сайте с добрых 10 минут. Приложение было настолько неочевидным, что я попросту бесцельно лазил по разным страничкам сайта, дабы найти то, что мне нужно. Позднее я обнаружил, что уже пару раз попадал на нужную страничку, но даже не понял этого, так как нужное мне поле затерялось среди других подобных полей огромной формы.

Оказалось, что для того, чтобы отредактировать информацию о поездке, мне нужно было прокрутить около двадцати строк формы, ввести номер карты лояльности и номер телефона, без которого форму нельзя отправить на проверку. Это пример программы, которая разрабатывалась без мысли о том, насколько пользователю будет с ней удобно.

По моему мнению, самое важное отличие профессионального разработчика программного обеспечения от любителя — учет таких параметров, как надежность, защищенность и безопасность приложения при его создании.

Настоящий профессионал знает, что он несёт ответственность за безопасность и защищенность своего решения.

Части программы должны быть устойчивы к некорректному вводу, некорректным состояниям и неправильному взаимодействию. Это действительно очень трудно обеспечить и это основная причина, по которой мы слышим истории о том, что люди гибнут из-за ошибок в программном обеспечении. Пользователи вводили, вводят и будут вводить некорректные данные в программу. Это нужно принять, как факт. Причём некоторые будут делать это специально, с целью сломать приложение и добраться до ресурсов, доступных ему.

Вот пример из реальной жизни: особа, якобы ответственная за недавнюю утечку данных Equifax, обвиняется в невыполнении своих служебных обязанностей, которые заключались в разработке решений, устойчивых к плохому и злонамеренному вводу во всех программных продуктах, поступающих в общий доступ. Случаи, имеющие отношение к информационной безопасности, связаны не только с неправильным и вредоносным вводом, но также и с правильно вводимыми данными. Если пользователь забыл свой пароль, сколько раз он может пробовать его ввести? Заблокируете ли вы его после этого? А что, если кто-нибудь другой пытается заблокировать его учетную запись? Может ли пользователь передавать свои учетные данные по незашифрованному каналу передачи данных? Что, если запрос на вход поступил из необычного места? Что вы будете делать, если попытка входа похожа на автоматическую? Что вы сделали для того что бы защитить ваших пользователей от межсайтового скриптинга и межсайтовой подделки запросов и банального фишинга? Есть ли у вас резервная стратегия на случай DDoS-атаки ваших серверов? Эти вопросы указывают только на некоторые проблемы, которые необходимо учитывать. Защищенная программа не сохраняет важную информацию в текстовом виде. Она защищает её с помощью сложного одностороннего шифра (такого, с помощью которого легко зашифровать, но практически невозможно расшифровать без ключа). Это резервные меры на случай, если программу всё-таки взломают. Хакеры обнаружат зашифрованные данные, которые бесполезны для них. Неожиданные проблемы возникают даже в лучших программах. Программиста, который не готов к их возникновению, вряд ли можно назвать профессионалом. Пока он не ожидает неожиданного поведения, он не инженер. Он — «автор небезопасных программ». Ошибки в программах не всегда очевидны. Наши интеллектуальные возможности предвидеть и предотвращать известные ошибки ограничены. Вот почему программные инженеры понимают значимость хороших инструментов, позволяющих им писать правильное и безопасное программное обеспечение. Нет сомнений, нам нужны разные и хорошие инструменты разработки. Их роль часто недооценивают, но на самом деле они изрядно экономят время и силы, упрощая некоторые задачи на порядок. Представьте, если бы вам до сих приходилось заливать файлы по FTP для развертывания, так сказать, по старинке. Вообразите отладку проблем сети и производительности без Chrome DevTools! А как неэффективно в наши дни было бы писать код на JavaScript без ESlit и Prettier!

Любой инструмент, сокращающий время обратной связи, когда вы пищите код, должен быть принят с радостью. Когда я нахожу незнакомый мне ранее, но действительно полезный и действенный инструмент, я могу сожалеть лишь о том, что я не использовал до этого счастливого момента.

Более качественные и современные инструменты помогут вам стать лучшим программистом. Находите их, используйте, цените, и, если можете, — улучшайте их. И не зацикливайтесь на одном и том же: кто знает, возможно, с новым инструментом вы один раз потратите время на установку и изучение, а затем будете решать задачи в разы быстрее?

Никто не может изучить программную инженерию за два месяца, за полгода, и даже за год. Вас не научат быть программным инженером на курсах, в университете или в учебном лагере. Я учусь последние двадцать с лишним лет и продолжаю учится сейчас. Я смог спокойно называть себя опытным программистом только после десятилетия обучения и разработки, создания и поддержки приложений, которыми пользуются тысячи пользователей. Программная инженерия — не для всех, но каждый должен учится решать свои задачи с помощью компьютера. Если вы можете научиться писать простые программы, вам стоит это сделать. Если вы можете научиться использовать общедоступное программное обеспечение, вам стоит это сделать. Если вы можете научиться использовать программы с открытым исходным кодом и дорабатывать их для себя, вы получите суперсилу! Каждый день приносит разработчикам новые задачи, новые проблемы, поэтому и нужна программная инженерия. Главная задача этой профессии — создавать ПО так, чтобы обычному человеку не пришлось разбираться с ним по многу лет. Чтобы для взаимодействия с программами не было нужды в долгой учёбе. И ещё —программные инженеры всё время думают над созданием более совершенных инструментов, способных решать более сложные известные проблемы, и делать все возможное, чтобы новые проблемы появлялись как можно реже.

Программная инженерия отличается от программирования

27 ноября 2017 в 12:07 (МСК)

Перевод Software engineering is different from programming.

Некоторым людям не нравится термин «программный инженер» из-за метафоры с инженерным делом. Но эта статья не про термин. Если он вам не нравится, замените на Автора программ, Умельца по программному обеспечению или Программного художника!

Под «программным инженером» я подразумеваю человека, который считает своей профессией написание качественного ПО. Этот человек использует науку и статистику в своей профессии, и не относится к ней как к способу зарабатывания денег.

Умение программировать не делает вас программным инженером. Научиться программированию может любой. Это просто. Кто угодно может создавать простые программы, которые будут работать для авторов и на их машинах, но совершенно не обязательно, что те же программы будут работать и для других людей.

Я люблю приводить такое сравнение: все могут развлекаться пением в душе, но приходя в гости, вряд ли кто-то включит записи своего «исполнения». Все предпочтут слушать профессионалов.

Нужны ещё примеры? Пожалуйста:

В школе мы все изучаем математику и письмо, но это не делает нас математиками и писателями.
Большинство из вас легко научится готовить, но если нужно накормить много людей, вы наймёте шеф-повара.
Вы вряд ли позовёте своего рукастого соседа построить вам с нуля дом.

В этой статье я хочу поделиться своим мнением, что простые программы очень отличаются от профессионально разработанных (engineered) программ.

Простейшее определение программирования: дать компьютеру инструкции что-то сделать с какими-то входными данными, чтобы получились какие-то выходные данные.

Инженерия программного обеспечения — это проектирование, написание, тестирование и сопровождение компьютерных программ для решения пользовательских задач. Это создание устойчивых и безопасных решений, которые выдержат проверку временем и будут решать какие-то неизвестные задачи, связанные с задачами очевидными. Программные инженеры всё знают о решаемых ими задачах и предоставляемых решениях, об ограничениях этих решений, об их влиянии на приватность и безопасность. Если кто-то не понимает сути задачи, то его нельзя допускать к программированию решения. Программные инженеры не воспринимают свою карьеру как просто написание программ. Они мыслят категориями удовлетворения потребностей и решения проблем. Это важно, поскольку не для всякой проблемы нужно писать программу. Какие-то задачи решаются с помощью уже имеющихся программ или их комбинации. Появление каких-то проблем вообще можно предотвратить, если действовать на упреждение. Проектирование хороших программ зачастую требует планирования, чтобы избежать проблем в будущем. Интеллектуалы решают проблемы, гении их предотвращают. Альберт Эйнштейн Для решения сложных задач обычно требуется написать несколько программ. В каких-то случаях программы должны работать параллельно, в каких-то — последовательно. Некоторые проблемы можно решить, если обучить пользователей. Прежде чем писать программу, инженер должен спросить себя:

Какие задачи я пытаюсь решить?
Что ещё можно сделать для их решения, кроме написания кода?
Как я могу облегчить решение этих задач с помощью кода?

Замечательные программы понятны и читабельны, их можно легко расширить, они прекрасно работают с другими программами, а сопровождение не превращается в кошмар. Качество кода — не предмет для обсуждения, корявые обходные решения из-за дедлайна или эмоций — неприемлемы. Один из важнейших аспектов программной инженерии заключается в том, что при проектировании продукта с нуля в него закладывается возможность расширения. Приложения изменяются, это естественно. Пользователям понадобится больше возможностей, они захотят ещё большего удобства использования. Сама по себе какая-то часть ПО не слишком полезна. По-настоящему полезные свойства программное обеспечение обретает, когда многочисленные компоненты взаимодействуют друг с другом, обмениваются данными и совместно предоставляют пользователям информацию и интерфейсы. Всё это нужно учитывать при проектировании программ. Какие сообщения они должны принимать? Какие события отслеживать? Какие сообщения отправлять? Как будет устроена аутентификация и авторизация? Ещё одна важная черта замечательных программ — это чистота кода, а не поголовье тестов или количество отчётов о покрытии. Простой вопрос: этот код читабелен для других? Или ещё лучше: я, автор этого кода, смогу понять его через несколько недель? В информатике есть лишь две трудности: инвалидация кэша и присвоение имён. Фил Карлтон Читабельность кода гораздо важнее, чем вы думаете. К сожалению, пока ещё не придумали хороших метрик чистоты кода. Отчасти помогают хорошие шаблоны и методики проектирования, но зачастую этого мало. Грамотные программные инженеры просто развивают в себе чутьё на чистоту кода, полагаясь на свой опыт и интуицию. Здесь очень уместна метафора с писательством: знание огромного количества слов не поможет вам писать осмысленные и понятные тексты. У меня нет времени писать короткое письмо, так что пишу длинное. Марк Твен С программами возникают трудности. Возможность легко решать их — неотъемлемый признак хорошего ПО. Возникающие в программах ошибки должны сопровождаться понятными сообщениями, должен вестись централизованный журнал ошибок для последующего анализа. Когда приходит отчёт о новой ошибке, ответственный за её исправление человек должен иметь возможность отладить. У него должна быть возможность влезть в потроха системы и прочитать информацию о контексте исполнения в любой момент времени. Должна быть возможность простой сверки ожиданий от любой части системы. Когда программные инженеры пишут программы, они проверяют, будут ли их детища работать в самых разных средах, на машинах с разными ресурсами, в разных часовых поясах. ПО должно работать на экранах всевозможных размеров, с любой ориентацией. Также программное обеспечение должно работать при ограниченном объеме памяти и вычислительной мощности. К примеру, если вы создаёте браузерное приложение, то оно должно работать во всех основных браузерах. Если создаёте приложение настольное, то чаще всего он должно быть в версиях под Mac и Windows. Если создаёте приложение, зависящее от внешних данных, то оно должно работать даже при медленном или временно пропадающем подключении. При создании ПО инженеры стараются предусмотреть все возможные сценарии и закладывают их в планы тестирования. Нужно проверять штатную работу приложения, когда не происходит ничего неожиданного (happy path), а также планировать тестирование всех возможных сбоев и проблем. Некоторые программные инженеры сначала пишут код для так называемых тестовых случаев, то есть симуляций всевозможных сценариев, а затем пишут желаемый код, который успешно выдерживает передряги тестовых ситуаций.

Программные инженеры понимают, что требования к ПО нередко размыты и неполны. Талантливый инженер понимает, не как написать решение, а что должно в него входить.

В большинстве случаев программные инженеры могут решать проблемы быстро. Если вы считаете, что найм опытных программистов означает повышение расходов, то подумайте об этом ещё раз. Чем более опытного программиста вы берёте, тем быстрее он будет писать устойчивые, аккуратные, надёжные и простые в сопровождении решения. А это приведёт к снижению общих расходов в долгосрочной перспективе. Не забывайте и о стоимости исполнения программ. Каждая программа использует компьютерные ресурсы, а они не достаются за «спасибо». Программные инженеры напишут эффективные программы, экономно расходующие ресурсы. Например, можно применить кэширование часто используемых данных, но это лишь один из тысяч возможных инструментов и способов ускорения программ и повышения их эффективности. Начинающий программист может дать вам простое решение, но его использование может стоить вам и вашим клиентам гораздо дороже, чем использование более эффективного продукта опытного программиста. Хорошие программы проектируются с учётом удобства использования (UX). Есть множество исследований и открытий на тему взаимодействия человека с компьютером. И чем больше мы узнаём, тем лучше могут быть наши приложения. Приведу несколько примеров, чтобы вы прочувствовали всю важность удобства использования:

Если нужна форма ввода адресов электронной почты, то хорошая программа будет игнорировать регистры букв. И даже обрезать пробелы по краям. На заставляйте пользователей нервничать из-за включённого CapsLock, адрес почты должен состоять из прописных букв. Если программа принимает новые адреса, то сразу проверяйте их корректность и сразу сообщайте пользователям, что они, возможно, вводят неправильный адрес. Сюда относится как очевидная проверка на отсутствие символа @, так и менее заметные ошибки, например, в написании доменов: “gmail.ocm.”
Если нужно перенаправить пользователя для выполнения какой-то задачи, хорошая программа запомнит, откуда перешёл человек, и в конце вернёт его обратно. Также хорошая программа запоминает любые уже внесённые данные и совершённые действия, если в дальнейшем о них нужно будет спросить пользователя. Допустим, вы в качестве гостя ищете авиарейс на Expedia. А затем решили создать аккаунт. В нём должна быть сохранена вся ваша предыдущая поисковая история, чтобы вы могли обращаться к ней при заходе с разных компьютеров.
Хорошая программа спроектирована с учётом пользовательских сценариев. Поставьте себя на место пользователя. Не надо просто добавлять фичи! Однажды я бронировал билет в авиакомпании United, и забыл ввести свой номер постоянного клиента. Получив подтверждение о бронировании, я зашёл на сайт United, чтобы добавить номер, и на это пришлось потратить ДЕСЯТЬ минут. Там просто не было никаких явных способов добавления, мне пришлось перебрать все ссылки, чтобы найти эту фичу. Зашёл на страницу, где можно было ввести номер, и сначала не мог найти поле ввода, потому что оно было запрятано в глубинах большой формы. Мне пришлось отредактировать информацию о пассажире, пролистать назад около 20 разделов этой формы, выбрать тип номера, который я хочу использовать, а также ввести требуемый номер телефона, чтобы наконец подтвердить заполнение формы. Это пример программы, которая проектировалась без учёта удобства пользователя.

Пожалуй, это важнейшие свойства приложений, по которым можно отличить профессионалов от любителей. Профессионалы понимают, что должны писать безопасные и защищённые решения. Приложение должно быть устойчивым к плохому вводу данных, плохим состояниям и плохим способам взаимодействия. Этого ОЧЕНЬ трудно добиться, и поэтому мы слышим истории о том, как люди гибнут из-за программных ошибок. Пользователи будут вносить в приложения плохие или ошибочные данные. Кто-то сделает это намеренно, стараясь сломать программу и проникнуть в представляемые ею ресурсы. Человек, якобы ответственный за недавнее фиаско Equifax, обвинил компанию в том, что она во всём публично доступном ПО не предусмотрела возможность ввода плохих и вредоносных данных. Проблема защищённости связана с вводом не только плохих и вредоносных, но также и нормальных данных. Если пользователи забывают свои пароли, то сколько попыток даётся на ввод? Вы блокируете пользователей после определённого количества попыток? А если ещё кто-то пытается блокировать пользователей? Вы разрешаете вводить пароли при незашифрованном соединении? А если попытка входа совершается с необычного для этого пользователя IP-адреса, компьютера, системы? Что вы делаете, если действия пользователя выглядят автоматизированными? Что вы делаете для защиты своих пользователей от межсайтового скриптинга и подложных запросов, от атак «человек посередине» и простого социального фишинга? У вас есть запасная стратегия на случай DDoS-атаки на ваши серверы? Всё это лишь малая часть проблем, которые вам нужно предусмотреть. Защищённые программы не хранят важную информацию в виде обычного текста, а используют одностороннее шифрование с очень устойчивыми ко взлому алгоритмами. Это запасная стратегия на случай компрометации программы и данных. Чаще всего зашифрованные данные окажутся для хакеров бесполезны. ПО переходит в плохое состояние, его нужно привести в порядок. Неожиданные проблемы могут возникать даже с лучшими программами. Если вас это не волнует и вы к этому не готовитесь, то вы не профессионал в создании ПО, вы просто пишете небезопасные программы. Дефекты в программах невидимы. Возможности нашего разума спрогнозировать и предотвратить эти дефекты не безграничны. Поэтому программные инженеры осознают ценность хороших инструментов, помогающих писать корректное и безопасное ПО. Несомненно, нам нужно более разнообразные и качественные инструменты. Они играют большую роль и часто недооцениваются. Если бы нам сегодня ещё приходилось слать файлы по FTP для развёртывания приложений? Если бы нам приходилось отлаживать проблемы с сетью и производительностью без Chrome DevTools? Представьте, насколько неэффективно сегодня писать JavaScript без ESLint и Prettier! Если вы JavaScript-разработчик и вынуждены выбирать какой-то один плагин для редактора кода, берите ESLint.

Нужно приветствовать любой инструмент, сокращающий цикл обратной связи при написании кода. Для меня стало откровением мнение Брета Витора об изобретении моментальных визуальных представлений для того, что мы создаём. Расширение спектра инструментов и их улучшение — один из путей в светлое будущее. Если вы ещё не смотрели выступление Брета, отложите все дела и немедленно посмотрите.

Когда я нахожу новый замечательный инструмент, то сожалею лишь о том, что не нашёл его раньше. Более совершенные инструменты помогут вам программировать лучше. Найдите их, используйте, цените и, если можете, улучшайте их. Выбор языка имеет значение. Типобезопасность имеет значение. TypeScript (и Flow) — лучшее, что произошло с JavaScript. Статичный анализ кода важнее, чем вы думаете. Если вы им не пользуетесь, то ваш код остаётся уязвимее к будущим проблемам. Не пишите код без системы статичной типизации. Если ваш язык не имеет статичной типизации, то либо меняйте язык, либо найдите траспилятор. Сегодня транспиляторы достаточно сообразительны и работают, читая комментарии в коде. Я считаю, именно так в будущем будет выполняться проверка типов в языках, изначально её не поддерживающих. Никто не может стать программным инженером за два месяца, или шесть, или даже за год. Вы не научитесь программной инженерии в летнем лагере. Я занимаюсь ею больше 20 лет, и до сих пор учусь. Я стал достаточно уверенно называть себя опытным программистом лишь после десятилетия обучения, а затем проектирования, создания и поддержки приложений, которыми пользуются тысячи людей. Программная инженерия — занятие не для всех, но каждый должен учиться решать свои собственные проблемы с помощью компьютеров. Если вы можете научиться писать простые программы, то учитесь. Если можете научиться использовать распространённые программные сервисы, то делайте это. Если можете научиться использовать open-source ПО, то обретёте много возможностей.

Программная инженерия должна развиваться вместе с задачами. Будущее этой профессии в том, чтобы обычные пользователи могли использовать свои компьютеры без нескольких лет предварительного обучения. Чтобы пользователи могли сами решать простые задачи с помощью лёгких в применении инструментов. Затем программные инженеры перейдут к созданию более совершенных инструментов, к решению более сложных известных проблем, и будут всячески предотвращать появление неизвестных.

Программная инженерия отличается от программирования

Перевод Software engineering is different from programming.

Нужны ещё примеры? Пожалуйста:

В школе мы все изучаем математику и письмо, но это не делает нас математиками и писателями.
Большинство из вас легко научится готовить, но если нужно накормить много людей, вы наймёте шеф-повара.
Вы вряд ли позовёте своего рукастого соседа построить вам с нуля дом.

Программные инженеры всё знают о решаемых ими задачах и предоставляемых решениях, об ограничениях этих решений, об их влиянии на приватность и безопасность.

Если кто-то не понимает сути задачи, то его нельзя допускать к программированию решения.

Менталитет решения

Программные инженеры не воспринимают свою карьеру как просто написание программ. Они мыслят категориями удовлетворения потребностей и решения проблем. Это важно, поскольку не для всякой проблемы нужно писать программу. Какие-то задачи решаются с помощью уже имеющихся программ или их комбинации. Появление каких-то проблем вообще можно предотвратить, если действовать на упреждение. Проектирование хороших программ зачастую требует планирования, чтобы избежать проблем в будущем.

Интеллектуалы решают проблемы, гении их предотвращают. Альберт Эйнштейн

Для решения сложных задач обычно требуется написать несколько программ. В каких-то случаях программы должны работать параллельно, в каких-то — последовательно. Некоторые проблемы можно решить, если обучить пользователей.

Прежде чем писать программу, инженер должен спросить себя:

Какие задачи я пытаюсь решить?
Что ещё можно сделать для их решения, кроме написания кода?
Как я могу облегчить решение этих задач с помощью кода?

Качество кода

Один из важнейших аспектов программной инженерии заключается в том, что при проектировании продукта с нуля в него закладывается возможность расширения. Приложения изменяются, это естественно. Пользователям понадобится больше возможностей, они захотят ещё большего удобства использования.

Сама по себе какая-то часть ПО не слишком полезна. По-настоящему полезные свойства программное обеспечение обретает, когда многочисленные компоненты взаимодействуют друг с другом, обмениваются данными и совместно предоставляют пользователям информацию и интерфейсы.

Всё это нужно учитывать при проектировании программ. Какие сообщения они должны принимать? Какие события отслеживать? Какие сообщения отправлять? Как будет устроена аутентификация и авторизация?

Ещё одна важная черта замечательных программ — это чистота кода, а не поголовье тестов или количество отчётов о покрытии. Простой вопрос: этот код читабелен для других? Или ещё лучше: я, автор этого кода, смогу понять его через несколько недель?

В информатике есть лишь две трудности: инвалидация кэша и присвоение имён. Фил Карлтон

Читабельность кода гораздо важнее, чем вы думаете. К сожалению, пока ещё не придумали хороших метрик чистоты кода. Отчасти помогают хорошие шаблоны и методики проектирования, но зачастую этого мало. Грамотные программные инженеры просто развивают в себе чутьё на чистоту кода, полагаясь на свой опыт и интуицию. Здесь очень уместна метафора с писательством: знание огромного количества слов не поможет вам писать осмысленные и понятные тексты.

У меня нет времени писать короткое письмо, так что пишу длинное. Марк Твен

С программами возникают трудности. Возможность легко решать их — неотъемлемый признак хорошего ПО. Возникающие в программах ошибки должны сопровождаться понятными сообщениями, должен вестись централизованный журнал ошибок для последующего анализа. Когда приходит отчёт о новой ошибке, ответственный за её исправление человек должен иметь возможность отладить. У него должна быть возможность влезть в потроха системы и прочитать информацию о контексте исполнения в любой момент времени. Должна быть возможность простой сверки ожиданий от любой части системы.

Среды и тестирование

Когда программные инженеры пишут программы, они проверяют, будут ли их детища работать в самых разных средах, на машинах с разными ресурсами, в разных часовых поясах. ПО должно работать на экранах всевозможных размеров, с любой ориентацией. Также программное обеспечение должно работать при ограниченном объеме памяти и вычислительной мощности. К примеру, если вы создаёте браузерное приложение, то оно должно работать во всех основных браузерах. Если создаёте приложение настольное, то чаще всего он должно быть в версиях под Mac и Windows. Если создаёте приложение, зависящее от внешних данных, то оно должно работать даже при медленном или временно пропадающем подключении.

При создании ПО инженеры стараются предусмотреть все возможные сценарии и закладывают их в планы тестирования. Нужно проверять штатную работу приложения, когда не происходит ничего неожиданного (happy path), а также планировать тестирование всех возможных сбоев и проблем. Некоторые программные инженеры сначала пишут код для так называемых тестовых случаев, то есть симуляций всевозможных сценариев, а затем пишут желаемый код, который успешно выдерживает передряги тестовых ситуаций.

Стоимость и эффективность

Не забывайте и о стоимости исполнения программ. Каждая программа использует компьютерные ресурсы, а они не достаются за «спасибо». Программные инженеры напишут эффективные программы, экономно расходующие ресурсы. Например, можно применить кэширование часто используемых данных, но это лишь один из тысяч возможных инструментов и способов ускорения программ и повышения их эффективности.

Начинающий программист может дать вам простое решение, но его использование может стоить вам и вашим клиентам гораздо дороже, чем использование более эффективного продукта опытного программиста.

Удобство использования

Хорошие программы проектируются с учётом удобства использования (UX). Есть множество исследований и открытий на тему взаимодействия человека с компьютером. И чем больше мы узнаём, тем лучше могут быть наши приложения.

Приведу несколько примеров, чтобы вы прочувствовали всю важность удобства использования:

Если нужна форма ввода адресов электронной почты, то хорошая программа будет игнорировать регистры букв. И даже обрезать пробелы по краям. На заставляйте пользователей нервничать из-за включённого CapsLock, адрес почты должен состоять из прописных букв. Если программа принимает новые адреса, то сразу проверяйте их корректность и сразу сообщайте пользователям, что они, возможно, вводят неправильный адрес. Сюда относится как очевидная проверка на отсутствие символа @, так и менее заметные ошибки, например, в написании доменов: “gmail.ocm.”
Если нужно перенаправить пользователя для выполнения какой-то задачи, хорошая программа запомнит, откуда перешёл человек, и в конце вернёт его обратно. Также хорошая программа запоминает любые уже внесённые данные и совершённые действия, если в дальнейшем о них нужно будет спросить пользователя. Допустим, вы в качестве гостя ищете авиарейс на Expedia. А затем решили создать аккаунт. В нём должна быть сохранена вся ваша предыдущая поисковая история, чтобы вы могли обращаться к ней при заходе с разных компьютеров.
Хорошая программа спроектирована с учётом пользовательских сценариев. Поставьте себя на место пользователя. Не надо просто добавлять фичи! Однажды я бронировал билет в авиакомпании United, и забыл ввести свой номер постоянного клиента. Получив подтверждение о бронировании, я зашёл на сайт United, чтобы добавить номер, и на это пришлось потратить ДЕСЯТЬ минут. Там просто не было никаких явных способов добавления, мне пришлось перебрать все ссылки, чтобы найти эту фичу. Зашёл на страницу, где можно было ввести номер, и сначала не мог найти поле ввода, потому что оно было запрятано в глубинах большой формы. Мне пришлось отредактировать информацию о пассажире, пролистать назад около 20 разделов этой формы, выбрать тип номера, который я хочу использовать, а также ввести требуемый номер телефона, чтобы наконец подтвердить заполнение формы. Это пример программы, которая проектировалась без учёта удобства пользователя.

Надёжность, защищённость и безопасность

Пользователи будут вносить в приложения плохие или ошибочные данные. Кто-то сделает это намеренно, стараясь сломать программу и проникнуть в представляемые ею ресурсы. Человек, якобы ответственный за недавнее фиаско Equifax, обвинил компанию в том, что она во всём публично доступном ПО не предусмотрела возможность ввода плохих и вредоносных данных. Проблема защищённости связана с вводом не только плохих и вредоносных, но также и нормальных данных. Если пользователи забывают свои пароли, то сколько попыток даётся на ввод? Вы блокируете пользователей после определённого количества попыток? А если ещё кто-то пытается блокировать пользователей? Вы разрешаете вводить пароли при незашифрованном соединении? А если попытка входа совершается с необычного для этого пользователя IP-адреса, компьютера, системы? Что вы делаете, если действия пользователя выглядят автоматизированными?

Что вы делаете для защиты своих пользователей от межсайтового скриптинга и подложных запросов, от атак «человек посередине» и простого социального фишинга? У вас есть запасная стратегия на случай DDoS-атаки на ваши серверы? Всё это лишь малая часть проблем, которые вам нужно предусмотреть.

Защищённые программы не хранят важную информацию в виде обычного текста, а используют одностороннее шифрование с очень устойчивыми ко взлому алгоритмами. Это запасная стратегия на случай компрометации программы и данных. Чаще всего зашифрованные данные окажутся для хакеров бесполезны.

ПО переходит в плохое состояние, его нужно привести в порядок. Неожиданные проблемы могут возникать даже с лучшими программами. Если вас это не волнует и вы к этому не готовитесь, то вы не профессионал в создании ПО, вы просто пишете небезопасные программы.

Дефекты в программах невидимы. Возможности нашего разума спрогнозировать и предотвратить эти дефекты не безграничны. Поэтому программные инженеры осознают ценность хороших инструментов, помогающих писать корректное и безопасное ПО.

Инструменты

Несомненно, нам нужно более разнообразные и качественные инструменты. Они играют большую роль и часто недооцениваются.

Если бы нам сегодня ещё приходилось слать файлы по FTP для развёртывания приложений? Если бы нам приходилось отлаживать проблемы с сетью и производительностью без Chrome DevTools? Представьте, насколько неэффективно сегодня писать JavaScript без ESLint и Prettier!

Если вы JavaScript-разработчик и вынуждены выбирать какой-то один плагин для редактора кода, берите ESLint.

Выбор языка имеет значение. Типобезопасность имеет значение. TypeScript (и Flow) — лучшее, что произошло с JavaScript. Статичный анализ кода важнее, чем вы думаете. Если вы им не пользуетесь, то ваш код остаётся уязвимее к будущим проблемам. Не пишите код без системы статичной типизации. Если ваш язык не имеет статичной типизации, то либо меняйте язык, либо найдите траспилятор. Сегодня транспиляторы достаточно сообразительны и работают, читая комментарии в коде. Я считаю, именно так в будущем будет выполняться проверка типов в языках, изначально её не поддерживающих.

Эволюция программной инженерии

Никто не может стать программным инженером за два месяца, или шесть, или даже за год. Вы не научитесь программной инженерии в летнем лагере. Я занимаюсь ею больше 20 лет, и до сих пор учусь. Я стал достаточно уверенно называть себя опытным программистом лишь после десятилетия обучения, а затем проектирования, создания и поддержки приложений, которыми пользуются тысячи людей.

Программная инженерия — занятие не для всех, но каждый должен учиться решать свои собственные проблемы с помощью компьютеров. Если вы можете научиться писать простые программы, то учитесь. Если можете научиться использовать распространённые программные сервисы, то делайте это. Если можете научиться использовать open-source ПО, то обретёте много возможностей.

Автор: NIX_Solutions

Источник

Программная инженерия или информационная безопасность что выбрать

Компьютерные науки или программная инженерия – что выбрать?

Быстрый осмотр пациента

Какие перспективы?

Обязательные темы первого года

Обязательные темы второго курса

И все-таки, что выбрать, чтобы быть инженером-программистом?

Несколько примечаний

Другие материалы по теме:

Кто такой Software Engineer. Программная инженерия VS "просто" программирование

Программная инженерия отличается от программирования

Программная инженерия отличается от программирования

Менталитет решения

Качество кода

Среды и тестирование

Стоимость и эффективность

Удобство использования

Надёжность, защищённость и безопасность

Инструменты

Эволюция программной инженерии

Смотрите также