Почему некоторые программисты считают, что существует противоречие между теорией и практикой? [закрыто]

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

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

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

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

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

Мой вопрос: почему некоторые программисты думают, что есть контраст между теорией (формальными методами) и практикой (что-то делается)?

Является ли программное обеспечение (строительное программное обеспечение) воспринимаемым многими как легко по сравнению, например, с гражданским строительством (зданиями)?

Или эти две дисциплины действительно разные (кроме критических программное обеспечение, сбой программного обеспечения гораздо более приемлемый, чем отказ здания)?

ИЗМЕНИТЬ

Спасибо за все ответы и интерес к этой теме. Я бы просил вас не публиковать какие-либо новые ответы, если у вас нет добавить некоторое замечание, которое еще не было охвачено существующими ответами. Поэтому, пожалуйста, внимательно прочитайте все ответы перед публикацией новых.

Я пытаюсь обобщить, что я понял из ответов до сих пор.

  1. В отличие от разработки программного обеспечения, в области гражданского строительства гораздо яснее, какой объем теории (моделирование, проектирование) необходим для определенной задачи.
  2. Отчасти это связано с тем, что гражданское строительство так же стара, как человечество, в то время как разработка программного обеспечения существует уже несколько десятилетий.
  3. Еще одна причина заключается в том, что программное обеспечение является более изменчивым видом артефакта, с более гибкими требованиями (может быть разрешено сбой), различными маркетинговыми стратегиями (хороший дизайн может быть принесен в жертву, чтобы быстро получить его на рынке) и т. д.

Как следствие, гораздо труднее определить, какая правильная сумма дизайна /теории подходит для разработки программного обеспечения (слишком мало -> messy code, too much -> Я никогда не смогу закончить) потому что нет общего правила, и может помочь только (много) опыт.

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

62 голоса | спросил 4 revs
Giorgio
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

22 ответа


60

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

У многих программистов были плохие впечатления от теории убегания, которая стала активным препятствием на пути к выполнению (например, «исполняемый UML», сверхбюрократические процессы разработки). Напротив, грязные хаки и патчи могут получить вас довольно чертовски далеко, хотя и медленно в конце. И как вы заметили в своем последнем абзаце: неудачи обычно не являются окончательными и, следовательно, не столь проблематичными.

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
29

Разработка программного обеспечения и гражданского строительства имеют мало общего. Усилия гражданского строительства ограничены физическими свойствами их материалов и окружающей среды. Гражданские инженеры тратят много времени на изучение свойств почвы и характеристик материала. Разработка программного обеспечения физически ограничена только скоростью процессоров и доступным хранилищем. Оба они легко понять, и мы не проводим много времени, изучая их. Основным ограничением разработки программного обеспечения является человеческий интеллект. И ни один разработчик не одинок. Поддерживается ли этот код? Кем? Трехстрочная реализация quicksort в Haskell может быть явно правильной для некоторых, но непонятной для других. Команда из двух человек может заполнить заявку через месяц, в то время как другая команда из десяти попыток доставить через год.

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
15

Как более или менее честный инженер-механик (с каким-то гражданским) превратил программиста, затем CS (AI) PhD, затем учитель, затем программист снова (извините, Software Engineer ), У меня есть написание этого общего предмета.

В традиционной технике

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

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

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
13

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
11

Возьми меня с собой. У меня есть точка.

У меня был профессор, который сказал мне однажды, что откладывание ведет к дальнейшему откладыванию, хотя большинство людей после ночи изнасилованной бумажной письменности /кодирования /программирования говорят себе: «Я больше никогда этого не сделаю. В следующий раз, начнем рано и сделай рано ». По моему опыту, как непревзойденного прокрастинатора, я нашел это правдой, и вот объяснение профессора, почему: каким бы неприятным ни был опыт промедления, в большинстве случаев вы добиваетесь относительного успеха. Это поведение высокого риска /высокой награды. Через некоторое время вы забываете обо всех неприятностях и помните только о награде. Таким образом, следующий соблазн затягивания тем более заманчиво, потому что вы преуспели в последний раз.

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

Я была той бедной, несчастной душой, и, возможно, многие из вас. Я умоляю вас всех. Не делайте легкий выход! :)

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
9

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

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

Общим фактором является стоимость. Проект по традиционному строительному проекту снижает затраты (как фактические, так и материальные, а также потенциальные с точки зрения ответственности), тогда как наступает момент разработки программного обеспечения, где стоимость разработки увеличивается за пределы возвращаемого значения.

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
7

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
6

