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

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

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

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

Инженерный склад ума — поиск прикладных решений

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

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

Качество программы и качество кода

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

Окружения и тестирование

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

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

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

Ориентация на удобство пользователя

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

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

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

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




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

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

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

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

Необходимые инструменты

Нет сомнений, нам нужны разные и хорошие инструменты разработки. Их роль часто недооценивают, но на самом деле они изрядно экономят время и силы, упрощая некоторые задачи на порядок. Представьте, если бы вам до сих приходилось заливать файлы по FTP для развертывания, так сказать, по старинке. Вообразите отладку проблем сети и производительности без Chrome DevTools! А как неэффективно в наши дни было бы писать код на JavaScript без ESlit и Prettier! Любой инструмент, сокращающий время обратной связи, когда вы пишите код, должен быть принят с радостью. Когда я нахожу незнакомый мне ранее, но действительно полезный и действенный инструмент, я могу сожалеть лишь о том, что я не использовал до этого счастливого момента.

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

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