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

63

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

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

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

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

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

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

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

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


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

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

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

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

Джорджио
источник
9
нет, 90% программистов есть;)
jk.
24
Ну, в программном обеспечении вы могли бы начать со строительства крыши и затем спуститься вниз к фундаменту, пока готовые детали плавают в воздухе. Если что-то не подходит, вы можете использовать клейкую ленту, чтобы подогнать его. Попробуйте это при строительстве небоскреба. ;)
Безопасный
65
В теории нет разницы между теорией и практикой, но на практике есть.
Йорис Тиммерманс
6
Хорошая книга для поиска алогритов? Большая часть программного обеспечения - это просто CRUD, не похожее на то, что включено в любой курс или книгу по алгоритмам
Жиль
44
Теория о современных языках и алгоритмах. Практика приходит на работу в ваш первый день, и перед ней стоит задача добавить незначительную функцию в программное обеспечение Point of Sale, работающее на кассовом аппарате, которое использует программное обеспечение, которое было вручную преобразовано из BASIC в K & R C людьми, которые не знали C с помощью глючного компилятора от поставщика, который обанкротился и ожидается, что эта функция будет работать не позднее пятницы.
Gort the Robot

Ответы:

61

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

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

Michael Borgwardt
источник
1
Я согласен с вами, что в разработке программного обеспечения важно иметь правильное количество формализма. Слишком много значит, что вы никогда не сможете начать, и, возможно, когда вы обнаружите, что сделали ошибку, будет слишком поздно. Слишком мало значит, что вы можете устроить беспорядок. Я думаю, у вас есть очень сильное замечание, когда вы говорите, что производительность и качество гораздо сложнее измерить в разработке программного обеспечения, чем в строительстве.
Джорджио
2
«... в то время как в программной инженерии не существует столь же мощная сила , чтобы непрактично ...» Я думаю , что вы имеете в виду там больше нет такой силы. В свое время ограничения, создаваемые более слабыми процессорами, меньшим объемом памяти и небольшим объемом памяти или отсутствием памяти, действовали как такая сила.
День
1
@blesh: я так не думаю. Жесткие аппаратные ограничения одинаково ограничивают хорошее и плохое проектирование
Майкл Боргвардт
Ваши примеры не являются теорией программирования. Ограничения на программное обеспечение связаны с используемыми технологиями и математическим потенциалом авторов.
Пол Натан
5
В UML определенно есть что-то «теоретическое» ... ... его полезность!
ObscureRobot
29

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

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

кевин клин
источник
1
Я согласен с вашими наблюдениями, что человеческий фактор намного сильнее в программном обеспечении, но все же я думаю, что попытка проанализировать проблему или структурировать ваше решение - это общий подход / инструмент. Мой вопрос заключается в том, почему некоторые программисты считают, что это бесполезный подход (или даже трата времени). Вы упомянули Haskell: я приложил усилия для изучения некоторого Haskell, хотя я не использовал его ни в одном проекте, потому что думал, что это поможет мне написать лучший код (даже на C ++ или Java). Даже если я не могу измерить это, я чувствую, что стал более продуктивным: я делаю больше вещей.
Джорджио
2
Трехстрочная быстрая сортировка на Haskell? Хм ... это даже можно реализовать Quicksort на языке , где все неизменны по дизайну?
Мейсон Уилер
3
@MasonWheeler Первый результат от Google: Быстрая сортировка в Haskell .
chrisaycock
3
@Mason: время выполнения по-прежнему равно O (n log n). Это также требует O (n log n) памяти, в отличие от быстрой сортировки на месте, которая требует только O (log n) дополнительной памяти для рекурсии.
Кевин Клайн
2
@kevincline В той степени, в которой типичный программный проект уникален, я приступил к уникальному проекту по реконструкции моей ванной комнаты. Разница в том, что если я испорчу свой код, мои тесты станут красными, а если я испорчу проводку, мой дом сгорит. Конечно, этот проект также был сверхурочным и превышал бюджет, потому что у меня нет опыта в решении проблем ремоделирования. Основная проблема, которую я видел в программных проектах, похожа ... не то, что правильные люди не могли решить эти проблемы быстрее, это то, что нужные люди не доступны, и мы должны стать правильными людьми на летать.
Philododad
17

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

В традиционной инженерии

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

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

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

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

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

