Transcription
В типичной среде разработки ваш кодовая база, вероятно, интегрирована с внешними сервисами, такими как базы данных, внешние серверы или интеграции API со сторонними приложениями. Теперь, между вами и вашей командой, существуют устные и неустные правила относительно того, как вы должны взаимодействовать с этими системами, а также правила относительно того, как вносить изменения в ваши кодовые базы. Теперь, когда вы используете клиент для внесения изменений в вашу кодовую базу, важно, чтобы эти правила были переданы клиенту, чтобы он мог ориентироваться в вашей существующей настройке, следуя стандартам кодирования. Клиент позволяет вам хранить и организовывать эти правила в выделенной сессии, называемой правилами клиента. И вы можете задаться вопросом, как решить, что поместить в раздел правил клиента? Точно так же, как и любому новому разработчику, который присоединяется к вашей команде, любая соответствующая информация, которую вы обычно передавали бы им для онбординга, может быть изложена как правила клиента. Общие варианты использования правил клиента включают принципы кодирования, практики безопасности, рекомендации по документированию, стиль кодирования и даже правила схемы базы данных. И, как мы видели ранее, если ваша система имеет API-соединения или пользовательские интеграции за пределами вашей кодовой базы, стоит изложить, как клиенты должны взаимодействовать с системой, как отдельный документ в правилах клиента. И, подобно тому, как плохо написанный запрос может привести к плохим результатам, плохо написанные правила клиента также могут привести к несогласованному опыту. Распространенным примером этого являются расплывчатые правила, такие как "оптимизировать код, где это возможно" или "использовать правильную технику кодирования" или даже "документировать, где вы считаете нужным". Хотя клиент сделает все возможное, чтобы следовать этим правилам, которые вы изложили, проблема в том, что фразы, такие как "где это возможно", "правильный" и "когда вы думаете", могут привести к неоднозначным случаям, которые приводят к тому, что правила иногда применяются, а иногда нет. Лучший способ оптимизировать это был бы следующим. Оптимизируйте код, когда модульный тест занимает более 100 миллисекунд, или используйте SOLID-принципы при использовании классов. И, наконец, добавляйте встроенные комментарии, когда код делает предположения. Как вы можете видеть, эти правила более конкретны и не полагаются на усмотрение модели, а скорее на эмпирический порог, который активируется, когда он соответствует этому критерию. Другим примером плохо написанного правила клиента являются противоречивые правила, где два правила противоречат друг другу. Например, если ваш принцип кодирования гласит "использовать camelCase для имен классов", в то время как ваш документ по стилю кодирования гласит "использовать snake_case для имен классов", то эти два правила теперь находятся в прямом конфликте друг с другом и могут привести к несогласованному опыту. Вместо этого вы можете использовать более широкий охват для общих правил, таких как "использовать camelCase для имен классов", сохраняя при этом правила, специфичные для языка, такие как "для кода Python все имена классов должны быть в snake_case". Таким образом, правила фактически дополняют друг друга, а не мешают. По мере роста ваших вариантов использования клиента важно относиться к правилам клиента как к живому документу. Требования и стандарты постоянно меняются, и базовая кодовая база Azure развивается. Важно поддерживать эти правила в актуальном состоянии и правильно настраивать их, чтобы получать более согласованные результаты от клиента. Имейте в виду, что раздел правил клиента предназначен для правил, касающихся вашей кодовой базы, а не для бизнес-требований, которые относятся к отдельной области, называемой документами клиента. Правила клиента — это мощный способ познакомить клиента с вашей командой и заставить его думать и вести себя так же, как и все остальные. После правильной настройки клиент будет лучше оснащен, чтобы помочь вам с вашими задачами по кодированию, оставаясь при этом в рамках предпочтений вашей организации.