От джуна до сеньора

Тезисы

■ Разные языки программирования предоставляют различный уровень абстракций.

■ Используйте ровно тот уровень абстракций, который работает для вашей задачи.

■ Пишите просто – этот код придется поддерживать вам и вашим коллегам (а они могут знать, где вы живете).

Задание

Узнайте, какой уровень абстракций предлагает язык программирования вашего проекта. Проанализируйте код проекта: есть ли негласные правила использования тех или иных возможностей языка разработчиками? Попробуйте решения, которые можно выполнить с меньшим уровнем абстракций, сделав код более интуитивным и простым.

История из жизни

Однажды при найме нового разработчика я получил от него тестовое задание, которое включало в себя довольно простую задачу: в ней требовалось реализовать веб-приложение, позволяющее редактировать текстовые заметки. Обычно кандидаты ограничиваются минимальным набором необходимых классов и компонентов, но на сей раз это оказалась целая заготовка большой системы, состоящей из интерфейсов, трейтов, абстрактных классов, фабрики заметок и прочего. При личной встрече я первым делом задал вопрос: «Почему вы решили так усложнить задание?» На что получил более чем достойный и ожидаемый (в душе) ответ: «Я просто готовился к тому, что эту систему придется в дальнейшем расширять».

Оптимизация

Оптимизация – это способ сделать уже написанный код более быстрым, менее требовательным к ресурсам и более отвечающим нуждам задачи, которую он выполняет. Оптимизация возможна почти для любого написанного кода, но в большинстве случаев она нужна только в конкретных местах проекта.

Задачи оптимизации кода, его быстродействия крайне важны, и отчасти вы уже оптимизируете код, даже не осознавая этого. Многие языки программирования включают механизмы оптимизации в свои инструменты: в компиляторы, интерпретаторы и среды выполнения. Эти формы оптимизации помогают коду даже без вашего ведома (я очень рекомендую прочитать, как именно оптимизирует себя ваш язык программирования, это будет очень полезно).

Разные области разработки программного обеспечения требуют разной степени оптимизации. Есть определенный баланс: оптимизируя код, вы часто жертвуете стройностью его логики, красотой реализации, удобством архитектуры или частью функций системы.

Из этого следует первое правило: никогда не начинайте оптимизацию до того, как код будет удовлетворять всем требованиям проекта. Дональд Кнут (пожалуйста, прочитайте про этого прекрасного человека) сформулировал это правило так: «Преждевременная оптимизация – корень всех зол»[3] – и был, несомненно, прав. В вопросах оптимизации необходимо идти от обратного: не от отсутствия кода к его появлению, а от существующего кода к его упрощению и ускорению.

Второе правило оптимизации: убедитесь в том, что вы оптимизируете нужный код.

Прежде чем приступать к любой оптимизации, следует как минимум сделать профилирование кода. Необходимо знать все медленные места проекта, все бутылочные горлышки (bottlenecks, да, ознакомьтесь с этим). Чем больше вы получите информации о проекте, тем лучше сможете проанализировать и спланировать дальнейшую оптимизацию.

Как уже говорилось, чаще всего оптимизация на готовом проекте представляет собой баланс: на одной чаше весов – скорость и безотказность работы после оптимизации, на другой – простота понимания кода, удобство его использования или часть функций, от которых придется отказаться. Вы не сможете склонить чашу весов ни в одну из сторон, пока проект не будет удовлетворять всем требованиям и пока вы не будете знать, какие именно места в системе делают ее медленной и неоптимальной.