Базовые принципы и практики разработки чистого кода

Культовый разработчик Кент Бек сформулировал принципы написания ПО, которые в вольном изложении звучат приблизительно так:

1. Заставь код работать.
2. Сделай его понятным.
3. Оптимизируй для лучшей производительности.

Этим основам не один десяток лет, однако джуны (да и старшие порой, будем честны:) спотыкаются уже на втором шаге. В результате получается рабочий, но нечитаемый код, который не просто трудно понять — его нельзя дополнить или исправить, не поломав программу.

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

Обычно до оптимизации дело так и не доходит: важные участки кода скорее «заморозят» и запретят вносить в них изменения, чем перепишут. Беда, если именно в них будет крыться экономическое преимущество системы.

Чистый код существует?

В четком виде теории чистого кода не существует: авторы тематических книг опираются на субъективный опыт и порой противоречат друг другу. В конце концов, всё зависит от задач, которые выполняет код. Однако мы можем выделить несколько эффективных принципов, которые применимы в большинстве случаев.

Принципы написания чистого кода

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

Пример (Java):

public void assign(Author author, Book book) {   book.setAuthor(author);   book.save(); }

По названию метода нельзя определить, что в нём происходит. Это плохо. Конкретизируем имена, и код объяснит сам себя:

public void assignAuthorForBook(Author author, Book book)  {   book.setAuthor(author);   book.save(); }

2. Оставляйте комментарии в сложных участках. Пусть они будут нечастыми, но содержательными. Идеальный код можно понять без дополнительной документации.

Пример (Dart):

Комментарии могут связать код с реальностью и дать объяснение, почему мы решили закодить именно так.

///! category && product открывают одинаковый экран /// Это нужно для обработки диплинков /// Так как на вебе в url может быть либо products, либо category GoRoute(   path: CatalogueRoutes.productsItem.path,   name: CatalogueRoutes.productsItem.path,   builder: (context, state) => CategoryPage(     key: state.pageKey,     slug: state.pathParameters['slug']!,     args: state.extra as CategoryArgsModel?,   ), ), GoRoute(   path: CatalogueRoutes.categoryItem.path,     name: CatalogueRoutes.categoryItem.path,     builder: (context, state) => CategoryPage(       key: state.pageKey,       slug: state.pathParameters['slug']!,       args: state.extra as CategoryArgsModel?,   ), ),

3. Наводите красоту пустотами. Пробелы, табы и отступы помогут разделить код на логические секции и сделать его удобным для чтения.

Пример (Javascript):

function filterPermissions(permissions, searchQuery) { const q = searchQuery.trim().toLowerCase() if (!q) return permissions const searchDeep = (permission) => filterTree(permission, ({title}) => title.toLowerCase().includes(q)) return permissions.map(searchDeep).filter((v) => v) }

Такими кирпичами только стены строить. Добавим отступы, выстроим лесенку, и наш увесистый блок превращается в прекрасный читабельный код:

function filterPermissions(permissions, searchQuery) {     const q = searchQuery.trim().toLowerCase()      if (!q) {         return permissions     }      const searchDeep = (permission) => filterTree(       permission,       ({title}) => title.toLowerCase().includes(q)     )      return permissions         .map(searchDeep)         .filter((v) => v) }

4. Отбрасывайте ненужное. После рефакторинга сразу удаляйте участки, которые больше не несут практической ценности. Не оставляйте на случай «вдруг пригодится» — удалённый кусок всегда можно отыскать в истории Git-а.

Пример (go):

//test_banner := model.Banner{ID: 1, FeatureId: 45, TagIds: []int32{5, 12, 244}}   if !banner.IsActive {     log.Warn("attempt to get inactive banner")     //return model.Banner{ID: -1, FeatureId: -1, TagIds: []int32{}, content {"forbidden! - empty"}}     return nil, fmt.Errorf("banner {id:%d, featureId:%d, tagIds:%v} is inactive",     banner.ID, banner.FeatureId, banner.TagIds)   }

Тестовые строчки в комментариях засоряют код и мешают нормальному чтению. Их нужно сносить беспощадно.

Подведем итоги

Чистый код не только «легко читается». В первую очередь мы говорим о грамотном проектировании системы, которое дает нам куда большие преимущества:

— Код легко расширить без технических затрат. Сущности не связаны между собой слишком тесно. 

— Код стабилен и предсказуем. Если появляется проблема, мы уже знаем, куда смотреть. 

P.S.

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

Кстати, как вам материал? Если хотите больше таких – пишите в комментах, нам будет приятно 🙂