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