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

В одной из компаний, где я работал, был проект медицинского архива, который использовался для сканирования файлов пациентов. Прошло почти два месяца с тех пор, как я начал работать над проектом. Был огромный спрос на новые функции со стороны клиентов, и время от времени сообщалось о нескольких ошибках, которые необходимо было исправить. Из-за большой загруженности и нехватки времени нам приходилось работать очень быстро, и, конечно же, коды, которые мы писали, были грязными и неразборчивыми, и у меня не было возможности написать документы по кодам.

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

Чистый код

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

Мартин Фаулер говорит в этом посте:

Программные системы склонны к созданию мусора — недостатков внутреннего качества, из-за которых дальнейшее изменение и расширение системы становится сложнее, чем в идеале. Технический долг — это метафора, придуманная Уордом Каннингемом, которая определяет, как думать о том, как бороться с этим хламом, думая о нем как о финансовом долге. Дополнительные усилия, необходимые для добавления новых функций, — это проценты, выплачиваемые по долгу.

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

1 – Чистые коды понятны и удобочитаемы для других программистов, которые хотят разрабатывать код.

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

2 – Чистые коды не содержат повторяющихся блоков, методов или классов.

Если в вашем проекте есть фрагмент кода, который делает одно и то же, но повторяется в нескольких разных местах, я должен сказать, что вы проделали плохую работу. Допустим, у вас есть три метода, целью которых является преобразование одной МОДЕЛИ в DTO. или ViewModel, если вы реализуете код, который выполняет преобразование в каждом методе отдельно, с более или менее свойством A, вы должны изменить все три метода. А теперь представьте, что это будет происходить в большем масштабе, например, размером с модель 30. Это потратит на вас много энергии и времени.

3. Чистые коды часто бывают небольшими

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

  • Не допускайте, чтобы количество строк в наших кодах превышало 30 (независимо от пустых строк и комментариев).
  • Не допускайте, чтобы количество методов в классе превышало 30.
  • Объем строк в классе не превышает 900 строк.
  • Количество классов в DLL или пакете не должно превышать 30.

До сих пор мы говорили о читабельности кода, неповторяемости кода и размере кода. В других разделах мы поговорим о ряде принципов, связанных с тестированием и сопровождением кода.