За годы профессиональной деятельности у меня сформировалось мнение, что по большей части программный код пишется «на коленке», «в спешке», «под страхом дедлайна» и так далее и тому подобное.
Этот код не только не всегда рефакторится, но и почти никогда.
Такой код может быть трудно понять позже.
Я не жалуюсь, я понимаю, что такое положение вещей и оно вряд ли радикально изменится.
Но! Есть вещи (конечно, давно известные, как и большинство других), о которых разработчики часто непростительно забывают, но которые могут сделать их, как и других людей, счастливее — когда придет время раскопать написанный ими когда-то код. 1. Дайте понятные имена вашим функциям, методам, классам и переменным.
Когда ваш код полон имен вроде «s», «ss» и «sss» — и каждая из этих переменных имеет свой тип и назначение — хочется выть волком, особенно когда они постоянно используются в методе, который имеет длину полтысячи строк.
Не используйте сокращения , если только они не понятны всем на 100 процентов (например, глупо называть переменную класса DOMДокумент — " document_object_model_document ", однако часто нехорошо называть объект класса Коллекция клиентов — " SS ": если эта переменная используется в длинном методе, есть риск путаницы).
Современные средства разработки предоставляют множество вариантов автодополнения, поэтому не стоит экономить на символах, снижающих понятность кода.
Не следует давать имена двух методов, отличающиеся одной или двумя буквами.
(иногда выбор этой буквы совершенно случаен и не поддается логике).
Часто становится невозможно понять, в каких случаях следует использовать один метод, а в каких другой, поэтому приходится искать в коде прецеденты использования, чтобы понять, что к чему.
Название должно отражать смысл объекта! 2. Разделяй и властвуй.
Разделите программу на небольшие части.
Понятно, что когда делаешь одну довольно объемную задачу, возникает соблазн писать и писать лист одной функции, пока задача не будет выполнена.
Но вы сами не заметите, как копируете сначала одну часть, потом другую — и программа рискует превратиться в полный копипаст самой себя.
3. Старайтесь избегать длинных списков параметров в функциях и методах.
.
Обычно вам следует ограничиться не более чем тремя (однако это мое личное мнение, и вы можете устанавливать свои собственные соглашения).
Часто бывает, что вы хотите добавить в функцию ненужный там параметр, что только излишне усложнит вызовы функций.
Посмотрите — может быть, есть возможность выделить отдельную функцию, которая будет выполнять небольшую часть работы, за которую отвечает этот новый параметр.
Всемогущие, универсальные функции часто плохи, потому что они монолитны.
4. Пишите комментарии.
Да.
Пишите комментарии – к методам, функциям и классам.
К неочевидным местам кода, к «временным» «заплаткам» (они обычно длятся дольше, чем вы думаете, и впоследствии могут привести к крайнему недоумению).
Если вы комментируете подпись метода или функции, обязательно меняйте комментарий при изменении самой подписи, особенно если ваша IDE использует комментарии для всех видов автозаполнения (например, именно так ведут себя IDE для PHP).
5. Старайтесь избегать длинных методов и больших файлов исходного кода.
В них сложно ориентироваться.
Провести рефакторинг: можно конечно, убрав дублирование, убрав из кода ненужные зоны ответственности (вынеся его в отдельный блок) - уменьшить размер исходного кода.
Теги: #разработка #рефакторинг #чистота кода #Чулан
-
Основы Сравнения Программного Обеспечения
19 Oct, 24 -
Получение Правильного Текстового Файла
19 Oct, 24 -
Роснано И Сколково Могут Закрыться
19 Oct, 24 -
15 Мая – День Осведомленности О Доступности.
19 Oct, 24 -
История Вестоуна
19 Oct, 24 -
Фриланс – Это Практика. 4 Года Спустя
19 Oct, 24 -
Пасхальное Яйцо В Блокноте И Калькуляторе
19 Oct, 24
