Как архитектура систем улучшила мои навыки программирования

Перевод статьи «How Architecture Improved My Coding Skills».

Сейчас я лучший программист, чем был раньше

Последние пару лет я больше занимался архитектурой приложений (на глубоком уровне) и техническим писательством, чем непосредственно созданием кода на своей IDE. Этим летом я вернулся к разработке, включившись в новый проект. К моему удивлению, даже несмотря на «хромоту» моего синтаксиса, сейчас я куда лучший программист, чем был раньше. В этой статье я хотел бы рассказать, что именно изменилось в моем мыслительном процессе и моих подходах к написанию кода.

Крупный план

Первое изменение в себе, которое я заметил, — изменение перспективы. Я больше не фокусируюсь на своем тикете, игнорируя все остальное. Теперь я обращаю внимание на то, какое место в общей системе занимает моя задача, задумываюсь, почему вообще работаю над ней. Я осознаю тот факт, что вносимые мной изменения повлияют на другие тикеты и системы.

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

Юзабилити на первом месте

Когда я говорю об основных целях, я имею в виду, что теперь у меня (среди прочего) есть понимание, что успешное завершение задачи это нечто большее, чем эффективный цикл for. Также я пришел к осознанию того, что мы не должны рассчитывать на дальнейший рефакторинг, напротив — следует уделять время тому, чтобы заранее делать все правильно. Такие вещи как отзывчивый дизайн, доступность, интернационализация должны продумываться с самого начала.

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

То, что теперь я задумываюсь обо всех этих вещах, делает меня куда более сильным программистом. И это еще раз напоминает нам о том, что наши навыки выходят далеко за пределы синтаксиса.

Кодинг

Умение расставлять приоритеты

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

Моя способность видеть картину крупным планом и понимание того, какой функционал является самым важным, позволяют мне осознанно идти на возможные компромиссы.

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

Раньше я, скорее всего, и не подумал бы ставить под сомнение необходимость работы над моим тикетом. Но теперь я довольно часто понимаю, что моя работа над какой-то задачей будет не в интересах проекта и команды. Это не значит, что нужно постоянно пытаться изменить масштаб своих задач. Нет, делать это нужно только если в результате изменений преимуществ будет больше, чем недостатков.

Осознание проблем интеграции

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

Теперь, поработав с архитектурой систем, я хочу знать каждую точку интеграции в своем коде. Мне обязательно нужно понять все сложности, проблемы и потенциальные edge cases.

Как это разворачивается? Будет ли этот формат данных совместимым в разных системах? Передаю ли я всю необходимую информацию?

Концентрация на безопасности

Еще один пункт, на котором теперь я фокусируюсь гораздо больше, чем раньше, это вопросы безопасности. Обычно в проектах существуют всеохватывающие планы обеспечения безопасности, но к каждому отдельному тикету не прикрепляются какие-то конкретные задачи этих планов. Когда я пишу код, мне нужно знать, какая часть плана обеспечения безопасности касается моих фич.

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

Вопросы безопасности

Коммуникация

Это самая существенная перемена, произошедшая во мне. Раньше я думал, что лучший способ показать, на что я способен, это взяться за задачу и довести ее до конца. Со временем я понял, что чаще всего источник провалов проектов — люди и команды. Недостатки коммуникации и координации могут приводить к серьезным проблемам.

Сейчас, заметив какие-то конфликты в проекте, я с куда большей вероятностью громко заявлю об этом. Я скорее «пингану» коллегу, чтобы что-то перепроверить, чем пущу все на самотек. Теперь я знаю, какое огромное влияние на конечный продукт могут оказать ошибки всякого рода.

Заключение

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

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

1 комментарий к “Как архитектура систем улучшила мои навыки программирования”

  1. Евгений

    Просто отличная статья. Которую, как мне кажется, всем нужно, как можно раньше понять и применять на практике.

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх