Учитывая, что разницы между разработчиком программного обеспечения и программистом практически не существует, программист/разработчик должен изучить множество аспектов приложения, которое разрабатывает его компания.
Помимо технической стороны, когда дело доходит до навыков решения проблем, следует уделять больше внимания и человеческой стороне ошибок.
В этой статье позвольте мне перечислить 3 навыка, которые я считаю очень важными и развивались в течение определенного периода времени.
Определите человеческую ошибку
Чаще всего дефекты, возникающие в более низких (непроизводственных) средах, заканчиваются тем, что возникают проблемы с тестовыми данными или тестовым сценарием.
Прежде чем вытаскивать все логи и переводить свою IDE в режим отладки, проанализируйте и оцените ситуацию.
Сценарий годный? Данные испытаний точны?
Хуже всего, убедитесь, что нужный код доступен в среде, в которой возник дефект.
Необходимые навыки? Четкое понимание бизнес-требований.
Знайте компоненты
Как программист, вы выполнили кодирование в соответствии с требованиями, протестировали модуль и интеграцию и развернули его в тестовой среде.
Ваш код сейчас не работает, как бы вы решили эту проблему?
Получите общее представление о различных системах и программных компонентах, задействованных в вашем приложении.
Ваш код может не работать из-за следующих гипотетических сценариев:
- Ответ от внешней системы не такой, как ожидалось.
- Не удалось получить ответ от одного из сторонних API, и ваш код так и не был выполнен.
- Асинхронные сообщения создаются, но служба потребителя, в которой написан ваш код, не использует сообщения, и ваш код не выполняется.
Забавный факт: третий сценарий произошел в реальности, и мой код был изменен гением без всякой причины. В тот момент я не знал, как определить проблемы Кафки :D
Любая из этих и других проблем может возникнуть в реальной жизни, и вы должны иметь базовые знания о множестве сторон, участвующих в вашем приложении.
Необходимые навыки? Вики-страница для документирования архитектуры приложения и базовых навыков для понимания компонентов.
Изолируйте ошибку
Максимально изолируйте проблему, прежде чем использовать какие-либо технические знания для решения ситуации.
Начните с основных вопросов, таких как
- Когда проблема была замечена? С каких пор это происходит? журналы или инструменты мониторинга могут помочь вам определить это.
- Что-то изменилось в тот момент? Произошла ли миграция БД? Было ли развертывание кода? Произошло ли в это время какое-либо обновление программного обеспечения? Было ли плановое техническое обслуживание в это время? Начните с самых основных вопросов.
- Если это было связано с развертыванием кода, проверьте историю коммитов и подтвердите новые изменения. Если это было исправление, проверьте любую другую службу, использующую тот же продукт.
- Если получение данных не удается, проверьте правильность сохранения данных из приложения и т. д.
Большая часть процесса изоляции проблем не связана напрямую с вашими техническими способностями к разработке программного обеспечения или концепций программирования. Это больше касается вашего базового понимания различных частей приложения.
Если x и y потребляют z, а y не работает, проверьте, работает ли x нормально, если да, скорее всего, проблема связана с y, а если нет, то проверьте z.
За свою карьеру я устранил множество проблем с программным обеспечением, и некоторые из них касались систем и служб, с которыми я напрямую не работал. Мое руководство доверяло мне, привлекая меня к любому производственному сортировочному звонку, и заключалось в моей способности сузить проблему до ее источника. Как упоминалось ранее, я редко приписываю эту способность своим техническим навыкам, все это Аналитика.
Нужны ли навыки? Логическое мышление.
Заключение
Надеюсь, вы найдете эту статью полезной. Расскажите мне о некоторых нетехнических навыках, которые вы использовали на работе для решения проблем в своем приложении.
