Попробуйте в следующий раз изменить его на «мы»

Знаменитое слово «я»

«Я» - это слово, которое я часто слышу в последнее время. И это слово «я» часто исходит от разработчиков, которые в одиночку работают над серверными приложениями, у которых часто нет реальных пользователей. Забудьте о том, что сейчас мы говорим о back-end разработчике.

Если вы разработчик, мы все согласны с тем, что вы можете присоединиться к своему приложению и называть его своим. Это особенно верно, если вы много лет интенсивно работали над этим и знаете код наизусть. Неудивительно, что иногда разработчики чувствуют себя единственными пользователями приложения. И часто они начинают использовать «я» вместо «мы», когда говорят о приложении, которое мы контролируем.

В этой статье я расскажу о своем опыте работы с разработчиками, работающими над серверными, интерфейсными приложениями и прошивками, а также об их неправильном видении нашего приложения. Мы будем упоминать важность выражения «мы», а не «я», когда говорим о:

  • журналы приложений
  • код приложения
  • решение в целом

Предложения "I"

Начнем с моего любимого.

«Я нахожу журналы в моем приложении удобочитаемыми, и я прекрасно справляюсь».

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

Назовем ваших клиентов:

  • DevOps - они развертывают ваше приложение. Если они смогут выяснить, почему ваше приложение не работает должным образом, на ранней стадии, они сэкономят много времени людям, находящимся позже в цепочке.
  • Разработчики - вы не собираетесь работать над своим приложением бесконечно. Другие разработчики придут и продолжат вашу работу. И им нужно будет выяснить, почему ваше приложение не работает должным образом в производственной среде. Для них тоже есть журналы. Подумайте о других разработчиках, работающих над вашим приложением, даже если вы единственный, кто работает над ним в данный момент.
  • QA - Если они могут выяснить, кто виноват в ситуации, когда два приложения обмениваются данными, они не будут вызывать ошибки у двух человек, они будут вызывать ошибки только у одного человека, что сэкономит драгоценное время.
  • Поддержка - нет более тяжелого звонка, чем когда кто-то сообщает об ошибке в производственной среде. Подумайте и об этих парнях. Предоставьте им достаточно информации, чтобы понять, ошибка это или нет.

Убедитесь, что вы зарегистрировали следующее:

  • Параметры конфигурации во время запуска - DevOps может ошибаться при настройке вашего приложения. Регистрируйте загруженные параметры конфигурации во время запуска вашего приложения. Это сэкономит вам много времени.
  • Внешние вызовы к другим службам - если вы вызываете внешние службы, регистрируйте, что отправлено и кому вы отправляете. Если вы вызываете службы REST, запишите целевой URL-адрес и тело запроса, которое вы отправляете. Если вы отправляете сообщение в Kafka, зарегистрируйте, какой сервер Kafka и какую тему Kafka вы нацеливаете. Вы можете загрузить правильные параметры, но иногда вы передаете неправильный параметр, используемый для маршрутизации вызовов во внешние приложения.
  • Запрос / ответ - регистрируйте запросы, поступающие в ваше приложение, и ответы, генерируемые вашим приложением. Это самая ценная информация, которую вы можете получить, когда приходит отчет из производственной среды. Обладая этой информацией, вы можете исключить свое приложение как потенциального подозреваемого в ошибке.
  • Важное решение в вашем приложении - если вашему приложению необходимо решить, по какому пути идти, запишите, какой путь он выбрал, и параметры, которые заставили его пойти по этому пути. Часто вы можете увидеть, как приложение работает не так, как вы ожидали. Записать что: путь, по которому прошло приложение. И запишите почему: параметры, которые заставили вас пойти по этому пути. Позже будет легче проанализировать.

Общее правило: поместите журнал в место, где вы обычно помещаете комментарии в свой код. Обычно вы комментируете то, что делаете в своем коде, чтобы объяснить свои намерения. Не делай этого; лучше зарегистрируйте это. Таким образом, стороннее лицо будет знать, что вы делаете, просто просмотрев файл журнала.

