Чому програмісту краще розробити алгоритм, перш ніж починати писати код?

Чи справді відповідний алгоритм допомагає покращити якість та в кінцевому рахунку ефективність програми?

Чи можемо ми все-таки виготовити якісну програму без алгоритму?

Чи ОБОВ'ЯЗКОВИЙ алгоритм ОБОВ'ЯЗКИ в сучасному програмуванні?

Я думаю, що це питання потребує певної історичної точки зору.

Повернувшись до "старих часів" (я не є особистим свідком, тому це лише моя реконструкція тієї епохи - сміливо виправляйте мене, якщо ви пережили речі по-іншому). Простір та продуктивність HW були нульовими порівняно з сьогоднішніми. Тож все, що люди писали тоді, мало бути дуже ефективним. Таким чином, їм потрібно було багато подумати і дослідити, щоб винайти найкращі алгоритми для досягнення необхідної продуктивності простору / часу, щоб виконати роботу. Іншим фактором цього було те, що розробники працювали здебільшого над тим, що можна назвати інфраструктурою : операційними системами, стеками протоколів, компіляторами, драйверами пристроїв, редакторами тощо. Все це дуже багато використовується багатьма людьми, тому продуктивність дійсно має значення .

В наші дні нас балує неймовірний HW з багатоядерними процесорами та гігабайт пам'яті навіть у базовому ноутбуці (чорт, навіть у мобільному телефоні). Це, природно, означає, що в багатьох випадках ефективність - таким чином алгоритм - перестала бути центральною проблемою, і важливіше швидко надати рішення, ніж забезпечити швидке рішення. У нас є купа рамок, які допомагають нам вирішувати проблеми і одночасно інкапсулювати велику кількість алгоритмів . Тож навіть коли ми не думаємо про алгоритми, ми можемо дуже багато використовувати у фоновому режимі.

Однак, все ж є сфери, де результативність має значення. У цих областях вам ще потрібно подумати над своїми алгоритмами, перш ніж писати код. Причина полягає в тому, що алгоритм є центром проектування, визначаючи безліч структур даних і взаємозв'язків в навколишньому коді. І якщо ви дізнаєтесь занадто пізно, що ваш алгоритм не масштабує добре (наприклад, це O (n ³ ), тому він виглядав приємно і швидко, коли ви тестували його на 10 предметах, але в реальному житті у вас буде мільйони), це дуже важкий, схильний до помилок і займає багато часу, щоб замінити його у виробничому коді. І мікрооптимізація не допоможе вам, якщо основний алгоритм не підходить для роботи.

Просто щоб зазначити щось:

Алгоритм сам по собі є загальним покроковим рішенням вашої проблеми. Отже, якщо ви вирішили проблему, ви насправді використовували алгоритм.

Найважливішим моментом тут є те, що ви повинні використовувати алгоритми для вирішення проблеми, так чи інакше. Більшу частину часу краще подумати над своєю проблемою, перш ніж перейти до кодування - цю фазу часто називають дизайном. Але, скільки і яким чином ви це зробите, залежить від вас.

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

Редагувати:

Дійсно існує багато способів представити алгоритм, а сам код мови програмування - один із них. Однак нерідко набагато краще або простіше не вирішити всю проблему одразу, а лише окреслити, а потім заповнити пробіли, як ви йдете.

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

• Але для контуру можна використовувати реальний код. Наприклад, користувачі TDD люблять розробляти алгоритм під час кодування, і оскільки вони не можуть вирішити все це відразу, вони розробляють контур виконання програми в реальному коді та використовують макетні об'єкти (або функції, методи ..) .) як заготовки, які потрібно заповнити пізніше.

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

• Крім того, якщо ви базуєте свій алгоритм на перемиканні між станами, то діаграма стану є дуже корисною.

• Взагалі, будь-який засіб, який вам доведеться просто замалювати за ідеєю певного алгоритму, - це хороший шлях.

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

Код реалізує алгоритми. Спроба написати код, не розробивши алгоритм, схожа на спробу пофарбувати будинок перед тим, як побудувати стіни. Алгоритми були "ОБОВ'ЯЗКІ" з початку програмування.

Володіння мовою допомагає покращити якість та продуктивність. І вирішення невеликих алгоритмічних задач набагато корисніше для цього, ніж повторення одного і того ж MVC-матеріалу 100 разів.
Хоча, я гадаю, є й інші способи домогтися безоплатності.

Чи стане алгоритм ОБОВ'ЯЗКОВО у сучасній області програмування?
Це вже "обов'язково", якщо ви не якийсь "php ніндзя" пише "класний кодекз". Всі "найкращі" компанії (Google, Amazon тощо) перевіряють ваш алгоритмічний досвід в інтерв'ю, і я думаю, що вони не зробили б це без причини.

Але повертаючись до початкової точки, вам слід постійно кидати виклик собі, якщо ви хочете вдосконалюватися. А оскільки звичайні робочі місця (так само "зараз пишіть менеджери CRUD для ще 100 об'єктів") не завжди створюють хороший виклик, алгоритми це компенсують.

Я б сказав, що вам потрібно принаймні початкове уявлення про алгоритм, перш ніж почати кодування. Ви, ймовірно, переглянете свою ідею, кодуючи на основі структур даних тощо.

Пізніше ви можете переглянути код ще раз, якщо профілювання підкаже, що в цій області є проблеми з продуктивністю.

Причина в тому, що швидше виправити помилки, перш ніж ви написали код помилки.

