97 этюдов для программистов. Опыт ведущих экспертов - Пит Гудлиф
} catch (Exception x) {
return false;
}
if (Integer.parseInt(time.substring(0, 2)) > 12) {
return false;
}
Тот же самый код появлялся еще дважды с соответствующими изменениями в смещении символов и в значении верхней границы, чтобы проверить правильность минут и секунд. Заканчивался метод следующими строками, проверяющими AM и PM:
if (!time.substring(9, 11). equals("AM") &
!time.substring(9, 11). equals("PM")) {
return false;
}
Если ни одно из этого ряда условий не оказывалось ложным (при этом возвращается false), метод возвращал true.
Если приведенный код кажется слишком многословным и трудным для понимания, не волнуйтесь. Мне тоже так показалось, и я решил, что нашел код, который стоит подчистить. Я переработал его и написал несколько модульных тестов, чтобы проверить, по-прежнему ли правильно работает новый код.
Закончив работу, я остался доволен результатами. Новый вариант легко читался, был вдвое меньшего размера и точнее, поскольку прежний код проверял только верхнюю границу часов, минут и секунд.
Когда я собирался на работу на следующий день, меня посетила идея: а почему бы не проверить правильность строки с помощью регулярного выражения? Через несколько минут у меня была рабочая реализация, состоящая всего из одной строки кода:
public static boolean validateTime(String time) {
return time.matches("(0[1–9]|1[0–2]):[0–5][0–9]:[0–5][0–9] ([AP]M)");
}
Смысл не в том, что в итоге мне удалось заменить 30 с лишним строк кода одной, а в том, что пока я не отошел от компьютера, мне казалось, что мой первый вариант был лучшим решением задачи.
Поэтому, когда вы в следующий раз столкнетесь с неподатливой задачей, сделайте себе одолжение. По-настоящему разобравшись в сути проблемы, займитесь чем-то, что включит творческую часть вашего мозга: нарисуйте схему проблемы на бумаге, послушайте музыку или просто выйдите из дома. Иногда лучшее, что вы можете сделать, чтобы решить задачу, — это бросить мышь и отойти от клавиатуры.
Читайте код
Карианне Берг
Мы, программисты, странные создания. Мы любим писать код. Но что касается чтения кода, мы обычно сторонимся этого дела. В конце концов, писать код гораздо увлекательней, а читать код трудно — иногда почти невозможно. Особенно тяжело читать код, написанный другими. Не всегда из-за того, что он плохо написан, но потому, что другой человек думает и решает задачи иначе, чем вы. А вам не приходило в голову, что чтение чужого кода может помочь улучшить ваш собственный код?
Когда вы в следующий раз будете читать какой-нибудь код, остановитесь и задумайтесь. Трудно его читать или легко? Если трудно, то почему? Он плохо отформатирован? Система именования непоследовательна или нелогична? Несколько задач смешались в одном фрагменте кода? Возможно, выбранный язык затрудняет чтение кода. Старайтесь учиться на чужих ошибках, чтобы не повторять их в своем коде. Вас могут ожидать сюрпризы. Например, приемы разрыва зависимостей могут быть полезны для введения слабого связывания, но они могут также затруднить чтение кода. А код, который одни считают элегантным, другие могут назвать нечитаемым.
Если код читается легко, обратите на него внимание и посмотрите, нельзя ли чему-то научиться у этого кода. Возможно, в нем применяется шаблон проектирования, который вам не знаком или который вы пытались реализовать ранее. Или он содержит методы более короткие и более точно именованные, чем ваши. В некоторых проектах с открытым исходным кодом можно встретить массу примеров великолепного, понятного кода, тогда как в других вы столкнетесь с прямо противоположным! Скачайте немного кода из репозиториев таких проектов и поизучайте его.
Чтение собственного старого кода из проекта, над которым вы больше не работаете, тоже может оказаться поучительным опытом. Начните с какого-нибудь самого старого кода и постепенно продвигайтесь к коду, который пишете сегодня. Возможно, вы обнаружите, что читать старый код совсем не так легко, как было в то время, когда вы его писали. Ваш ранний код может вызвать у вас определенное смущение, типа того, которое испытываешь, когда тебе рассказывают о том, что ты говорил накануне вечером, выпивая в пабе. Посмотрите, как с годами росло ваше мастерство; это может стать весьма ободряющим открытием. Выясните, какие части кода тяжело читать, и подумайте, продолжаете ли вы писать код в том же стиле сегодня.
Итак, когда вы в следующий раз почувствуете необходимость улучшить свое мастерство программирования, не беритесь за книги. Читайте код.
Читайте гуманитарные книги
Кейт Брэйтуэйт
Во всех проектах, кроме самых маленьких, люди работают с другими людьми. Во всех исследовательских областях, кроме самых абстрактных, люди пишут программы для людей, чтобы помочь им достичь определенную цель. Люди пишут программы вместе с людьми и для людей. Этот бизнес строится вокруг людей. К сожалению, программистов обучают тому, что мало помогает им в общении с людьми, для которых и с которыми они работают. К счастью, существует целая область знаний, которая может в этом помочь.
К примеру, Людвиг Витгенштейн (Ludwig Wittgenstein) в своей книге «Philosophical Investigations»[23] (Wiley-Blackwell) и других работах весьма убедительно утверждает, что ни один человеческий язык не является — и не может являться — форматом сериализации для передачи идей или образов из головы одного человека в голову другого. Нам следует помнить об этом уже тогда, когда мы «собираем требования». Витгенштейн также показывает, что наша способность понимать друг друга связана не с общими определениями, а с единым опытом и образом жизни. Возможно, по этой причине у программистов, глубоко вникающих в предметную область, все получается лучше, чем у тех, кто держится от нее в стороне.
Лакофф (Lakoff) и Джонсон (Johnson) в своей книге «Metaphors We Live By»[24] (University of Chicago Press) утверждают, что язык в значительной степени метафоричен и что метафоры языка позволяют нам заглянуть в собственное восприятие мира. Даже такой на первый взгляд конкретный термин, как денежный поток (cash flow), употребляемый нами в разговоре о финансах, может быть понят метафорично: «деньги — это жидкость». А как эта метафора влияет на наши представления о системах, оперирующих деньгами? Или другой пример: мы говорим об уровнях в стеке протоколов, где есть протоколы высокоуровневые, а есть низкоуровневые. Это сильная метафора: пользователь — «вверху», а технологии «внизу». Метафора вскрывает наше представление о структуре системы, которую мы строим. Она также может означать привычку мыслить шаблонно, которую мы
