Чому деякі програмісти вважають, що існує протиставлення теорії та практики? [зачинено]

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

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

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

За моїм досвідом, я б сказав, що поки вам не потрібно багато теорії, щоб зібрати 100-рядковий сценарій (хата), для розробки складного додатку (10-поверховий будинок) вам потрібна структурована конструкція, ну -визначені методи, хороша мова програмування, хороші підручники з текстами, де можна шукати алгоритми тощо.

Таким чином, теорія ІМО (потрібна кількість) є одним із інструментів для виконання справ .

Моє запитання: чому деякі програмісти думають, що існує протиставлення теорії (формальних методів) та практики (виконання речей)?

Чи сприймається багатьма простою інженерія програмного забезпечення (будівельне програмне забезпечення) порівняно з, скажімо, будівництвом (будівництво будинків)?

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

Я намагаюсь підсумувати, що я зрозумів з відповідей поки що.

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

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

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

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

Багато програмістів мали поганий досвід, коли теорія побіжної діяльності стала активною перешкодою для виконання завдань (наприклад, "виконуваний UML", надбюрократичні процеси розвитку). І навпаки, брудні хаки та патчі можуть зробити вас досить чортовим далеко, хоча і в кінці кінців. І як ви зауважуєте в своєму останньому абзаці: провали, як правило, не такі остаточні і, отже, не такі проблемні.

Інженерія програмного забезпечення та цивільне будівництво мають мало спільного. Зусилля цивільного будівництва обмежені фізичними властивостями матеріалів та навколишнього середовища. Будівельні інженери проводять багато часу, вивчаючи властивості ґрунту та характеристики матеріалу. Розробка програмного забезпечення фізично обмежена лише швидкістю процесорів та наявним сховищем. І те й інше легко зрозуміти, і ми не витрачаємо багато часу на їх вивчення. Основним обмеженням у розробці програмного забезпечення є інтелект людини. І жоден два розробники не схожі. Чи є цей код доступним? Ким? Трирядкова реалізація кваксорту в Haskell може бути очевидно правильною для деяких, але незрозумілою для інших. Команда з двох осіб може заповнити заявку протягом місяця, тоді як інша команда з десяти намагається поставитись за рік.

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

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

У традиційній техніці

• ти повинен знати свою математику та науку, тому що все, що ти робиш, засноване на цьому
• "герої" на місцях - це люди, які вигадують нові речі, відкривають нові ідеї, вирішують проблеми, що вважаються нерозв'язними

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

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

Більше того, винахідливість не заохочується. Це не відштовхує, на користь методів групового мислення групи найменших загальних знаменників, замаскованих під "читабельність". (Уявіть собі, якби інженерів з аеронавігальної та ядерної діяльності рекомендували не робити нічого, що може бути важко зрозуміти для молодших однолітків.)

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

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

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

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

Веди зі мною на цьому. У мене є пункт.

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

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

Я був такою бідною, нещасною душею, і так, мабуть, багато з вас, напевно. Я закликаю вас усіх. Не приймайте простий вихід! :)

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

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

Загальний фактор - вартість. Проектування на традиційному проекті цивільного будівництва зменшує витрати (як фактичні, як матеріальні, так і потенційні з точки зору відповідальності), тоді як в розробці програмного забезпечення наступає момент, коли вартість проектування збільшується понад повернуту вартість.

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

Креслення архітектора / цивільного інженера практично ніколи не ідентичні планам "як побудовані". Щось ЗАВЖДИ змінюється. Чому? Тому що є і завжди будуть "невідомі невідомі". Є речі, які ви знаєте і так можете планувати, речі, які ви знаєте, невідомі, і ви можете досліджувати і оцінювати, а потім є речі, які ви не знаєте, що не знаєте; "сюрпризи". Ви прагнете усунути їх у більшості систем, вивчивши все, що можете, але все, що потрібно, - це одне невелике порушення будівельного коду (яке може базуватися на правилі, яке не існувало 2 роки тому, коли ваша будівля розроблялася) і ваших усіх -обхідний генплан повинен змінюватися, іноді досить кардинально.

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

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

Різниця полягає насамперед через відомі вимоги:

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

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

Ми використовуємо бібліотеки для подібних речей якомога більше.

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

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