оборота Майк Данлавей
источник
5
Физика может сказать вам, разрушится ли какая-либо структура под собственной нагрузкой. CS говорит вам, что вы не можете сказать, остановится ли данная программа при заданном входе. Формальные методы ИМО масштабируются намного лучше в гражданском или машиностроении, чем в программном обеспечении, в основном потому, что системы менее сложны и менее динамичны ...
Гай Сиртон,
6
@GuySirton "CS говорит вам, что вы не можете сказать, будет ли данная программа остановлена ​​с определенным вводом." если это все, что, по вашему мнению, делает CS, я думаю, что вы можете знать о CS не так много, как вы думаете ...
gregghz
2
Парень, невероятно маловероятно, что ты когда-либо использовал программные материалы, которые раньше никто не использовал. Маккарти сделал, и Тьюринг сделал, но на самом деле, разработка программного обеспечения не настолько удивительна. Если все в порядке, что здание опустилось на дно океана, потому что вы можете просто перезагрузить его, это было бы похоже на разработку программного обеспечения.
Философия
3
Я бы дал вам +1, кроме крэка о читабельности. Ремонтопригодность составляет 80% стоимости программного обеспечения, поэтому удобочитаемость не мала. Кроме того, когда этот авиационный или ядерный инженер делает что-то, что будет изготовлено, чтобы другие люди понимали, что это важно. Военные, правительственные или даже крупные учреждения не в восторге от волшебного изобретения, которое не может быть воспроизведено или понято никем, кроме изобретателя.
Томас
2
@Thomas. Утверждение о том, что жизнеспособные решения часто отвергаются на уровне «читабельности», не обязательно означает, что решения не так разборчивы, как следовало бы. Я видел, как это случилось. Черт, я поймал себя на том, что делаю это.
Эрик Реппен
13

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

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

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

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

Потерпи меня на этом. У меня есть точка зрения.

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

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

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

FishBasketGordo
источник
3
Если вам нужно сделать это один раз и забыть об этом, это нормально. Но если вам придется расширять и поддерживать его впоследствии, вы ищете проблемы. Вы должны понимать, сколько теории: слишком много означает, что вы никогда не сделаете этого, слишком мало означает, что вы собираетесь сделать это 10 раз, прежде чем это действительно будет сделано. Мои 2 цента.
Джорджио
6
Но иногда вам нужно вывести свое программное обеспечение прямо сейчас . Вам нужно победить конкурента на рынке. Или у вас есть законное требование предоставить некоторую информацию. Или вам просто нужно получить денежный поток, чтобы вы все еще существовали, когда беспорядок, который вы создали в своем подходе «сделай это», является проблемой ... которая иногда является хорошей проблемой. Потому что, если у вас его не было, вы не выпустили вовремя, и ваша компания мертва до ее начала.
CaffGeek
1
@ Чед - я согласен с тобой. Это баланс. Все вещи, которые вы упомянули, подпадают под «истинное ограничение по времени» в качестве причин для готового программирования, и в краткосрочной перспективе это нормально и даже выгодно, если вы укажете на это.
FishBasketGordo
@FBG: Блестяще сказал.
Куба Обер
@ Чед, хорошая мысль. Мартин Фаулер делает аналогичное замечание на сайте martinfowler.com/bliki/TechnicalDebt.html . Иногда это выгодный компромисс.
Джон М Гант
9

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

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

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

Джеймс Маклеод
источник
«В разработке программного обеспечения наступает момент, когда стоимость проектирования возрастает сверх возвращаемой стоимости». Я четко написал «правильное количество теории». Я знаю, что сверхинжиниринг не увеличивает производительность.
Джорджио
Есть почти нулевые проекты IMO, которые разработаны заранее, которые фактически следуют их дизайну. Гражданское строительство (вообще?) Строит одно и то же снова и снова (дорога, черт, туннель, здание, мост). Методы хорошо известны. Это не так в программном обеспечении. Потому что это можно легко изменить, и потому что люди не знают, чего они хотят или что работает, пока не попробуют серьезно, предварительный дизайн - пустая трата времени. Мы строим, тестируем и повторяем. Что-то, что невозможно с гражданским строительством, как указано выше. 2 дисциплины не сопоставимы.
GMan
5
Извините, я должен указать на опечатку: я не думаю, что инженеры-строители наплевать. ;-)
Джорджио
2
Я полагаю, что в будущем, когда мы, инженеры-программисты, создадим классное программное обеспечение для гражданского строительства, инженеры-строители могут покончить со всем этим математическим материалом. Просто постройте виртуальный небоскреб высотой 10 км. Если в первые 100 виртуальных лет он не обрушится под собственным весом и сможет выдержать виртуальный ураган cat 5, то для его создания используйте специальный 3D-принтер для небоскребов.
emory
1
@RexKerr: вы отрубили половину его заявления: «... который удовлетворяет требуемым стандартам безопасности»
Ли Райан
7

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

