«Самый ценный код – это код, который не следует писать»

«Самый ценный код — это код, который не нужно писать»

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

Механизация освобождает нас от ручной работы, которая либо слишком тяжелая, опасная, либо грязная. Ни один средневековый крестьянин не любил тащить телегу. Поэтому мы использовали лошадей и других животных. Мы изобретали инструменты и машины, и не только для замены мышц. Конечно, некоторая умственная работа может быть утомительно скучной, но большая ее часть не особенно опасна или грязна. Существуют неприятные исключения, такие как модерация социальных сетей, но большая часть этой работы сложна и полезна для вашего мозга. Так почему мы должны позволить искусственному интеллекту делать то, что люди уже любят делать и делают хорошо, например, писать сценарии или песни? Циничный бухгалтер будет утверждать, что нет смысла делать что-то вручную, если машина может доставить приемлемое качество дешевле. Есть нишевый рынок для ручных вязаных изделий, но недостаточно вязальщиков, чтобы одеть мир.

Если у вас хороший работодатель, ему будет важно ваше здоровье и благополучие, но его главной заботой не является обеспечение вам постоянного удовольствия от написания кода, особенно когда искусственный интеллект в конечном итоге сможет создать его по части стоимости. Код – это средство создания ценности, но это также и обязательство. Создание и поддержка кода затратны, если мы можем достичь той же ценности с меньшим (или без) кода, то тем лучше.

Я не знаю, когда навыки в традиционных языках программирования (с классами, типами, переменными и управляющими конструкциями) устареют, но я предсказываю, что это произойдет задолго до моей пенсии. До наступления этого момента овладение традиционным программированием (головоломками, как, например, Code Llama) все более станет еще одним ментальным вызовом, который компьютеры могут справиться лучше. Мы практикуем это для развлечения или в конкуренции с другими людьми, как, например, шахматы или го.

• Прекрасное AI-Art стимулирование Dalle-2 для создания изображений функциональных технических историй
• Humane запускает революционный носимый устройство с искусственным интеллектом AI-колышек
• Революционирование розничной торговли влияние искусственного интеллекта на опыт покупателя, управление инвентаризацией и маркетинг.

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

Вот как это могло бы происходить.

Собеседование без кода

Собеседователь: “Предположим, у нас есть автономное приложение, написанное на Java 6 с простым графическим интерфейсом Swing, которое считывает XML-файл, преобразует и обогащает данные, выполняя несколько запросов к базе данных и создает отчет Excel. Оно создавалось и поддерживалось программистом, который ушел от нас год назад. Также наш старший архитектор просмотрел код и решил, что качество серьезно не соответствует требованиям. Это типичный spaghetti, практически без модульных тестов. Как вы бы поступили, чтобы улучшить его и привести к хорошему уровню?”

Соискатель: “Прежде чем я изучу код, я бы хотел получить представление о том, насколько срочна и важна данная рефакторизация. Потому что это две разные проблемы”.

Интервьюер: “Как так?”

Соискатель: “Ну, моя ежегодная налоговая декларация очень важна, но так как ее сдача не ожидается еще полгода, это не срочно. С другой стороны, если я хочу купить билет в театр на сегодняшний вечер, это срочно, но не очень важно. Итак, насколько важен этот инструмент для организации? Какая польза он приносит и какой вред может нанести? Что произойдет, если пользователи не смогут получить доступ к инструменту в течение часа? А в течение дня, недели? Что, если он будет выдавать неправильные данные? На него полагается много пользователей? Как часто он используется? А по срочности, я имею в виду, насколько долго мы можем отложить работу? У пользователей есть проблемы прямо сейчас? Он надежно работает в производстве? Были ли с ним недавно инциденты? Как часто поступают запросы на изменение? Насколько стабильны входные и выходные спецификации? Он полагается на устаревшие технологии, которые скоро станут устаревшими и требуют обновления? Или это требование компании?”

Интервьюер: “Очень хорошие вопросы. Позвольте мне прояснить: это приложение используется дважды в год для создания входных данных для внутреннего вопросника. Входной файл представляет собой выгрузку из системы выплат и является очень стабильным. Запросы на добавление функций поступают три-четыре раза в год. Я считаю, что он написан на Java 6 и работает на компьютере разработчика”.

Соискатель: “Относительно запросов на добавление функций: насколько сложно их изменить?”

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

Соискатель: “Эти запросы на добавление функций были похожими?”

Интервьюер: “Да. В основном это добавление или удаление столбца в выводе”.

Соискатель: “И все же, второй разработчик жаловался, что это заняло слишком много времени. Можно предположить, что первый разработчик не задокументировал свой процесс и не провел рефакторинг?”

Интервьюер: “Хорошо подмечено”

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

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

Соискатель: “Как насчет покрытия модульными тестами?”

Интервьюер: “Меньше 20%”

Соискатель: “Если работодатель так небрежно относится к такому критическому элементу бизнеса, я не думаю, что я бы хотел работать на него. Поэтому я рад, что это только гипотетический случай. Мы должны решить проблему с тестовым покрытием, прежде чем приступать к изменению исходного кода. Риск регрессии слишком велик, если начинать рефакторинг без него. Создание подробных модульных тестов, вероятно, не является выполнимым, если все тесно связано. Давайте начнем с одного чувствительного на вход и выход компонента сообщений. Файл ввода/вывода и доступ к базе данных отделяются от бизнес-логики и создаются надлежащие модульные тесты без риска поломки. Но, поскольку вы добавляете тесты как после, забудьте о тестировании, основанном на TDD. Преимущества написания тестов вместе с производственным кодом уже нет. Вероятно, вы обнаружите, что ваш один модульный тест уже увеличил покрытие на 30 процентных пунктов”.

Интервьюер: “Мой последний вопрос. Вам не нравится хороший код?”

Соискатель: “Конечно, нравится. Но мне нравится полезное программное обеспечение больше. Я уверен, что есть отличные приложения с ужасно нечистым исходным кодом под капотом. То же самое здесь. Код может вызывать недовольство нашего чувства мастерства, но он не сломан, если у нас нет острой или немедленной проблемы. И это может случиться после благонамеренного улучшения. Делайте такие улучшения только в ответ на реальные запросы на добавление функций. Ограничьте время ваших усилий в таком случае. Соблазн превратить F в A сильный, но это редко имеет смысл с точки зрения бизнеса”.