Оптимизация кода.

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

Как вы считаете, что такое оптимизированный код? Многие разработчики ответят просто - чем лучше код, тем он оптимизированее. Однако, понятие оптимизированного кода несколько емче, чем может показаться на первый взгляд. Далеко не всегда хороший код является залогом хорошей работы вашего программного продукта, а гоняясь за изяществом и быстродействием, можно потерять суть проблемы, потратить много времени на ее решение и/или вовсе не решить ее. Четкий и системный подход - вот ключ к оптимизации вашего кода.

Я приведу некоторые примеры:

Несколько дней назад я случайно повстречался со знакомым разработчиком, команда которого получила заказ на создание информационной системы для организации. Однако, как это часто бывает, задача была сформулирована едва ли не в словесном виде. Команда не потрудилась составить проекта самостоятельно, и, как результат - они сами плохо понимают, работают ли плоды их трехмесячного труда и как это происходит. Следует ли говорить, что отладка и сопровождение подобной системы - дело неблагодарное? Этот реальный пример хорошо отражает потребность любой задачи в формализации, а формализация в свою очередь, играет большую роль в повышении производительности ПО. Пишете ли вы необъятную систему, которая будет управлять всем, начиная от заварки кофе, и заканчивая прицеливанием орбитального телескопа "Хаббл", или пишете крошечный компонент для чего-то иного - составьте проект. В крайнем случае набросайте общую структуру, цели и порядок их достижения, UML-диаграмму - все это составит некий каркас, логический скелет вашего продукта, который позже обрастет мышцами кода и кожей пользовательского интерфейса. Именно он поможет глубоко понять задачу, и умостит ее в вашем сознании.

Мало ли живых примеров того, как неправильная разработка требований сожгла колоссально много времени? Проанализируйте, что требуется данной задаче, руководствуясь принципом "Лечи, что наболело". Ненужный функционал вынудит вас потратить много времени и ничего не даст взамен. Подумайте, сколько дополнительного времени, вы бы потратили на разработку компонента, который строил бы графики за 10 секунд, когда необходимое время составляет, скажем, 25 секунд?

Анализ "проблемных областей" по моему мнению - достаточно важная деталь. На этапе проектирования, пронанализируйте те части вашего программного продукта, который может "страдать" низкой производительностью. Как пример - взаимодействие системы с внешними источниками данных, такими как база данных или файлы. Многократное обращение к базе данных, увы, не будет способствовать повышению производительности. Постарайтесь перенести всю работу с данными в оперативную память.

Кнут утверждал, что менее 4% кода обычно соответствуют 50% времени выполнения программы. Если выделить эти 4% кода, то можно весьма существенно изменить производительность вашей программы. Важно помнить - подобные "популярные" куски кода разумно искать и исправлять уже после написания программы, ведь иначе сложно увидеть полную картину сложившейся структуры.

Понятие пользовательского интерфейса не слишком коррелирует с кодом, и всем, что с ним связанно. Но следует помнить, что выполнение вышенаписанного, а также невероятной кучи рекомендаций, написанных ветеранами-разработчиками, не гарантирует удобной работы с вашей программой. Представим, что у вас есть приложение для управления записями в вашем блоге. Оно суперэргономично, невероятно шустро и греет сердце одним фактом своего существования. А на блоге у вас 50 записей, половину из которых вы не прочь удалить. Здесь всплывает небольшая проблема - с помощью этого приложения, нельзя совершать действия с постами комплексно. То есть для удаления половины записей, вам придется выполнить одно и то же действие ровно 25 раз. Монотонно. Скучно. И совсем неважно, насколько быстро работает сам алгоритм удаления - скорее всего вы не будете больше пользоваться этой программой.