Онорио Катеначчи
источник
6

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

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

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

оборота KeithS
источник
3
Существует также гораздо больше неизвестных неизвестных в разработке программного обеспечения - вы могли бы начать строить небоскреб, но когда клиент смотрит на него, он говорит вам: «На самом деле я хотел куб Rubix высокого уровня».
Tacroy
@Tacroy: Интересно, что инженер-строитель, вероятно, посчитал бы этого плохим клиентом, который тратит ваше время и ресурсы, а инженер-программист попытается разработать новую методологию, чтобы удовлетворить его. :-)
Джорджио
1
@ Джорджио, или счет соответственно ...
CaffGeek
5

Разница в основном из-за известных требований:

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

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

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

Izkata
источник
1
+1 за «когда говорим о« теории », это обычно означает теоретическую сторону информатики».
Джошуа Дрейк
5

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

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

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

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

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

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

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

Альберт Лэнг
источник
3
+1 за "Доставка это особенность"! Однажды я услышал похожее предложение: «Совершенство не существует. Преимущество этого программного обеспечения в том, что оно существует». Конечно, это немного шутка. Что касается критически важного программного обеспечения: неперехваченное исключение может вызвать сбой ракеты.
Джорджио
this software has the advantage that it exists... я этого еще не слышал, но он входит в мой список замечательных цитат по программному обеспечению. мне это нравится
Альберт Лэнг
@ Джорджио: JSF и MISRA C написано так, что нет никаких исключений. Исключения и ракеты не смешиваются.
Кодер
5

Здесь много хороших ответов, но я думаю, что сравнение между информатикой и гражданским строительством некорректно.

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

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

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

TL; DR : Теория и практика в разработке программного обеспечения различны, как и везде. Подходящая аналогия - разработка программного обеспечения: гражданское строительство :: компьютерные науки: физика. Но на практике все немного сложнее :)

ObscureRobot
источник
«Я полагаю, что инженеры-строители редко должны учитывать общую относительность при выполнении своей работы. Большая часть гражданского строительства может быть безопасно построена в ньютоновской механике». Насколько я знаю, им приходится использовать довольно много исчислений (интегралов и тому подобное). Это не квантовая механика, но IMO это определенно нетривиально.
Джорджио
2
Конечно, но вам не нужно выводить волновое уравнение для каждого компонента вашего моста, а затем объяснять, как они взаимодействуют.
ObscureRobot
Ты прав. Тем не менее, моя точка зрения не в том, насколько теория используется в гражданском строительстве по отношению к разработке программного обеспечения. Скорее инженеры-строители знают, что они должны использовать свои формулы и делать расчеты о том, как построить какое-то здание. В разработке программного обеспечения у меня сложилось впечатление, что импровизации становится больше, и иногда, если вы хотите откинуться на спинку кресла и проанализировать проблему (просто чтобы понять ее правильно, а не писать диссертацию на соискание ученой степени кандидата наук), вы можете быть недовольны: мы хотим получить ее закончено, чтобы не сделать его идеальным. Но IMO, некоторая теория (не слишком большая) - это именно то, что может помочь закончить ее быстрее!
Джорджио
Вам нужно найти точку баланса, подходящую для вашего проекта. Младшие разработчики, как правило, более фанатичны в том, чтобы бросать дерьмо воедино, чтобы посмотреть, что из этого получится. Если они пришли из очень теоретического фона, они могут даже иметь более сумасшедшие и чрезмерно сложные идеи. Эффективное управление начинающими разработчиками часто включает в себя помощь им сделать шаг назад и анализ их работы. С другой стороны, старшие разработчики могут быть слишком сосредоточены на проблемах долгосрочного проектирования, чтобы им было сложно сосредоточиться на насущных потребностях.
ObscureRobot
Вау, извините, это не по теме, но, не прочитав ваш ответ, я закончил его точно так же - с помощью TL; DR, а затем буквально по той же аналогии. Формат сат. Я отредактировал его из своего ответа, чтобы не выглядело так, будто я его копирую, но он все равно меня бесит. Может быть, программисты слишком много думают.
Ярсен
3

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

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

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

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

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

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

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

Брайан. Маки
источник
1

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

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

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

Стивен Эверс
источник
3
«математика ... уже сделана»: не только рассмотрите все библиотечные функции, платформы, СУБД, протоколы и множество других тяжелых вещей, которые мы можем просто использовать в нашем коде, вызывая функцию с некоторыми параметрами. Как программист, я иногда чувствую себя больше как рабочий, который ходит на эшафоте, чем как инженер, который спроектировал здание.
Джорджио
1

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

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

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

