Некоторые другие вещи, о которых стоит подумать…
Остерегайтесь логического отрицания (NOT). Всегда представляйте, что другой программист, которому предстоит поддерживать ваш код, – новичок, и вам надо ему помочь. Новичка очень легко сбить с толку конструкциями типа if (not customer_number is null)… Если вы постараетесь, чтобы код содержал как можно меньше отрицаний, вам самим будет проще его читать. Возможно, стоит подумать и о том, чтобы добавить метод для определения номера клиента. Конструкцию if (isValid(customer_number))… будет легче читать будущим кодерам.
В качестве примера того, как можно ускорить работу и при этом не спешить, я расскажу о своем подходе к большим сложным проектам по обслуживанию.
• Прежде чем изменить какую-либо часть кода, я один раз прохожусь по всему коду в целом, чтобы уловить, какие данные тут задействованы и что код в целом делает.
• Затем я рефакторю[21] код. Обычно я трачу день на переработку кода, разбивая большие методы на множество более мелких. Я ищу логические отрицания и преобразую код в позитивный. Я ищу сегменты кода с отступами более одного или максимум двух уровней и выделяю их в отдельные методы. Я ищу длинные методы, выполняющие десять различных действий, и разбиваю их на десять отдельных методов. Я ищу избыточный код и выделяю его в отдельный метод или класс. (Примечание: в процессе этой работы надо добавить комментарии, которые могут быть полезны будущим разработчикам и вам самим.)
• Затем я удостоверяюсь, что код по-прежнему выполняет то, что делал раньше.
Рефакторинг позволяет мне «проникнуть внутрь» программного кода и понять, что он делает. На этом этапе кажется, что проект стоит на месте или даже откатывается. Но после рефакторинга у меня уже есть понимание, сколько времени займет проект, и база исходного кода, с которой я могу работать. Что еще более важно, этой базой сможет воспользоваться другой программист, не проходя через ту же боль, что прошел я.
Еще несколько «правил» разработки программного обеспечения, большинство из которых основаны на здравом смысле и до боли очевидны, но я все равно включу их сюда:
• Используйте самоочевидные имена переменных и методов. Звучит как что-то из самого базового курса программирования, но поразительно, как много на свете программистов, которым об этом надо напоминать. Старайтесь не использовать имена переменных типа «foo» или «x». Гораздо лучше имена типа customer_number.
• Не используйте для одной и той же цели два разных имени переменных. Если в одном месте кода у вас будет переменная cust_num, а в другом месте те же данные будут обозначаться другой переменной customer_number, вы запутаетесь. Если нужно, определяйте где-то имя переменной, и не пишите его по-разному – например, db.customer_number и input.customer_number.
• Конечный пользователь не должен сидеть без дела. Это философия проектирования, а не стандарт программирования, но об этом определенно стоит подумать, работая с кодом. Конечным пользователям (людям, которые в итоге пользуются программой) трудно долго концентрироваться на одном предмете. Я всегда придерживался правила «семи секунд». Человека, сидящего перед компьютером, нужно каким-то образом задействовать каждые семь секунд. Может, и семь раз в секунду, но… я лично готов потерпеть в худшем случае семь секунд. Даже если это означает просто попросить пользователя «Нажмите ввод», нужно чем-то его занять. Не позволяйте ему скучать.
21
Рефакторинг – это своего рода «редактура» кода, целью которой является его очистка: от дублирования методов, слишком больших блоков, длинных списков, лишних классов и других нагромождений, затрудняющих чтение. –