Алгоритмы, с помощью которых мы разрабатываем программное обеспечение

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

Его метод

Начните работу над этой функцией в начале дня. Если вы не закончите к концу дня, удалите все и начните сначала на следующий день. Вам разрешается сохранять написанные вами модульные тесты.

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

Он сказал, что не он это изобрел, но это было связано с движением экстремального программирования конца 90-х и начала 00-х.

Несколько мыслей о методе

«Пиши все дважды»

Совет, который я даю начинающим инженерам, — писать все дважды. Решите проблему. Сохраните свой код в ветке. Затем напишите весь код снова.

Я открыл для себя этот метод случайно, после того как сдох ноутбук, на котором хранилось несколько дней работы. Переписывание решения заняло всего 25% времени от первоначальной реализации, а результат оказался намного лучше.

Таким образом, вы получаете, возможно, в 2 раза более качественный код за 1.25 времени — этот способ обычно хорошо подходит для проектов, которые вам придется поддерживать в течение длительного времени.

N.B. Очевидно, что не стоит писать буквально все дважды. Это эвристика. Применяйте ее с умом.

Метод «каждый день начинать сначала» — еще более экстремальная версия этого. Каждый раз, когда вы переписываете текст, вы прокладываете более гладкий путь к решению. Конечное решение может быть очень, очень чистым.

«Количество само по себе имеет качество»

Почти наверняка апокрифическая цитата Сталина применима к тому, чтобы стать хорошим инженером-программистом. Для начинающего инженера просто нет замены первым 100 тысячам строк кода за плечами. Метод «каждый день начинать сначала» поможет вам быстрее добраться до этих 100 тысяч строк.

Вы можете подумать, что многократное повторение одного и того же материала не так ценно, как получение разнообразных 100 тысяч строк кода. Я с этим не согласен. Многократное решение одной и той же задачи на самом деле очень полезно для сохранения знаний о закономерностях, которые вы обнаружили.

Вам нужно всего 5K идеальных строк, чтобы один раз увидеть все основные закономерности. Остальные 95 тысяч строк — это повторение, чтобы перестроить ваши нейроны.

Сравнение с эвристикой «пистолет к голове»

Еще одна эвристика, которую я использовал, — это попросить кого-то придумать решение проблемы. Возможно, человек скажет, что на его реализацию уйдет 4 недели. Тогда я говорю: «Приставляю пистолет к голове, вы должны закончить за 24 часа, что вы будете делать?».

Цель здесь — сломать рамки и предвзятое отношение. Если вы только что сказали, что на что-то уйдет месяц, то для того, чтобы сделать это за день, должно быть радикально другое решение.

Самое удивительное в этой технике — то, как часто она срабатывает. Как часто кого-то — через несколько минут после того, как он представил свой план на месяц, — можно побудить придумать план, который потенциально может быть выполнен за день.

На практике ни один из однодневных планов на самом деле не является однодневным. Пистолет не приставлен к вашей голове. Вы можете пойти домой и поспать. Но новое решение часто действительно может быть реализовано всего за несколько дней. Десятиминутный мысленный эксперимент превращается в 10-кратную экономию времени.

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

Поиск пути

Суть дела заключается в поиске путей в проблемном пространстве. Каждый путь — это решение, и задача инженера — найти лучшее из них.

Между этими эвристиками и различными алгоритмами поиска путей можно провести множество нечетких аналогий. Есть некоторая связь с итеративным углублением, ограниченным смягчением A*, лучевым поиском, имитацией отжига и другими.

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

Так же и с инженерной эвристикой. Стать лучшим инженером — значит стать лучшим искателем пути в проблемном пространстве.

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

Источник