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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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