Проекты архитектора /инженера-строителя практически никогда не идентичны планам «как построены». Что-то ВСЕГДА меняется. Зачем? Потому что есть и будут всегда «неизвестные неизвестные». Есть вещи, которые вы знаете, и поэтому можете планировать, вещи, которые вы знаете, неизвестны, и поэтому вы можете исследовать и оценивать, а затем есть вещи, которые вы не знаете, чего не знаете; «сюрпризы». Вы пытаетесь устранить их в большинстве систем, изучая все, что можете, но все, что требуется, - это одно небольшое нарушение кода здания (которое может основываться на правиле, которое не существовало 2 года назад, когда ваше здание было концептуализировано), и все ваши Генеральный план генерального плана должен меняться, иногда довольно резко.

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
5

Разница в основном обусловлена ​​известными требованиями:

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
5

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

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

Один из моих сотрудников, который работал в NASA, ранее описал процесс разработки программного обеспечения, написав сотни страниц обоснования и сотни часов заседаний, чтобы оправдать создание одной строки кода!

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

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

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

Подводя итог, Premature optimization is the root of all evil или как мой босс всегда будет говорить Shipping is a feature!

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
4

Здесь есть много хороших ответов, но я думаю, что сравнение между Computer Science и Civil Engineering ошибочно.

Строго говоря, то, что делают профессиональные разработчики программного обеспечения, больше похоже на Software Engineering, чем на Computer Science. Лучшая аналогия заключается в том, что Computer Science - это физика для разработки программного обеспечения. Аналогичным образом, Civil Engieering представляет собой сборник упрощений и приближений физики для практически строительных материалов.

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

Большая разница заключается в том, что мосты, небоскребы и другие продукты Civil Engineering являются достаточно хорошо понятными вещами. Инженеры-программисты часто строят новые конструкции или используют новые методы для создания хорошо понятых вещей. Программная инженерия FAR менее зрелая, чем гражданская инженерия, и это, вероятно, будет оставаться верным в обозримом будущем.

TL; DR . Теория и практика различны в Software Engineering, как и везде. Соответствующая аналогия - Software Engineering: Civil Engineering :: Computer Science: Physics. Но на практике это немного сложнее, чем это:)

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
3
  

Итак, мой вопрос в том, почему некоторые программисты считают, что есть   контраст между теорией (формальными методами) и практикой (получение вещей   сделано)?

Построение программного обеспечения в отличие от построения моста. В программном обеспечении существует много объектов, которые могут быть определены или не определены в начале. Существуют стандарты для упрощения технического обслуживания и сотрудничества с разработчиками, а не для соблюдения произвольных математических формул или других таких идеалов. Например, при выборе поведения, основанного на переменной, иногда имеет смысл использовать коммутатор, а иногда и заводскую модель. Это зависит от удобства обслуживания и выявления болевых точек, таких как проблемы с производительностью.

Другой пример может быть сделан с манипуляциями с данными. Часто имеет смысл использовать делегатов в контексте .NET. Это не так просто в Java, потому что у него нет поддержки фреймворка для стиля функционального программирования, который имеет .NET. Другими словами, в общем случае просто невозможно сделать X в ситуации Y. Это связано с тем, что X и Y зависят от N числа переменных факторов.

  

Является ли программное обеспечение (строительное программное обеспечение) воспринимаемым многими как легкое   по сравнению, например, с гражданским строительством (зданиями)?

Я не уверен, что «легкий» - правильный термин. Отсутствие ощутимых доказательств может привести к восприятию того, что никакая работа не выполняется. Или, аналогично, существующая работа легко изменяется.

  

Или эти две дисциплины действительно разные (кроме   критически важное программное обеспечение, отказ программного обеспечения гораздо более приемлемый   чем отказ здания)?

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
1

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
1

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
1

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
1

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

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
1

Я думаю, что аналогия ошибочна. Насколько мне известно, гражданское строительство не имеет такой же теоретической основы, как информатика; компьютерная наука родилась от теоретической математики - как машины Тьюринга. Гражданское строительство - это создание структур, которые противостоят материнской природе и, возможно, даже выглядят красиво. Опять же, я действительно мало знаю о гражданском строительстве, но я не думаю, что есть инженеры-инженеры-эквиваленты P против NP, коммивояжера и другие забавные вещи, чтобы сбить ваши мозги. И определенно есть место для нашей теории информатики - если кто-то решает коммивояжера или проблему с остановкой, в которой мы находимся, для многих удивительных новых достижений. Но для инженера-программиста, чей бизнес является программным обеспечением для архитекторов, такие проблемы действительно являются только забавой и играми.