Більш прозаїчно, регулярно вимірюються різниці в продуктивності від 10 до 1 між різними програмістами. Якщо ви подивитеся на програмістів, які знаходяться на 10-кратному рівні продуктивності, вони витрачають найменшу частину свого часу, фактично кодуючи. Час введення коду не повинен бути вузьким місцем. Натомість вони витрачають більшу частину свого часу на переконання, що вони мають чіткі вимоги, планування, тестування тощо.

І навпаки, коли ви дивитесь на програмістів, які занурюються в кодування без пауз, їм неминуче доводиться писати код знову і знову, оскільки вони стикаються з цілком передбачуваними проблемами, а кінцевий результат - менш досяжний і більший. (Ви, до речі, ви знали, що в середньому 80% грошей, витрачених на розробку програмного забезпечення, перебуває на етапі технічного обслуговування? Здійснення речей, що мають важливе значення. Багато.)

Зазвичай алгоритми та структури даних спочатку кодують пізніше. Але це багато залежить від програми програмування. Раніше я робив багато застосованих матеріалів з математики, і справді дивився на поширену тоді модель водоспаду. Це було тому, що алгоритми низького та середнього рівня рідко можна сприймати як належне. Створіть велику структуру навколо існування неписаних підсистем, а потім виявіть пізно в грі, що математика для однієї з цих найважливіших підсистем не виходить (нестабільна чи будь-яка інша). Тому я завжди думав про найскладніші підсистеми спочатку, і якщо були якісь причини для сумнівів, я писав і тестував їх першим. Але для деяких проблемних доменів ви можете просто оратись вперед, не плануючи багато.

Створіть алгоритм по розділах, потім розділіть ці розділи та кодуйте кожен з них окремо. Таким чином ви можете змішати обидві точки зору:

1. Використовуйте свої мовні можливості, щоб алгоритм працював
2. Спробуйте подумати перед кодом, щоб ваша ідея не зливалася з мовою (одного дня вам потрібно перенести алгоритм на іншу мову, і ви закінчитесь у спагетті)

Для мене це майже весь код. Я думаю, що це справедливо для більшості високопродуктивних програмістів. Я можу писати код так само легко, як і пишу текст.

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

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

Коли ви сідаєте і починаєте кодування, ви маєте на увазі алгоритм, "спроектований" чи ні.

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

1) перемішування клавіш випадковим чином. Це, ймовірно, призведе до помилки компілятора

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

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

Тож люди зазвичай програмують з алгоритмом в голові. Це може бути м'якоть або аргументована на папері чи іншому носії.

Це може бути гарною дисципліною, щоб думати про вашу атаку на проблему далеко від клавіатури, особливо в попередні дні як програміста. Як зазначалося в інших відповідях, коли ви отримуєте більш досвідчений досвід, ви можете краще кодувати ще кілька керованих фрагментів проблеми "на льоту". Однак для складних чи великих проблем корисне мислення та проектування далеко від клавіатури: якщо ви займаєтесь кодом, ви, швидше за все, думаєте з точки зору конструкцій мови та як підійти до найбільш безпосереднього завдання в проблема. Тоді як думка про проблему, скажімо, з ручкою та папером, звільняє вас більше від мовного аспекту коду та дозволяє думати на більш абстрактному рівні.

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

Чи справді відповідний алгоритм допомагає покращити якість та в кінцевому рахунку ефективність програми?

Чи допомагає відповідний план / схеми будівництва ефективно будувати якісний будинок?

Чи можемо ми все-таки виготовити якісну програму без алгоритму?

Чи можете ви побудувати хороший якісний будинок ефективно без відповідного плану забудови? Відповідно до теореми нескінченної мавпи , ймовірно, так (так само мільйон мавп, які друкують навмання на вічність, врешті-решт наберуть цілі твори Шекспіра.

Чи ОБОВ'ЯЗКОВИЙ алгоритм ОБОВ'ЯЗКИ в сучасному програмуванні?

Якщо ви не хочете бути кодовою мавпою і хочете переконатися, що ви не постачаєте програмне забезпечення, яке виглядає і працює як лайно, так, це обов'язково. Кожен проект, який мені довелося врятувати (оскільки код виглядав як незрозуміле лайно), незмінно починався з негативної відповіді на це питання.

Насправді сучасне програмування відійшло від інженера-програміста ковбойського програмування, де планується якесь планування .

Навіть коли у вас є бібліотека алгоритмів і структур даних (. .Ie. Збільшення C ++ або бібліотека колекцій Java), ви повинні знати, як працює цей матеріал, щоб використовувати його належним чином і складати його на розумні, вищі, алгоритми рівня.

Це не краще. Краще нічого не «проектувати». Тобто для людей, які не пишуть програм. Ви знаєте, люди з реальним досвідом проблеми. Якщо ви математик, інженер або логіст, добре, вам потрібно працювати над процесом в іншому місці. Але це не «програмування».

Поставте на перше місце тест і орієнтир.

Тоді напишіть щось, що завгодно. Робіть refactor-переписувати -loop, поки не закінчиться час або не зможете більше вдосконалитись.

Хоча багато хто, здається, думають, що можна робити речі з комп’ютером, насправді нічого не роблячи на комп'ютері, я думаю, що це один з найпоширеніших міфів. Архітектура космонавтизмів.

Також ви не можете оптимізувати свій algo до його написання.

IOW, "тримайтеся близько до металу".