Один з моїх колег, який працював у NASA, раніше описав процес розробки програмного забезпечення як написання сотень сторінок обґрунтування та сотні годин зустрічей, щоб виправдати написання єдиного рядка коду!

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

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

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

Підводячи підсумки, Premature optimization is the root of all evil або як завжди міг би сказати мій начальникShipping is a feature!

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

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

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

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

TL; DR : Теорія та практика в інженерії програмного забезпечення різні, як і скрізь. Правильною аналогією є інженерія програмного забезпечення: цивільне будівництво :: інформатика: фізика. Але на практиці це трохи складніше, ніж це :)

Отже, моє запитання: чому деякі програмісти думають, що існує протиставлення теорії (формальних методів) і практики (виконання речей)?

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

Ще один приклад можна зробити з маніпулювання даними. Часто має сенс використовувати делегатів у контексті .NET. У Java це не так просто, оскільки у нього немає рамкової підтримки функціонального стилю програмування, яку має .NET. Іншими словами, в загальному випадку зробити X в ситуації Y просто неможливо. Це пов'язано з тим, що X і Y залежать від N кількості змінних факторів.

Чи сприймається багатьма простою інженерія програмного забезпечення (будівельне програмне забезпечення) порівняно з, скажімо, будівництвом (будівництво будинків)?

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

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

Традиційна інженерія та інженерія програмного забезпечення сильно відрізняються з причин, про які я вже говорив.

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

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

Це було сказано, якщо мова йде про більшість програмістів , коли завдання написати щось до них приходить дизайн ("математики", як ви це сказали ), вже зроблено архітектором / ведучим / тощо. перш ніж завдання написати це дістанеться їм. Таким чином, це може здатися з рівня прямої лінії.

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

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

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

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

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

Я був інженером-механіком та виробником до того, як 20 років тому я виявив, що мої навички полягають у програмі. Я співчуваю багатьом елементам, які ви виклали.

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

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

Ніяких аргументів - є проекти, які потрібно починати з комітету з 17 архітекторів програмного забезпечення. Насправді вони є такими ж рідкими, як 20 каратних алмазів.

Я думаю, що аналогія є хибною. Наскільки мені відомо, цивільне будівництво не має такої теоретичної основи, як інформатика; інформатика народилася з теоретичної математики - як машини Тьюрінга. Цивільне будівництво - це створення структур, що протистоять материнській природі і, можливо, навіть виглядають красиво. Знову ж таки, я справді мало знаю про цивільне будівництво, але я не думаю, що є еквіваленти інженера-будівельника P vs NP, мандрівний продавець та інші цікаві речі, які б урізалися з вашими мізками. І для нашої теорії інформатики, безумовно, є місце - якщо хтось вирішить подорожуючого продавця або проблему, що зупиняється, у нас стоїть багато нових дивовижних успіхів. Але для інженера-програміста, який займається архітектурним програмним забезпеченням, такі проблеми справді є лише розвагою та іграми.

Тепер я також думаю, що це залежить від того, що ви маєте на увазі під "теорією". Ми говоримо про схеми дизайну чи накачуємо лему? Тому що добре розуміти шаблони дизайну абсолютно важливо, щоб бути хорошим інженером-програмістом. Однак при архітектурі великої програмної системи теоретизувати проблеми P / NP не корисно. У цьому сенсі я вважаю, що між інженерією програмного забезпечення та теоретичною інформатикою існує дуже різкий контраст.

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

Ще однією причиною є те, що в даний час існує кілька популярних ефективних методів розробки програмного забезпечення "Зроби це". Наприклад, в умовах гнучкої розробки ви не заздалегідь створили всю систему. Причина цього полягає в тому, що ви ще не знаєте, що саме будуєте - ви хочете, щоб те, що ви робите, було гнучким і адаптувалося до нової інформації та вимог. Розробляючи все це з ходу, а потім будуючи лише те, що не завжди дає найкраще програмне забезпечення. Однак це не рішення всього. Наприклад, скажіть, що ви проектуєте якусь річ розподіленого обчислення-кластера-божевільного-нового. Ви не можете зробити ескізи серветки і запустити SCRUM.