«Я могу найти свой код приложения читабельным, и я могу отлично справиться с этим»

На мой взгляд, это самая смертоносная конструкция «я». Вы можете исправить журналы довольно быстро. И вы можете исправить логи, не влияя на логику приложения. На каждой итерации можно добавлять логирование, не опасаясь, что что-то сломаете. Но если код не соответствует никаким правилам, кроме ваших, то нас ждут неприятности.

В Интернете есть множество стилей кодирования, которым вы можете следовать. Самое главное - следовать одному из руководств. Следуя руководству, вы признаете, что являетесь частью коллектива и что время, которое вы работаете над приложением, ограничено. В один прекрасный день вы уйдете в отставку или перейдете на другую должность. Когда придет время, ваше приложение больше не будет вашим. Он будет передан другому разработчику. Будьте к ним добры.

Будьте добры с программистами, унаследовавшими вашу кодовую базу, даже если вы являетесь единственной командой, стоящей за этим:

  • Используйте один из следующих стилей кода, найденных в Интернете. Просто погуглите. Это даст вам множество вариантов. Я предлагаю соглашение о коде Oracle и руководство по стилю Google Java для приложения Java.
  • Прочтите «Чистый код» Роберта К. Мартина. Я не могу не подчеркнуть, насколько важна эта книга для каждого разработчика, и особенно для Java-разработчика. Прочитав его, вы поймете, что все время программировали неправильно. Просто прочтите книгу, если нет. Это будет откровением.
  • Напишите модульные / интеграционные тесты. Тесты предназначены для того, чтобы предупредить нас, если кто-то изменил поведение приложения. И они также здесь, чтобы научить разработчиков, наследующих ваше приложение.
  • Используйте CI в своем приложении. Применяя CI к своему приложению, вы оставите шаблон того, как ваше приложение должно быть построено на ПК другого разработчика. Если он работает на сервере CI, он будет работать и на компьютере другого разработчика.

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

«Ошибка не в моем компоненте. Моя часть общего решения работает нормально ».

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

Для меня это нормальный ответ разработчика, который правильно выполняет свою работу. Говоря правильно, я имею в виду разработчика, который тестирует приложения в среде разработки или в локальной среде, или просто уделяет время тестированию приложения и не передает его сразу в QA. Вы не можете сердиться на хорошего разработчика, сказав это. Почему? Потому что все мы думаем, что наше приложение пуленепробиваемое. И особенно, если разработчик тестирует приложение на других компонентах. Но даже если вы такой разработчик, вы должны помнить, что ваше приложение почти всегда является лишь небольшой частью более крупной системы. Даже если вы тестировали приложение самостоятельно и протестировали его на ввод, они все равно говорят, что оно не работает должным образом.

Что мы можем сделать, если кто-то подходит к нам и говорит, что ошибка в вашем компоненте? По крайней мере, вы можете написать тест и показать, что ошибка не в вашем компоненте. Помните, мы зарабатываем деньги только тогда, когда все решение работает должным образом. Ваша цель - как можно скорее удалить подозреваемого из вашего компонента. Как только вы удалите подозреваемого, они будут искать другого подозреваемого и оставят вас в покое. И когда ваше заявление несколько раз было идентифицировано как ложное подозрение, вы заслужите уважение, и вас не будут так часто беспокоить.

В этой ситуации тот факт, что ваше приложение работает нормально, не делает его лучше. Это делает вас лучше, но в глазах клиентов вы плохо выглядите как тот, кто сделал ошибку. Мы все плохо смотрим в глазах клиентов. Только тогда, когда все компоненты будут работать должным образом, мы будем зарабатывать деньги. Будьте командным игроком и сотрудничайте с другими в выявлении компонента, вызвавшего ошибку.

Помните, мы зарабатываем деньги только в том случае, если решение в целом работает.

Спасибо за прочтение!