Перевод 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 ПО, то обретёте много возможностей.

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