Потому что в идеальном мире удобочитаемость и ремонтопригодность были бы северной звездой каждого программиста.

TL;DR

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

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

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

Но что вы можете сделать, чтобы сделать удобочитаемость и удобство обслуживания вашей северной звездой?

1. Сделайте свой TS Config как можно более строгим

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

Вот некоторые из наиболее полезных правил, которые вы можете включить в файле TSconfig:

"strict": флаг strict позволит использовать широкий диапазон проверки типов, что приведет к более надежным гарантиям правильности программы. Если вы включите это, вы включите все параметры семейства строгих режимов. Если вы хотите включить только часть строгого семейства (см. Ниже), нет необходимости включать strict.

"strictNullChecks": установите для этого правила значение true, чтобы избежать значительного количества ошибок Javascript; особенно популярная ошибка времени выполнения 'undefined' is not a function, часто вызываемая ошибками в коде JavaScript. С strictNullChecksenabled TypeScript не позволит вам использовать переменную, неизвестную компилятору (исключение должно быть сделано с использованием переменных anytyped, подробнее об этом позже).

"strictBindCallApply": это правило также очень полезно, поскольку оно проверяет правильность вызова встроенных методов функций call, bind и apply.

"strictFunctionTypes": если включено, параметры функции проверяются более корректно. Однако это правило не применяется к функциям, написанным в синтаксисе method, только для синтаксиса function.

"forceConsistentCasingInFilesNames": включение этого правила будет полезно, если вы работаете над проектом, в котором разработчики используют другую ОС, потому что это предотвратит проблемы, связанные с оболочкой файла и тем, как файлы упоминаются в коде. Таким образом, TypeScript выдаст ошибку, если программа попытается включить файл с корпусом, отличным от корпуса на диске.

"noImplicitAny": TypeScript выдает ошибку всякий раз, когда обнаруживает тип any. Это правило действительно строгое и, вероятно, его трудно реализовать в больших базах кода или базах кода, переходящих на TypeScript.

"noImplicitThis": TypeScript вызовет ошибку, если ваш код подразумевает anytype в thisexpressions.

"noImplicitReturns": если вы включите это правило, TypeScript проверит все пути кода в функции, чтобы убедиться, что они действительно возвращают значение.

"noUnusedParameters": включение этого вызовет ошибки для неиспользуемых параметров в функциях.

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

2. Используйте инструмент линтера и форматтера.

Почему так важно иметь читаемый, хорошо отформатированный и чистый код TypeScript? Потому что это позволит программистам сосредоточиться на том, что у них получается лучше всего, и на том, что им нравится больше всего: реализовать бизнес-логику, повысить производительность, улучшить архитектуру кодовой базы, создать библиотеку пользовательского интерфейса… вы называете это!

Использование инструментов линтера и форматирования (ESlint, Prettier…) обеспечит единообразие вашей кодовой базы и сделает вашу команду более счастливой. И все мы знаем, что счастливая команда - это эффективная команда! Сохраняя ваш TypeScript в чистоте с помощью линтеров и форматеров, вы избегаете долгих споров среди программистов по поводу отсутствия точек с запятой или отступов (о, радость!)

Ваша кодовая база станет:

  • легче читать и начинать с новых участников
  • легче просмотреть
  • легче рефакторинг
  • более счастливое место, где у программистов меньше трений

3. Согласуйте архитектуру проекта.

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

Если вы работаете над сольным проектом или в команде, вы всегда будете вознаграждены, если согласитесь и будете следовать четкой структуре проекта. Это позволит вам:

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

4. Используйте возможности парного программирования для решения сложных задач.

Почему вам следует чаще рассматривать возможность объединения в пару с товарищем по команде? По многим веским причинам!

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

Спасибо за чтение и удачного кодирования! 😀

Статья изначально опубликована на Dev.to.