Перевод статьи «Become a Better Developer By Doing a Few Things».
У хороших программистов часто бывают общие хорошие привычки. Это паттерны поведения, которые выделяют их на фоне коллег и способствуют продвижению по карьерной лестнице. В этой статье мы рассмотрим несколько таких паттернов.
Умение отвечать за свои действия
Разработчики должны брать на себя ответственность за свою работу. Работая над любой задачей, нужно следить за тем, чтобы делать все правильно.
Кроме того, мы должны отвечать за качество кода, который выпускаем в широкий мир. Это означает, что в случае возникновения проблем не следует перекладывать свою вину на других. Во-первых, это не поможет делу, а во-вторых, уронит вас в глазах окружающих.
Предоставление нескольких вариантов действий
Когда в нашей работе случаются проблемы, нужно давать стейкхолдерам несколько вариантов решения проблемы. Это гораздо лучше, чем придумывать несколько вариантов оправданий, которые никак не помогут справиться с возникшими затруднениями.
Укрощение энтропии в программах
Если не придерживаться определенной дисциплины при написании кода, программа быстро погружается в хаос. В результате в будущем с ней становится очень сложно работать.
Энтропия это хаос и беспорядок. Если разработчик не уделяет целенаправленного внимания чистоте кода, его код неизбежно (и очень быстро) засоряется.
Чтобы с нашими программами было легко работать не только нам, но и нашим коллегам, мы должны минимизировать энтропию. Код нужно чистить и не допускать, чтобы он докатился до состояния неподдерживаемого.
Исправление сломанного
Чтобы не раздражать наших клиентов и пользователей наших программ, нужно регулярно и вовремя исправлять в коде все, что сломалось.
Это не значит, что нужно немедленно посвятить все свое время поиску ошибок. Просто, когда работаете с кодовой базой и замечаете в ней какие-то неполадки, сразу же вносите быстрые правки. Позже, конечно, следует вернуться и переделать все на более высоком уровне.
Благодаря такому подходу код не превратится однажды в кучу мусора, с которой никто не захочет работать.
Умение видеть крупный план картины и не забывать о нем
Скорее всего, вам не придется работать с каждой частью большой системы. Но если вы сумеете охватить взглядом всю картину, вы сможете сделать так, чтобы «ваш» функционал лучше вписывался в систему. Это поможет избежать ситуаций, когда вы внесли изменения в своей части кода, а в результате что-то сломалось в другом месте.
Умение создавать достаточно хорошие программы
Ничто не совершенно, и программное обеспечение в том числе. Сделать каждую часть программы идеальной и при этом уложиться в заданные сроки практически нереально.
Поэтому, если мы вообще хотим выпустить продукт, следует идти на разумные компромиссы.
В идеале, все должно выпускаться инкрементально, чтобы на каждом витке вносить изменения и улучшать программу, пока она не станет достаточно хорошей.
Но это не означает, что можно писать неряшливый код в расчете на улучшение его в будущем. Каждая отдельная часть программы должна соответствовать требованиям заказчика. Но сами требования следует обсуждать с учетом имеющегося времени и четко фиксировать. У нас должен быть четкий список того, что обязательно должно быть сделано, чтобы заказчик был удовлетворен. А если уже в ходе работ мы столкнемся с какими-то ограничениями, об этом следует поставить в известность стейкхолдеров, чтобы пересмотреть требования или сроки.
Ориентация на качество
Мы определенно должны относиться к качеству как к одному из требований. Нет никаких причин, которые позволяли бы жертвовать качеством программы. Выпустив в свет недостаточно хорошую программу, пострадаем, прежде всего, мы сами.
Но программа должна быть хороша не только с точки зрения пользователя: код тоже должен быть качественным, поскольку это поможет нам в дальнейшей работе над ним.
Рассчитывая время сдачи работ, следует быть очень внимательным, чтобы ни в коем случае не пришлось жертвовать качеством продукта ради соблюдения сроков.
Заключение
Мы, разработчики, должны нести ответственность за свою работу и стараться делать ее как можно лучше в рамках выделенного времени.
Следует внимательно относиться к чистоте кода и находить способы улучшать код даже в условиях меняющихся требований. Также нужно вовремя исправлять неполадки; желательно, прежде, чем они станут проблемой для пользователя.
При определении дедлайнов следует непременно учитывать качество продукта: это хорошо как для пользователей, так и для самих разработчиков.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]