Extract Method, позволяющая выделить фрагмент кода и сделать из него метод. Средства рефакторинга найдут все параметры, которые нужно передать методу, благодаря чему становится чрезвычайно просто модифицировать код. Моя IDE даже найдет другие фрагменты кода, которые можно заменить вызовом этого метода, и спросит у меня, следует ли это сделать.
Другая замечательная возможность современных IDE — способность принуждать к соблюдению стиля, принятого в компании. Например, в Java некоторые программисты стали объявлять все параметры final (на мой взгляд, это пустая трата времени). Тем не менее раз такое правило установлено, мне достаточно задать его в настройках IDE, и я стану получать предупреждения для всех параметров, которые не объявлены как final. С помощью правил стиля можно также искать возможные ошибки, такие как проверка равенства автоматически упакованных (autoboxed) объектов посредством ссылочной семантики, как в случае использования оператора == для примитивов, упакованных в соответствующие объекты.
К сожалению, современные IDE не требуют, чтобы мы прилагали усилия к освоению этих самых IDE. Когда я начал программировать на C под UNIX, мне пришлось потратить немало времени, чтобы научиться работать в редакторе vi, что обусловлено его кривой обучения. Но потраченное на старте время сторицей окупилось с годами. Даже черновик этой статьи набран в vi. У современных IDE кривая обучения такая, что мы никогда не выходим за пределы базовых приемов работы с ними.
Первое, что я делаю при изучении IDE, — запоминаю управляющие сочетания клавиш. Когда я набираю код, пальцы лежат на клавиатуре, и нажатие Ctrl+Shift+I позволяет встроить переменную (операция рефакторинга Inline Variable), не нарушая рабочего потока, тогда как навигация по меню указателем мыши отвлекла бы меня. Такие отвлечения создают ненужные переключения контекста и значительно снижают мою продуктивность, если я пытаюсь делать все «ленивым» образом. То же справедливо в отношении владения клавиатурой: освойте печать вслепую, и вы не пожалеете о потраченном времени.
Наконец, у программистов есть проверенные временем конвейерные UNIX-утилиты, позволяющие манипулировать кодом различными способами. Например, если при рецензировании кода я замечаю, что программисты назвали многие классы одинаково, я легко могу обнаружить эти повторения с помощью утилит find, sed, sort, uniq и grep, например:
find. -name ”*.java” | sed ’s/.*\///’ | sort | uniq — c | grep — v ”~ *1 " | sort — rМы ожидаем, что посетивший нас сантехник умеет пользоваться паяльной лампой. Давайте же потратим немного времени и поучимся более эффективно работать со своими IDE.
Знай свои возможностиГрег Колвин
Нужно знать предел своих возможностей.
Ваши ресурсы ограничены. Отведенные на выполнение работы время и деньги определены конкретно, в том числе время и деньги, необходимые для поддержания ваших знаний, навыков и инструментов на современном уровне. Существует предел интенсивности, скорости, изобретательности и длительности для вашей работы. Возможности ваших инструментов ограничены. Мощность машин, для которых вы пишете программы, ограничена. Поэтому вы должны учитывать пределы своих ресурсов.
Как учесть эти границы? Нужно знать себя, своих сотрудников, свой бюджет и свою технику. Инженеру-программисту нужно знать пространственно-временную сложность своих структур данных и алгоритмов, архитектуру и показатели производительности своих систем. Ваша задача — создать оптимальное сочетание программного обеспечения и систем.
Пространственная и временная сложность задаются в виде функции О(f(n)), где n равно размеру входных данных. Эта функция определяет асимптотическое поведение памяти или времени для n, стремящегося к бесконечности. Важные классы сложности для f(n) — это ln(n), n, n In(n), ne и en. Как ясно видно из графиков этих функций, когда n растет, O(ln(n)) становится гораздо меньше O(n) и O(n ln(n)), а те, в свою очередь, становятся гораздо меньше O(ne) и O(en). В формулировке Шона Пэрента (Sean Parent): для практически достижимых n все классы сложности близки к функциям констант, линейным либо бесконечным.
Анализ сложности осуществляется в терминах некой абстрактной машины, но программы работают на реальных компьютерах. Современные компьютерные системы образуют целые иерархии физических и виртуальных машин, включающие библиотеки времени выполнения для языков программирования, операционные системы, процессоры, кэш-память, оперативную память, жесткие диски и сети. В приведенной таблице показаны пределы времени произвольного доступа к данным и пределы емкости памяти для типичного сервера, подключенного к сети.
Заметим, что вариативность памяти и скорости составляет несколько порядков. Для компенсации различий на всех уровнях системы интенсивно применяется кэширование и упреждающий просмотр, но они действенны только тогда, когда доступ предсказуем. Если часто происходят кэш-промахи, система будет тормозить. Например, случайное чтение каждого байта на жестком диске может занять 32 года. Даже случайное чтение каждого байта оперативной памяти может занять 11 минут. Случайный доступ непредсказуем. А что предсказуемо? Зависит от системы, но обычно выигрыш приносят повторный доступ к недавно считанным данным и последовательный доступ к элементам данных.
Алгоритмы и структуры данных различаются эффективностью использования кэша. Например:
• Линейный поиск эффективно использует упреждающий просмотр, но требует O(n) сравнений.
• Двоичный поиск в отсортированном массиве требует всего O(log(n)) сравнений.
• Поиск по дереву ван Эмде Боаса (van Emde Boas) имеет сложность O(log(n)) и нечувствителен к кэшу.
Что выбрать? Для окончательного анализа нужны измерения. В таблице ниже показано время поиска в массивах 64-разрядных целых чисел с помощью этих трех методов. На моем компьютере:
• Линейный поиск составляет конкуренцию другим методам на малых массивах, но проигрывает экспоненциально на больших.
• Поиск ван Эмде Боаса побеждает без вариантов благодаря схеме предсказуемого доступа.
Каждый сам решает, что для него лучше.
Знай, что сохранишь в репозиторийДэн Берг Джонссон
Я похлопал трех программистов по плечу и поинтересовался, чем они заняты. «Я провожу рефакторинг этих методов», — был ответ первого. «Я добавляю кое-какие параметры в эту веб-операцию», — отвечал второй. Третий сказал: «Я работаю над этим сценарием использования».
Может показаться, что первые двое были поглощены деталями своей работы, и только третий видел картину шире, и его подход лучше. Я поинтересовался, когда и что они собираются поместить в репозиторий, и тут картина резко изменилась. Первые два вполне ясно представляли, какие это будут файлы, и собирались закончить работу примерно в течение часа. Третий сказал: «Предполагаю, что закончу через несколько дней. Наверное, я добавлю некоторые классы и как-то модифицирую службы».
Дело не в том, что два программиста не обладали цельной картиной происходящего. Они просто выбрали задачи, которые, по их мнению, вели в нужном направлении и могли быть выполнены за пару часов. Покончив с этими задачами, они выберут новую функцию или рефакторинг для работы. Таким образом, они писали свой код, исходя из четко обозначенных задач и имея небольшую, но реалистичную цель.
Третий программист оказался неспособен провести декомпозицию задачи и работал сразу по всем направлениям. Он не имел представления о том, во что это выльется, и в принципе занимался рискованной работой в надежде, что в какой-то момент у него появится код для записи в репозиторий. Вероятнее всего, написанный на старте этого долгого предприятия код оказался малопригодным для того решения, которое получилось в итоге.
Как поступили бы первые два программиста, потребуй их задачи более двух часов работы каждая? Поняв, что не рассчитали свои силы, они, скорее всего, отказались бы от внесенных изменений, выбрали задачи помельче и начали все сначала. Продолжай они работу, произошла бы расфокусировка, а в репозиторий попал бы сомнительный код. Лучше отбросить сделанные изменения, но сохранить понимание сути.
Третий программист, возможно, продолжил бы свои гадания и в отчаянии старался бы сшить из своих заплаток код, который можно сохранить в репозиторий. В конце концов, как же можно выбрасывать внесенные изменения — ведь это будет означать, что вы напрасно трудились! К сожалению, если не выбрасывать такой код, в репозиторий попадает слегка странноватый код, не решающий определенную задачу.
Бывают моменты, когда даже программисты, которые ориентированы на частое сохранение кода в репозиторий, не могут найти ничего полезного, с чем бы они могли справиться за пару часов. Тогда они переходят в режим написания ненадежного кода и балуются с кодом, но, конечно, выкидывают свои изменения, когда некое озарение возвращает их на путь истинный. Даже такие бессмысленные, на первый взгляд, периоды работы имеют цель: лучше изучить код, чтобы суметь выявить задачу, решение которой принесет немедленную пользу.
Определите, что сдадите в репозиторий на сей раз. Если не удается завершить задачу, удалите свои изменения и определите новую задачу на основе приобретенного понимания. Займитесь рискованными экспериментами, если это необходимо, но следите за тем, чтобы случайно и незаметно не соскользнуть в режим написания сомнительного кода. Не помещайте в репозиторий плоды рискованных экспериментов.