Почему так сложно писать программное обеспечение?

Написание программного обеспечения, я считаю, состоит из двух частей:

Идея и
Реализация.

Идея о мышлении: "У меня есть эта проблема, как ее решить?" и далее: "Как я могу решить это изящно?" Ответы на эти вопросы можно получить, если подумать об алгоритмах и архитектуре. Идеи приходят частично через анализ, а частично через проницательность и интуицию.

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

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

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

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

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

Но писать код по-прежнему сложно. Написание кода - это понимание больших, сложных систем и инструментов, которые мы имеем сегодня, просто не очень далеко, чтобы помочь нам в этом. Когда я нажимаю "найти все ссылки" в Eclipse, я получаю список из них в нижней части окна. Я нажимаю на один, и я оторван от того, на что я смотрю, и вынужден переключиться на контекст. Архитектура Java обычно имеет несколько уровней глубины, поэтому я должен переключаться и переключаться и переключаться, пока не найду то, что я действительно ищу - к этому моменту я забыл, откуда я пришел. И я делаю это весь день, пока не понял систему. Это налогообложение умственно, и Eclipse не делает многого, чего нельзя было сделать в 1985 году с помощью grep, за исключением того, что есть сотни мегабайт ОЗУ.

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

Так почему же писать код все еще так сложно?

Ответ 1

Вы не можете победить прозрение Эдсгера Дийкстра 1972 Премия Льюиса Тьюринга, "Скромный программист:"

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

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

и к концу:

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

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

Целая лекция стоит прочитать.

Ответ 2

На самом деле я нашел полное противоположное, чтобы быть правдой.

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

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

Некоторые удивительные проблемы были решены с помощью языков программирования и очень короткого промежутка времени. Просто google многочисленные проблемы программирования, такие как ICFP.

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

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

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

Итак, подведем итог: Я считаю, что изменение и общение - это настоящая проблема, а не сама проблема.

Возвращаясь к недавнему выпуску, я бы сказал, что время было следующим образом: 70% Программирование 30%.

Затем этого 30% -ного программирования:

20% Единичный код тестирования
20% Реализация
40% исправление ошибок.

Исправление ошибок было в значительной степени из-за недостаточных модульных тестов и некоторых проблем с дизайном.

Ответ 3

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

Ответ 4

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

Ответ 5

Код записи жесткий , потому что он требует концентрации.

Ответ 6

Несколько моментов/критических замечаний... если я, кажется, имею в виду, что я не имею в виду; Мне очень нравится ваш вопрос.

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

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

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

Это звучит как высокая связь со мной... также свидетельствует о некоторых остеклениях на этапе проектирования между этим кофе и реализацией.;)

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

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

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

С другой стороны, если я работаю над программным обеспечением управления Warehouse (* thinks *), и там есть объект с именем BigBoxFullOfStuff или ScheduledShipment, то немного легче понять, почему это в системе.

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

Ответ 7

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

Чтобы привести пример, где я работаю, мы потратили почти 2 года на замену CMS из-за других вещей, которые он затрагивает, например, как ESB или CRM. Одной из задач является интеграция системы с людьми, а часть ее "Humanity: Epic FAIL" , если вы не видели этого разговора Джон Скит, вам обязательно нужно это проверить.

Ответ 8

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

Ответ 9

Писать код сложно, потому что трудно решить проблемы.

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

Собственно, тратить время на то, чтобы написать код, означает составить план того, как действовать при всех возможных условиях, что помещает программиста непосредственно перед всеми нерешенными проблемами. Таким образом, программист сам либо сам должен решить эти новые проблемы, либо вернуться в конструкторскую комиссию со всей новой партией nit-picky вопросов, например "Что мы будем делать, когда клиент возвращает продукт после его отправки, но прежде чем мы получить номер отслеживания?" или "Что мы используем для нашего шаблона счета, когда клиент покупает больше продуктов, чем будет на одной странице?"

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

Ответ 10

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

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

Кроме того, технология всегда меняется. Например, когда я учился в колледже, структурированное программирование считалось передовым и не было общепринятым. Спустя несколько лет структурированное программирование стало приемлемым, а объектно-ориентированное развитие было на переднем крае, но не так широко принято. Теперь, когда довольно широко принято, и такие вещи, как функциональное программирование, перемещаются в передний край. (Обратите внимание, что эти концепции были примерно в то время, но поле не использовало их в широком смысле так долго. Кроме того, большинство "доказательств", что они лучше, чем другой метод, были анекдотическими, рассмотренными очевидным или просто утверждаемым - без реальных научных исследований). Другие примеры изменения технологии другого типа: 25 лет назад графический интерфейс был новым, сетевое взаимодействие было почти редко, за исключением одного центра обработки данных, а World Wide Web просто не " t существует. Теперь эти темы считаются стандартными знаниями, и многие практикующие, как ожидается, будут хотя бы несколько опытными во всех этих областях.

Ответ 11

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

Подумайте о каждом последующем поколении программного обеспечения. Следите за gopher до lynx до mozaic к современным браузерам. Посмотрите, как прошел Photoshop. Сравните сегодняшние операционные системы с qdos. Некоторые из вещей, которые трудно было написать поколение назад, теперь слишком упрощены, чтобы быть интересными.

Ответ 12

Писать код сложно. Причина в том, что ИМО, мы всегда стараемся делать то, чего раньше не делали. Как долго было написано nntp newsreader в c 10 лет назад, и теперь мы можем, возможно, написать читателю iPhone rss в днях.

Ответ 13

Так почему же писать код все еще так сложно?

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