Рабочий мир был бы хорош, если бы мы могли только разрабатывать и поддерживать наш собственный код. Причина в том, что мы по своей сути понимаем концепции, рабочий процесс и логику внутри него. Но, как и любой работающий разработчик, которого я когда-либо знал, включая меня самого, наши дни полны поддержки существующих программ — иногда это процесс не для сердца.
Как давний программист, часто с персоналом других программистов, за которым я следил, в начале своей карьеры я узнал, как важно соблюдение стандартов программирования для общего успеха проекта. Стандарты не только влияют на создание кода отдельным пользователем, но и гарантируют, что любой, кто может внести код позже, может сделать это с разумным ожиданием согласованности.
Мой собственный опыт показал, что, хотя практика нестандартного кодирования встречается во всем спектре, от новичка до опытного профессионала, подавляющее большинство нарушений, по-видимому, происходит с новичками, программистами начального уровня или программистами с минимальным контролем. Почему, можно спросить? Просто! Супервайзеры разработчиков не выполнили свою ответственность за поощрение стандартной практики кодирования.
Что такое стандартные методы кодирования? Там нет ни одной книги; нет одного интернет-сайта; нет одного генерального плана, который описывает такие стандарты. О, есть стандарты форматирования, широко используемые в определенных кругах. Но для большинства локальных проектов, которые я видел за 35 с лишним лет анализа и проектирования, обычно существует только полуофициальный план стандартизации, который был решен кем-то, кто-то, кто отвечает за разработку проекта. Неважно, какими являются стандарты, поскольку они отражают ожидания в отношении кодирования и документирования. Хотя иногда существуют правила, которые нужно нарушать, стандарты должны меняться только в лучшую сторону, чтобы приложение дало еще лучшие и более согласованные результаты.
И так, что должно быть стандартизировано? Простой ответ … все! С точки зрения менеджера проекта это будет включать соглашения об именах программ, имена полей, имена функций, макеты отчетов, макет базы данных, процедуры тестирования, платформы разработки и т. Д. Вы увидите, как усилия по стандартизации со временем свяжут все компоненты проекта. , чтобы сформировать одну однородную сущность, которая станет намного более понятной, более понятной в будущем, а также намного более легко поддерживаемой.
Так что же делать, когда нет существующих стандартов? Два слова: создай их. Я признаю, что создание нового стандарта для всего не является тривиальной задачей, но вы обнаружите, что усилия приведут к продуктивным результатам. Вам не нужно создавать их с нуля — многие проекты с открытым исходным кодом опубликовали свои стандарты и рекомендации в Интернете, и вы можете использовать их в качестве основы для своих собственных; Вы можете выбрать один оптовый или выбрать элементы из нескольких, в зависимости от того, что имеет наибольшее значение для вашей команды. Это не так важно, как стандарты, а скорее наличие стандартов.
Если вы программист нижнего уровня, всегда следуйте всем установленным стандартам. Если стандарт может быть улучшен или расширен, обсудите его со своим руководителем, который должен приветствовать ваши комментарии с энтузиазмом. Если вы руководитель, приветствуйте такие предложения. Даже если вы являетесь программистом из одного человека, вы получите большую выгоду, если вы потратите время на создание собственных стандартов, а затем будете придерживаться их на протяжении всего процесса разработки проекта.
Надеемся, что эта информация не попадет на глухие уши (или глаза в зависимости от обстоятельств). Промышленный опыт доказал, что установление стандартов и их соблюдение дает лучшие производственные результаты и облегчает повседневную жизнь благодаря заказу, который с ними идет. Мой личный опыт также говорит мне, что как только кто-то внедряет и работает со стандартами, они никогда не возвращаются.
Изображение через oconner / Shutterstock