В этой статье рассматриваются различные подходы к применению инструментов программистами с акцентом на такие аспекты, как эффективность и ответственность.
Инструменты для разработки
Инженеры приобретают и используют инструменты, чтобы повысить эффективность своего труда.
- Трудно копать землю палкой — лопата позволяет сделать это быстрее. Если необходимо оперативно переместить большой объем грунта, можно использовать более совершенный инструмент, например экскаватор.
- Точно так же трудно без инструментов соединить два деревянных бруска. Если требуется сделать это быстрее, плотник воспользуется молотком и гвоздями или струбцинами и клеем.
Выбирая и используя инструменты, инженеры не должны отказываться от своей ответственности. Есть старая поговорка: “Только плохие мастера винят свои инструменты”. Инструменты могут сделать работу инженера более эффективной, но они же могут внести дефекты в проектируемые изделия. Предположим, вам нужно соединить два деревянных бруска, и вы решили воспользоваться клеем. Но если вы находитесь в Антарктиде, клей может не выдержать сильного холода.
Чтобы выбрать подходящие инструменты, инженеру следует знать, в каких условиях будет использоваться изделие. Инструменты должны использоваться надлежащим образом, и инженер несет ответственность за продукт независимо от выбранных инструментов.
Таким образом, полезность инструментов определяется ответственностью инженеров за их правильное использование. Этический кодекс программной инженерии был совместно опубликован двумя крупнейшими профессиональными сообществами в области вычислительной техники — Ассоциацией вычислительной техники (ACM) и Институтом инженеров электротехники и электроники (IEEE).
Этот кодекс, ориентированный на инженеров-программистов и их продукты, не упоминает инструменты, используемые для разработки этих продуктов. Ответственность за высококачественный продукт лежит на команде разработчиков ПО, которые его создают. Инженеры-программисты должны умело выбирать и использовать инструменты, то есть эффективно (снижая затратность разработки) и ответственно (обеспечивая высокое качество продукта).
Эффективное и ответственное использование инструментов в программной инженерии
Будучи пользователями инструментов, инженеры-программисты должны развивать в себе такие качества, как эффективность и ответственность. Проиллюстрируем эту точку зрения на примере инструментов, используемых при выполнении различных задач программной инженерии.
При написании программного обеспечения
В процессе написания ПО инженеры часто обращаются к внешним ресурсам для более глубокого понимания задачи и предупреждения ошибок. Эти внешние ресурсы относятся к инструментам агрегации и управления знаниями.
- Например, можно воспользоваться руководством Linux по работе с bash или по определенным API, таким как библиотечные вызовы (например, malloc и free) и системные вызовы (например, open, read, write и close).
- В качестве альтернативы можно обратиться к интернет-ресурсам и найти подходящий ответ на дискуссионном форуме, таком как Stack Overflow.
Инструменты агрегации и управления знаниями обладают различным уровнем эффективности и ответственности.
Чтение руководства — дело небыстрое. На MacBook руководства по открытию, чтению, записи и закрытию файлов занимают 3548 слов или чуть более 7 страниц с одинарным интервалом. Предположительно на их прочтение уйдет более 10 минут, даже если они будут казаться простыми (хотя это не так).
В то же время на Stack Overflow на многие вопросы о чтении и записи файлов можно получить ответ примерно за 20 секунд. Очевидно, что Stack Overflow более выгоден в плане эффективности.
Теперь рассмотрим вопрос об ответственности. Некоторые студенты полностью выполняют задания по программированию, обращаясь к Stack Overflow. Они копируют код для устранения каждой возможной ошибки, и код компилируется. Но в итоге получается непредсказуемое и монструозное решение, которое они не до конца понимают. Когда же это решение не проходит всех тестовых испытаний, они с трудом пытаются его отладить и исправить.
В противоположность этому студенты, изучающие руководства, могут потратить больше времени на выполнение задания, но зато будут уверенно продвигаться вперед, а не вносить многочисленные правки.
Для инженеров важно и то, и другое: они должны работать эффективно, осознавать свою ответственность и надежность своего продукта. Такие инструменты, как Stack Overflow, ценны тем, что помогают сразу перейти к части руководства, имеющей отношение к делу. Не стоит игнорировать их. Но надо ответственно подходить к использованию Stack Overflow и подобных информационных ресурсов. Пользуясь Stack Overflow, инженер должен задать себе четыре вопроса.
- Обладаю ли я достаточным опытом, чтобы понять, насколько обоснован совет? Если да, то замечательно. В противном случае стоит потратить время на развитие своих профессиональных компетенций.
- Смогу ли я отладить этот фрагмент кода, если он сломается? Большинство постов на Stack Overflow необходимо адаптировать к конкретному контексту. К тому же многие из них содержат малозаметные ошибки, поскольку предназначены для демонстрационных целей. Никогда не следует брать чужой код, не зная, как он работает.
- Насколько важно, чтобы я полностью понимал эту проблему и ее решение? В инженерной работе одни знания являются критически важными, другие — нет. Большинство инженеров не нуждаются в глубоком знании форматов даты и времени или RFC при определении действительных адресов электронной почты. Интернет-ресурсы — отличный способ найти подходящие фрагменты кода для таких задач, которые затем можно спрятать в дружественном API в библиотеке утилит. Но работая над кодом для критически важных бизнес-процессов (или над ключевым алгоритмом в учебном проекте), нужно быть бдительным на каждом шагу.
- Как долго я искал решение своей проблемы? Лично я пользуюсь правилом “5 минут”. Если решение не находится более 5 минут, то для меня это сигнал о том, что с моим вопросом, скорее всего, что-то не так. Значит, нужно более тщательно подойти к изучению проблемы и подбору инструментов. Возможна и другая ситуация: я оказался одним из первых, кто пытается решить сложную проблему, поэтому стоит сосредоточиться на ее решении.
При отладке программного обеспечения
У большинства разработчиков ПО код не получается идеальным с первого раза. Один из подходов к отладке или поиску ошибок в коде, заключается в том, чтобы внимательно прочитать код и попытаться обнаружить ошибку. Этот подход практически не требует инструментов, не считая тех, которые могут помочь прочесть код.
Существует несколько инструментальных подходов. Поговорим о двух из них.
- Первый основан на использовании инструментов типа printf, которые позволяют реализовать стратегию, называемую логированием: программа оснащается операторами printf, которые сообщают инженеру о ее динамическом поведении.
- Другой подход предполагает применение инструментов, называемых отладчиками, например gdb (отладчик для командной строки) или ddd (графический интерфейс для gdb).
Упомянутые средства имеют разные характеристики по эффективности и ответственности. Трудно сказать, что эффективнее — логирование или отладка. Иная ошибка находится с помощью одной записи в логе, тогда как для выявления дефекта, связанного с взаимодействием двух компонентов, может потребоваться длительный сеанс работы с отладчиком. Многочисленные исследования показывают: любой из этих инструментов будет более эффективным, чем попытка выявить ошибку при простом чтении кода, состоящего из сотен строк.
Это подводит нас к вопросу об ответственности, требующей осторожности действий. Внимательное изучение ПО (при подходе без использования инструментов) позволяет получить глубокие знания о его поведении и предположениях. Выявление ошибки в таком случае наверняка приведет к ее устранению без ущерба для существующих моделей поведения и предположений.
Однако многие студенты предпочитают действовать иначе: быстро обнаружив ошибку с помощью логгера или отладчика, они экономят время на ее устранение, поскольку не могут до конца понять выявленный дефект.
Это не означает, что не надо использовать логгеры и отладчики — инструменты, позволяющие более эффективно находить дефекты. Однако использовать их нужно ответственно. После обнаружения дефекта, необходимо изучить код, чтобы убедиться, что его исправление не приведет к поломке чего-то еще.
При делегировании задач по разработке ПО
Область вычислительной техники постоянно меняется. Одним из главных изменений последнего времени стало появление инструментов генеративного искусственного интеллекта (GenAI), таких как ChatGPT от OpenAI, Bard от Google и CoPilot от GitHub. Эти инструменты также называют большими языковыми моделями (LLM), поскольку ядром их реализаций являются LLM.
Одни генеративные инструменты (например, Stack Overflow) построены как системы ответов на вопросы. Другие (например, автозавершение, предлагаемое CoPilot) более тесно интегрированы в процесс разработки программного обеспечения.
Обе эти разновидности GenAI отличаются от предыдущих инструментов программной инженерии своей интерактивностью. Предыдущие инструменты, будь то отладчики, генераторы кода или агрегаторы знаний, статичны и требуют от пользователя адаптации созданных ими решений к конкретным условиям. Новые инструменты GenAI динамичны: если у вас есть дополнительные требования, можно попросить их доработать ваши предложения с учетом конкретной ситуации.
Инструменты GenAI, созданные компаниями-разработчиками ПО, особенно хорошо справляются с задачами, связанными с ПО. Их можно попросить реализовать распространенные структуры данных, объяснить ошибки в коде, написать документацию, сгенерировать “шаблонный” материал, например реализовать веб-клиент с использованием определенной библиотеки.
Интерактивность инструментов GenAI позволяет воспринимать их не столько как средства для ответов на вопросы (как, например, Stack Overflow), сколько как помощника, которому инженер может делегировать некоторые задачи.
Инженеры-программисты, которые освоят генеративные инструменты в полной мере, окажутся продуктивнее тех, кто откажется от них или будет использовать их неквалифицированно. И в этом нет ничего удивительного, поскольку инженеры — это пользователи инструментов, а GenAI — просто еще один вид инструментов.
Однако использование GenAI, как и любого другого инструмента, требует соблюдения баланса между эффективностью и ответственностью. Как и любое другое средство, GenAI следует применять только в пределах собственной компетенции. Если вы не готовы оценить результат работы инструмента, не стоит его использовать.
Вот две конкретные рекомендации по работе с текущим поколением инструментов GenAI.
- Вы должны полностью понимать спецификацию программного обеспечения, которое пытаетесь создать. Инструменты GenAI отлично подходят для создания первого (пробного) варианта проекта ПО, но они могут не справиться с каким-либо пограничным случаем. Выполнение такого пограничного случая с помощью промптов может оказаться менее эффективным, чем простое редактирование чернового варианта проекта, предложенного инструментом.
- Вам (инженеру) придется выполнять работу по проектированию. Современное поколение GenAI прекрасно справляется с заполнением шаблона и реализацией отдельных функций, но испытывает трудности, когда его просят придумать шаблон или разложить проблему на отдельные функции.
Несмотря на необходимость инженерной оценки, даже нынешнее поколение GenAI позволяет получить доступ к экспертным знаниям, приобретение которых в противном случае обошлось бы довольно дорого.
Например, вы разрабатываете ПО для работы на определенной аппаратной платформе, такой как ARM64.
- Концептуально вы можете знать, что ARM64 включает оптимизированные инструкции, такие как Single-Instruction-Multiple-Data (SIMD), позволяющие применять одну и ту же операцию к целому вектору данных. Это сокращает время преобразования вектора, а также энергозатраты на выполнение. Как оптимизация времени задержки, так и энергоэффективность являются причинами для использования этих возможностей.
- Однако вы можете не знать ни конкретной “магической формулы” для использования SIMD в вашем случае, ни предпочтительных библиотек для этого.
Недавно мне пришлось создавать с помощью ChatGPT-3.5 рабочую программу, адаптированную к ARM64, и то, на что ушло бы несколько дней (чтение руководств) или часов (поиски в интернете), заняло считанные минуты. Инструменты GenAI существенно повысили мою эффективность, а благодаря концептуальному владению SIMD, я смог ответственно оценить (и пересмотреть) предложения ChatGPT.
Инженерный опыт и инженерный анализ позволят вам задавать правильные вопросы GenAI, оценивать качество результатов и при необходимости пересматривать их. Другими словами, для эффективного и ответственного использования GenAI необходимы инженерный опыт и инженерный анализ.
Я рассматриваю GenAI как помощника программиста. Инженер остается ответственным как за разработку, так и за реализацию. Инструмент GenAI делает создание реализации более эффективным, но инженер по-прежнему отвечает за то, чтобы продукт был должным образом спроектирован и полностью решал поставленную задачу.
Программиста нельзя заменить: не беспокойтесь о том, что ваша работа будет автоматизирована. Но чтобы выполнять свои обязанности на достойном уровне, необходимо использовать все имеющиеся в вашем распоряжении инструменты, в том числе и GenAI.
Заключительные замечания
Вычислительная техника — захватывающая область. Современное общество работает на компьютерах, а компьютеры подчиняются своему программному и аппаратному обеспечению. Компьютерная инженерия (как программная, так и аппаратная) — это действительно профессиональная сфера XXI века.
Одна из особенностей вычислительной техники заключается в том, что ничто не остается неизменным. Согласно закону Мура, каждые 2–3 года появляется новая технология или инструмент, повышающий производительность труда компьютерных инженеров. Инженеры обязаны изучать эти новые инструменты — в противном случае они делают хуже себе, своему работодателю и своим клиентам.
Всегда используйте выбранные инструменты эффективно и ответственно.
Не забывайте о необходимости инженерного анализа и получайте удовольствие от работы.
Читайте также:
- Как развернуть GitLab с помощью Docker за 5 секунд
- Нужно ли дизайнеру уметь писать код?
- Понятия “связанности” и “связности” в объектно-ориентированном программировании
Читайте нас в Telegram, VK и Дзен
Перевод статьи James Davis: The Software Engineer as Tool-User