v-звезда
источник
1

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

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

Мартин Беккет
источник
Так что же представляет собой программный эквивалент анализа методом конечных элементов 100-этажного здания? Сколько высотных зданий имеют ошибки в термо / аварии? :-)
Гай Сиртон
@GuySirton - вы можете анализировать большое здание только на очень грубом уровне, с меньшей детализацией, чем в модульном тестировании типичного приложения. Во многих крупных зданиях есть повреждения, окна выпадают, тротуары разрушаются, они создают эффекты аэродинамической трубы. Или в случае с одним изогнутым отелем с высокой отражающей способностью в Вегасе вы создаете луч смерти в бассейне!
Мартин Беккет
В FEA вы можете работать довольно детально и прогнозировать поведение с очень высокой степенью точности. Люди все еще делают ошибки. ИМО просто невозможно делать подобные прогнозы на сложном программном обеспечении. Упомянутые вами недостатки составляют незначительную долю от общего числа зданий. Уровень дефектности в программном обеспечении должен быть на два порядка выше. Тем не менее, это, очевидно, континуум между тем, где формальные методы полезны и где они бесполезны.
Гай Сиртон
@GuySirton - я думаю, что проблема в том, что ты полагаешься на другие вещи. Nasa может тестировать бортовое радиоэлектронное оборудование на очень детальном уровне (хотя все еще не доказывает его правильность), поскольку они также создают ОС и аппаратное обеспечение. Писать в обычной ОС с помощью наборов инструментов и библиотек - это все равно, что строить мост, где вам не разрешено знать детали стали или бетона.
Мартин Беккет
1
@MartinBeckett, и коэффициент гравитации изменяется случайным образом от часа к часу ... как, когда системный администратор случайным образом решает обновить сервер, не говоря никому, потому что «он будет прозрачным».
CaffGeek
1

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

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

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

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

Доминик Кронин
источник
1

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

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

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

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

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

оборота Ярсен
источник
1
Я вижу некоторые сходства между нашими ответами, но ваши идеи, очевидно, оригинальны, и есть некоторые различия. Я не согласен, что понимание P / NP не полезно. Вам не нужно глубоко изучать Теорию Сложности, но работающий инженер-программист должен уметь оценивать O (n) любого фрагмента кода и говорить разумные вещи о стоимости альтернативных решений. Вы почти сделали, но не поняли, что теория часто заключена в библиотеках. Это хороший вопрос для рассмотрения.
ObscureRobot
«Если кто-то решит ... проблему остановки, которой нас ждут множество удивительных новых достижений». Ну, к сожалению, теория доказала, что это неразрешимо (не существует программы, которая может решить это), поэтому я не думаю, что какая-либо усилия по исследованию тратятся на решение проблемы остановки.
Джорджио
Машины Тьюринга не могут "Однако, не все машины, мыслимые человеческим воображением, подвержены тезису Черча-Тьюринга ... Остается открытым вопрос, могут ли существовать реальные детерминированные физические процессы, которые в конечном итоге не поддаются моделированию Машина Тьюринга и, в частности, может ли любой такой гипотетический процесс быть полезен в виде вычислительной машины (гиперкомпьютера), которая могла бы решить проблему остановки ... Это также открытый вопрос, участвуют ли какие-либо такие неизвестные физические процессы в работа человеческого мозга ... "- Проблема Холтинга, Википедия
Jarsen
Итак, насколько я знаю, и поправьте меня, если я ошибаюсь, я думаю, что у нас еще много открытий в вычислениях. Как уже неоднократно упоминалось в этой теме, информатика еще очень молода; там может быть гораздо больше, чем Turning Machines и архитектура фон Неймана.
Ярсен
@Jarsen: Это правда, что информатика очень молода, но любой компьютер, который был построен до сих пор, может делать только вычисляемые по Тьюрингу вещи. Насколько я знаю (на самом деле очень мало), даже квантовые компьютеры не могут сделать больше (они могли бы решить некоторые проблемы быстрее, но они не смогли бы решить больше проблем). Так что, да, кто знает, что можно изобрести, но любой вычислительный формализм, представленный за последние 70 лет, не может сделать больше, чем машина Тьюринга.
Джорджио
1

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

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

Марко Девиллерс
источник
0

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

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

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

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

луч
источник
0

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

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

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

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

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

Даниэль
источник
0

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

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

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

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

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

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

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

Эрик Реппен
источник
0

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

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

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

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

mirkok
источник