Потому что в идеальном мире удобочитаемость и ремонтопригодность были бы северной звездой каждого программиста.
TL;DR
- Сделайте свою конфигурацию TS как можно более строгой, чтобы вы могли согласовать соглашения об именах, избегать ошибок ввода и т. Д.
- Используйте инструменты линтера и форматирования, чтобы ваша команда могла сосредоточиться на реальном деле
- Согласуйте архитектуру проекта
- Используйте возможности парного программирования для решения сложных задач
Не пытайтесь абстрагироваться настолько, чтобы ваш товарищ по команде (и, скорее всего, вы в будущем) не смог понять ваш код позже. При работе в команде часто самой важной проблемой является чтение и понимание чужого кода. Сосредоточение внимания на удобочитаемости и ремонтопригодности не только поможет вам прочитать и реорганизовать код через два месяца, но также поможет всей команде стать более продуктивной, эффективной и, в целом, счастливой!
Читаемые и обслуживаемые кодовые базы также являются ключевыми, когда дело доходит до масштабирования вашего приложения. При запуске нового проекта лучше начать с простого и малого с прочным и ясным фундаментом, чем чрезмерно разрабатывать свое приложение, даже не зная, где будет ваш проект через несколько месяцев.
Но что вы можете сделать, чтобы сделать удобочитаемость и удобство обслуживания вашей северной звездой?
1. Сделайте свой TS Config как можно более строгим
Если можете, сделайте свой TS Config строгим. Для начала у вас может быть масса ошибок, но это того стоит, поскольку вы получите все преимущества лучшей безопасности типов.
Вот некоторые из наиболее полезных правил, которые вы можете включить в файле TSconfig:
"strict":
флаг strict позволит использовать широкий диапазон проверки типов, что приведет к более надежным гарантиям правильности программы. Если вы включите это, вы включите все параметры семейства строгих режимов. Если вы хотите включить только часть строгого семейства (см. Ниже), нет необходимости включать strict
.
"strictNullChecks":
установите для этого правила значение true
, чтобы избежать значительного количества ошибок Javascript; особенно популярная ошибка времени выполнения 'undefined' is not a function
, часто вызываемая ошибками в коде JavaScript. С strictNullChecks
enabled TypeScript не позволит вам использовать переменную, неизвестную компилятору (исключение должно быть сделано с использованием переменных any
typed, подробнее об этом позже).
"strictBindCallApply":
это правило также очень полезно, поскольку оно проверяет правильность вызова встроенных методов функций call
, bind
и apply
.
"strictFunctionTypes":
если включено, параметры функции проверяются более корректно. Однако это правило не применяется к функциям, написанным в синтаксисе method, только для синтаксиса function.
"forceConsistentCasingInFilesNames":
включение этого правила будет полезно, если вы работаете над проектом, в котором разработчики используют другую ОС, потому что это предотвратит проблемы, связанные с оболочкой файла и тем, как файлы упоминаются в коде. Таким образом, TypeScript выдаст ошибку, если программа попытается включить файл с корпусом, отличным от корпуса на диске.
"noImplicitAny":
TypeScript выдает ошибку всякий раз, когда обнаруживает тип any
. Это правило действительно строгое и, вероятно, его трудно реализовать в больших базах кода или базах кода, переходящих на TypeScript.
"noImplicitThis":
TypeScript вызовет ошибку, если ваш код подразумевает any
type в this
expressions.
"noImplicitReturns":
если вы включите это правило, TypeScript проверит все пути кода в функции, чтобы убедиться, что они действительно возвращают значение.
"noUnusedParameters":
включение этого вызовет ошибки для неиспользуемых параметров в функциях.
Для полной справки вы можете проверить официальную документацию здесь.
2. Используйте инструмент линтера и форматтера.
Почему так важно иметь читаемый, хорошо отформатированный и чистый код TypeScript? Потому что это позволит программистам сосредоточиться на том, что у них получается лучше всего, и на том, что им нравится больше всего: реализовать бизнес-логику, повысить производительность, улучшить архитектуру кодовой базы, создать библиотеку пользовательского интерфейса… вы называете это!
Использование инструментов линтера и форматирования (ESlint, Prettier…) обеспечит единообразие вашей кодовой базы и сделает вашу команду более счастливой. И все мы знаем, что счастливая команда - это эффективная команда! Сохраняя ваш TypeScript в чистоте с помощью линтеров и форматеров, вы избегаете долгих споров среди программистов по поводу отсутствия точек с запятой или отступов (о, радость!)
Ваша кодовая база станет:
- легче читать и начинать с новых участников
- легче просмотреть
- легче рефакторинг
- более счастливое место, где у программистов меньше трений
3. Согласуйте архитектуру проекта.
Как отметил Дэниел Ирвин в этой статье, почти всегда самая большая проблема, которую я вижу, - это межличностные проблемы, возникающие из-за разногласий по поводу направления и структуры проекта.
Если вы работаете над сольным проектом или в команде, вы всегда будете вознаграждены, если согласитесь и будете следовать четкой структуре проекта. Это позволит вам:
- легче набирать новых сотрудников
- структурированный и понятный способ навигации по проекту
- найти нужные файлы быстрее
- лучше реорганизовать свой код, так будет легче увидеть более широкую картину в вашем проекте
- в целом, повысьте свою продуктивность и довольствуйтесь работой над своим проектом
4. Используйте возможности парного программирования для решения сложных задач.
Почему вам следует чаще рассматривать возможность объединения в пару с товарищем по команде? По многим веским причинам!
- Это весело и создает сплоченность в команде, которым нельзя пренебрегать, поскольку в конечном итоге это, скорее всего, улучшит общую базу кода.
- Это позволяет быстрее и лучше распространять знания между командами, особенно если программист, ведущий сеанс, знаком с частью кодовой базы, которую не знает другой товарищ по команде.
- Наряду с той же идеей, парное программирование позволит лучше передавать навыки младшим разработчикам, поскольку они могут перенимать советы и уловки от более опытных разработчиков, что ведет к более быстрому росту.
- Обычно при парном программировании вы и ваш товарищ по команде программируете вслух, что в конечном итоге приводит к обнаружению скрытых элементов в коде и более четкому пониманию сложностей.
Спасибо за чтение и удачного кодирования! 😀
Статья изначально опубликована на Dev.to.