TL; DR. Я думаю, що навколо слова "теорія" є деяке орієнтування. Традиційно теорія стосується теоретичних математичних аспектів інформатики. Якщо ви не досліджуєте новіші способи обчислень, здебільшого теоретична інформатика не відіграє жодної ролі в повсякденному житті інженера-програміста. Інженери програмного забезпечення дбають про схеми дизайну та архітектуру системи. Конкретні деталі реалізації певних алгоритмів не важливі. Часто з менш складними ідеями доречно не розробляти багато і просто починати кодування. І я думаю, що саме тут іде ідея, що програмістам не подобається теорія.

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

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

Формальна теорія передбачає, що ви можете точно спланувати все заздалегідь, як виготовлений продукт, що програмне забезпечення буде існувати нескінченно в одному середовищі, і вирішення загальної абстрактної проблеми завжди є метою. Він передбачає 4D життєвий цикл програмного забезпечення як продукту: проектувати, розробляти, розгортати, робити. Формальна теорія полягає у вирішенні проблеми розробки програмного забезпечення за допомогою аналізу, абстрагування, узагальнення та прогнозування майбутніх змін. Це добре, якщо у вас чітко визначена проблема в прямому домені, який легко піддається аналізу, передбачуваному та досить статичному.

Практичне програмування - це вирішення правильної проблеми (а не розробки програмного забезпечення) правильним способом, щоб ваші колеги могли робити свою роботу краще / швидше / взагалі, або щоб доходи могли надходити в компанію. Багато програмного забезпечення не схоже на продукт, ніколи не робиться, але більше схоже на живу істоту, яка починається вузькоспеціалізованою для однієї екологічної ніші і може мати широкий термін служби, протягом якого їй потрібно вирішувати нові, небачені проблеми в широке розмаїття середовищ, що постійно змінюються. У діловому світі, з політикою та правовими нормами, конкуренцією та постійно змінюються організаціями, структурами та тенденціями, вимоги часто неоднозначні, складені різними особливими справами, погано визначені та можуть бути предметом швидких несподіваних змін. Вони не піддаються аналізу, передбачуваності або статичності, а часто не логічно чи розумно. Програмне забезпечення, ймовірно, буде нерелевантним за 2 тижні, як і раніше використовуватиметься через 20 років. Він приходить у світ, не знаючи багато чи здатний зробити багато, і його потрібно доглядати, доглядати та навчати протягом усього життя, щоб вирости сильним, гнучким та здатним адаптуватися до свого постійно мінливого середовища та нових проблем. Якщо ви нехтуєте нею після народження, вона зграє, якщо вона виживе досить довго, і спричинить біль і страждання, вирішуючи проблеми з тупою силою.

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

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

Ставки нижчі, робота легша, а керівництво рідко бачить цінність у гарному дизайні. Нестабільність, ремонтопридатність та цілісність - це проблема "ІТ", а не проблема "бізнесу". Усі керівники мають одне спільне. Вони або на 95% зосереджені на грошах, або звітують перед кимось, хто є.

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

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

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

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

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

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

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

Чи є, наприклад, модель MVC ідеально підходить, має багато спільного з цим контекстом. Настільний додаток зазвичай працює однією мовою та однією мовою, не враховуючи конфігураційні файли.

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

Очевидно, що ви не можете використовувати популярний та добре розглянутий зразок, як MVC, щоб вирішувати проблеми в інтернеті виключно, не змінюючи способи обробляти його в контексті настільних додатків. Насправді я заперечую, ви повинні знати про те, що робить MVC корисним, але навіть не намагатися реалізувати його в особливо вимогливих або оптових продажах. Парадигма веб-додатків унікальна тим, що всі переглянуті вами речі обробляються веб-переглядачем користувача, а всі дані / моделі-результати зазвичай є десь на сервері. Але де це залишає контролер? Все на сервері чи все на передньому кінці? Хтось має володіти цим. А може, MVC не на 100% найкраще підходить для сценарію. Непогано підійде для .NET резервного матеріалу. Не страшно в контексті конкретних віджетів інтерфейсу користувача.

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

Гленн Vanderburg представляє прекрасний вид на відмінностях між програмної інженерії та більш традиційними інженерними дисциплінами: http://www.youtube.com/watch?v=NP9AIUT9nos

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

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

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