Теперь я также думаю, что это зависит от того, что вы подразумеваете под «теорией». Мы говорим о шаблонах проектирования или о перекачке леммы? . Поскольку хорошее понимание дизайна шаблонов абсолютно важно для того, чтобы быть хорошим инженером-программистом. Однако при разработке крупной программной системы теоретическое обоснование проблем P /NP нецелесообразно. В этом смысле я считаю, что существует очень резкий контраст между программным обеспечением и теоретической информатикой.

Или теория ссылается на алгоритмы? Вы не тратите много алгоритмов написания времени, которые вы изучили в своем классе алгоритмов. Зачем? Потому что вы, как правило, нуждаетесь в них только в отдельных случаях (и затем смотрите его и исследуете), или вы используете уже написанную для вас библиотеку. Не нужно писать еще один байесовский классификатор. Абстракция - важный принцип в информатике. Я думаю, что разработчики программного обеспечения склонны не узнать, как работает алгоритм, пока им не понадобится.

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

TL; DR. Я думаю, что существует некоторая двусмысленность вокруг слова «теория». Традиционно теория относится к теоретическим математическим аспектам информатики. Если вы не изучаете новые способы вычисления, по большей части теоретическая информатика не играет никакой роли в повседневной жизни инженера-программиста. Инженеры-разработчики программного обеспечения заботятся о шаблонах проектирования и системной архитектуре. Специфические детали реализации некоторых алгоритмов не важны. Часто с менее сложными идеями уместно не много разрабатывать и просто начинать кодирование. И я думаю, что именно здесь идея исходит из того, что программисты не любят теорию.

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
1

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
0

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

Практическое программирование - это решение правильной проблемы (а не дизайна программного обеспечения) в правильном направлении прямо сейчас, чтобы ваши коллеги могли выполнять свою работу лучше /быстрее /вообще, или чтобы доходы могли поступать в компанию , Многое программное обеспечение не похоже на продукт, никогда не «сделано», а больше похоже на живое существо, которое начинается высокоспециализированным для одной экологической ниши и может иметь широко измененную продолжительность жизни, в ходе которой ему необходимо решить новые, непредвиденные проблемы в широкий спектр постоянно меняющихся сред. В деловом мире, с политикой и законностями, конкуренцией и постоянно меняющимися организациями, структурами и тенденциями, требования часто неоднозначны, сложны со всеми видами особых случаев, плохо определены и подвержены быстрым неожиданным изменениям. Они не являются анализируемыми, предсказуемыми или статичными, и часто не логичны или разумны. Программное обеспечение, по всей вероятности, будет неактуальным в течение 2 недель, чтобы быть еще в использовании через 20 лет. Он приходит в мир, не знающий многого или способного многое сделать, и его нужно развивать, ухаживать и тренировать на протяжении всей своей жизни, чтобы вырасти сильным, гибким и способным адаптироваться к постоянно меняющимся условиям и новым проблемам. Если вы пренебрегаете им после рождения, это будет дико, если он выживет достаточно долго и причинит боль и страдания, решая проблемы с тупой силой.

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
0

Ставки ниже, задача проще, а менеджмент редко видит ценность в хорошем дизайне. Системная нестабильность, ремонтопригодность и целостность - это проблема «ИТ», а не проблема «Бизнес». У всех руководителей есть одна общая черта. Они либо сосредоточены на деньгах на 95%, либо они сообщают тому, кто есть.

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

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
0

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

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

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

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

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

Очевидно, вы не можете использовать популярный и хорошо расцененный шаблон, такой как MVC, для обработки проблем с интерфейсом в Интернете исключительно без изменения способа его обработки в контексте настольных приложений. На самом деле, я бы сказал, вы должны знать, что делает MVC полезным, но даже не пытайтесь реализовать его в особенно требовательной или оптовой манере. Парадигма веб-приложений уникальна тем, что все материалы, которые смотрят на меня, обрабатываются браузером пользователя, и все данные /модель-иш обычно находятся на сервере где-то. Но где это выходит из контроллера? Все на сервере или все на лицевой стороне? Это кому-то принадлежит. Или, может быть, MVC не на 100% лучше всего подходит для сценария. Неплохо подходит для .NET back end. Не страшно в контексте конкретных виджетах пользовательского интерфейса. Но попытка применить его ко всему ради согласованности может быть неудачным шагом, ИМО.

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29
0

Гленн Вандербург представляет отличный взгляд на различия между разработкой программного обеспечения и более традиционными инженерными дисциплинами: http://www.youtube.com/watch?v=NP9AIUT9nos

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

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

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

ответил James Anderson 3 FebruaryEurope/MoscowbTue, 03 Feb 2015 04:56:29 +0300000000amTue, 03 Feb 2015 04:56:29 +030015 2015, 04:56:29

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132