Мы инженеры-программисты или программисты? Используем ли мы оба, как если бы они были одинаковыми? Если мы посмотрим на первую главу в книге Разработка программного обеспечения в Google и увидим, что они посвящают этому целую главу, мы можем предположить, что это не одно и то же. Эту главу стоит прочитать, и в ней собраны все детали, которые они раскрывают. Сегодня я хочу показать вам свое видение через небольшое описание и реальный пример каждого из них.
Программист-программист
Программирование — это то, как мы создаем больше программного обеспечения, поэтому программист — это просто человек, который может создавать программное обеспечение, просто кусок кода, который что-то делает.
Кроме того, программирование является частью разработки программного обеспечения.
Инженер-программист
Инженер-программист — это человек, который должен заботиться о гораздо большем, чем просто создавать программное обеспечение. Программная инженерия должна думать о:
- время: как долго будет действовать решение. Это краткосрочное решение? Это надолго? Может быть, мы не знаем…
- масштаб: насколько большим он может стать?
- компромиссы: преимущества и недостатки каждого решения
Теперь я хочу представить несколько реальных примеров моей повседневной работы, которые можно отнести к каждой из этих категорий (инженерия и программирование).
Случай программирования
Был обнаружен угловой случай, и некоторые статусы элементов не были обновлены правильно. После просмотра кода и понимания проблемы было сделано исправление.
Теперь нам нужно исправить те статусы, которые остались с неправильными значениями. Создайте небольшую программу, которая:
- Найдены неправильные элементы
- Ищите правильное значение
- Обновите статус в каждом неправильном элементе
Нам просто нужно создать программу, которая выполняет эти инструкции, и определить, как ее запускать.
То есть нет необходимости думать о чем-то другом, кроме правильных указаний для решения конкретной задачи.
Инженерный случай
Нам нужно помочь нашим пользователям пройти самый сложный этап в нашем процессе заключения контрактов, это ключевой процесс, он зависит от внешних служб и может когда-нибудь дать сбой. В случае сбоя это замедляет процесс для наших пользователей и увеличивает нагрузку на нашу службу поддержки.
Мы оценили несколько вариантов:
- Вариант первый: добавьте дополнительные шаги для клиента в процесс, чтобы помочь ему запустить альтернативный процесс
- Второй вариант: создать запланированное задание для запуска процесса, который кэширует информацию, которая будет использоваться во время процесса.
Первое, что мы приняли во внимание: усилия для каждого решения.
- Первый вариант потребует работы с серверной частью вместе с работой приложений (IOS и Android). Процесс, который необходимо реализовать, довольно сложен и имеет несколько новых шагов и изменений. Любой, кто работает с нативными приложениями, знает о процессе выпуска для каждой платформы и проблеме, когда обнаруживается новая ошибка. Таким образом, будучи сложным процессом и бизнес-проблемой, не очень хорошо известной нативным приложениям, это может привести к увеличению времени выпуска, возможной ошибке, плохому решению и необходимости удалить его из процесса и т. д.… Запоминание: нативное приложение, когда оно выпущено, готово, вы не должны гарантировать, что у пользователя будет последняя версия (по крайней мере, простым способом).
- Второй вариант требует работы только для бэкэнд-команды, он снижает сложность процесса, избегая синхронизации между командами, участвует только команда со знанием бизнес-проблем, возможная ошибка может быть решена без взаимодействия с пользователем (только обновление бэкэнда). В то же время это решение могло не работать для некоторых пользователей. Но именно здесь вступают в игру дополнительные изменения, и для решения этих случаев будет запланирована другая задача (также сокращение изменений и повторное использование уже существующих функций).
Как только у нас появился лучший вариант, пришло время подумать о процессе и спроектировать его с учетом различных деталей:
- Объем обрабатываемых данных: используйте правильный параллелизм, алгоритмы, структуры данных и шаблоны проектирования.
- Наличие внешних сервисов: параллелизм вызовов, сроки выполнения задачи.
- Абстракция задачи, возможности конфигурации: сделайте процесс независимым и позвольте настроить задачу в соответствии с потребностями.
- Результаты задачи: писать журналы, создавать мониторинг и панель мониторинга, сохранять данные результатов для процесса исторификации и иметь возможность анализировать результаты.
Как вы могли заметить, я использовал слово «мы» для обозначения действий в этом примере, и это «мы» — одно из самых важных различий между программированием и проектированием. Инжиниринг — это командная работа!
Итак, как мы видим, для «инженерного» процесса требуется программное обеспечение, но это всего лишь один шаг процесса. В этом процессе гораздо больше, и большую часть времени мы должны стараться быть «инженерами-программистами» и быть «программистами-программистами», когда это необходимо (когда мы просто пишем простой код).
Что мы можем сделать, чтобы стать лучше в каждом из них?
Программист-программист
- Освойте свой основной язык программирования и изучите другие.
- Овладейте своим редактором, привязками клавиш, инструментами отладки и т. д.
- Улучшение структур данных и алгоритмов.
- Изучите наиболее часто используемые структурные и поведенческие модели.
- Совершенствуйте свои навыки тестирования.
Инженер-программист
- Улучшить коммуникативные навыки (аудирование, письмо, говорение).
- Изучите архитектурные шаблоны.
- Увеличьте свои возможности абстракции.
- Узнайте о проектировании систем.
Это некоторые из моих примеров и рекомендаций, и я надеюсь, что это кому-то поможет. Если вам это нравится, следите за мной на Medium для других статей!.
Есть ли у вас другие определения или примеры для этих двух понятий?
