Почему программисту лучше спроектировать алгоритм перед тем, как начать писать код?

Действительно ли соответствующий алгоритм помогает улучшить качество и, в конечном итоге, эффективность программы?

Можем ли мы создать качественную программу без алгоритма?

НЕОБХОДИМО ли соответствующий алгоритм в современном программировании?

Я думаю, что этот вопрос требует некоторой исторической перспективы.

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

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

Тем не менее, есть еще области, где производительность имеет значение. В этих областях вам еще нужно много подумать о своих алгоритмах, прежде чем писать код. Причина в том, что алгоритм является центром проектирования, определяющим множество структур данных и взаимосвязей в окружающем коде. И если вы узнаете слишком поздно, что ваш алгоритм плохо масштабируется (например, это O (n ³ ), поэтому он выглядел хорошо и быстро, когда вы проверили его на 10 элементах, но в реальной жизни у вас будет миллионы), это очень сложно, подвержено ошибкам и отнимает много времени, чтобы заменить его в рабочем коде. И микрооптимизации не помогут вам, если фундаментальный алгоритм не подходит для работы.

Просто чтобы указать на что-то:

Алгоритм сам по себе является общим пошаговым решением вашей проблемы. Итак, если вы решили проблему, вы фактически использовали алгоритм.

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

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

РЕДАКТИРОВАТЬ:

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

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

• Но реальный код может быть использован для набросков. Например, люди, работающие в TDD, любят разрабатывать алгоритм по мере их кодирования, и, поскольку они также не могут решить его все сразу, они создают схему выполнения программы в реальном коде и используют фиктивные объекты (или функции, методы). .) в качестве пробелов для заполнения позже.

• Диаграммы UML Activity, похоже, представляют собой современное воплощение потоковых диаграмм старого стиля с добавленной нотацией для таких новых вещей, как полиморфизм и многопоточность. Я не могу сказать, насколько это полезно, потому что я не особо их использовал - я просто упомянул это для полноты.

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

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

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

Код реализует алгоритмы. Попытка написать код без разработки алгоритма - это все равно что попытаться нарисовать дом до того, как будут построены стены. Алгоритмы были "ДОЛЖНЫ" с самого начала программирования.

Свободное владение вашим языком помогает улучшить качество и производительность. И решение небольших алгоритмических задач гораздо более полезно для этого, чем повторение одного и того же материала MVC 100 раз.
Хотя, я полагаю, есть и другие способы достичь беглости.

Станет ли алгоритм обязательным в современной области программирования?
Это уже «обязательно», если только вы не «php ninja», пишущий «классный код». Все «лучшие» компании (Google, Amazon и т. Д.) Проверяют ваш алгоритмический опыт на собеседовании, и я думаю, что они не будут делать это без причины.

Но возвращаясь к исходной точке, вы должны постоянно испытывать себя, если вы хотите улучшить. А поскольку обычные задания (то есть «теперь пишут CRUD-менеджеры для еще 100 объектов») не всегда обеспечивают хорошую задачу, алгоритмы это компенсируют.

Я бы сказал, что вам нужно хотя бы начальное представление об алгоритме, прежде чем вы начнете кодировать. Скорее всего, вы будете пересматривать свою идею при кодировании на основе структур данных и т. Д.

Позже вы можете снова пересмотреть код, если профилирование предполагает, что в этой области есть проблемы с производительностью.

Причина в том, что быстрее исправить ошибки, прежде чем вы напишете ошибочный код.

Более прозаично, что между разными программистами обычно измеряется разница в производительности 10: 1. Когда вы смотрите на программистов, которые имеют 10-кратный уровень производительности, они тратят наименьшую часть своего времени, фактически кодируя. Время ввода кода не должно быть узким местом. Вместо этого они тратят большую часть своего времени на выполнение требований, планирование, тестирование и т. Д.

И наоборот, когда вы смотрите на программистов, которые погружаются в кодирование без паузы, им неизбежно приходится писать код снова и снова, поскольку они сталкиваются с полностью предсказуемыми проблемами, а конечный результат менее понятен и более ошибочен. (Между прочим, вы знали, что в среднем 80% денег, потраченных на разработку программного обеспечения, находятся на этапе обслуживания?

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

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

1. Используйте свои языковые возможности, чтобы заставить работать algorthm
2. Постарайтесь подумать перед кодом, чтобы ваша идея не сливалась с языком (однажды вам нужно переместить свой алгоритм на другой язык, и вы закончите со спагетти)

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

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

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

Когда вы садитесь и начинаете кодировать, вы имеете в виду алгоритм, «разработанный» или нет.

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

1) перемешивание ключей случайным образом. Это, вероятно, приведет к ошибке компилятора

2) написание компилируемого кода, который, вероятно, делает все, кроме того, что вы хотите, чтобы он делал

3) написание кода для решения небольших частей проблемы и наращивание его по мере агрегации, но на самом деле не забегая вперед - так что в конечном итоге проблема решена - но код не очень эффективен, и с возможность отказаться и тратить время на пути

Поэтому люди обычно программируют с алгоритмом в голове. Возможно, это было раскрыто или рассуждено на бумаге или другом носителе.

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

Вы должны перестать рассматривать конструкцию программного обеспечения как нечто фундаментальное из конструирования чего-либо еще ценного. Не то. Так что, как и все остальное, всегда нужен продуманный план или дизайн, пусть и лаконичный.

Действительно ли соответствующий алгоритм помогает улучшить качество и, в конечном итоге, эффективность программы?

Соответствующий план здания / схемы помогают эффективно построить качественный дом?

Можем ли мы создать качественную программу без алгоритма?

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

НЕОБХОДИМО ли соответствующий алгоритм в современном программировании?

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

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

Даже когда у вас есть библиотека алгоритмов и структур данных (.ie. Boost в C ++ или библиотека коллекций Java), вы должны знать, как работает этот материал, чтобы использовать его надлежащим образом и объединять в разумные, более высокие алгоритмы уровня.

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

Сначала поместите какой-нибудь тест и эталон.

Тогда напишите что-нибудь, что угодно. Делайте refactor-rewrite -loop до тех пор, пока не закончится время или вы уже не сможете улучшить.

Хотя многие, кажется, думают, что можно что-то делать с компьютером, фактически ничего не делая на компьютере, я думаю, что это один из самых распространенных мифов. Архитектура космонавтики.

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

IOW, "держись поближе к металлу".