Хороший код невозможен в современной разработке программного обеспечения? [закрыто]

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

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

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

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

Как заявили DeMarco и Lister в Peopleware около 20 лет назад, подавляющее большинство провальных программных проектов терпит неудачу не из-за технических проблем, а из-за социологических проблем . Это не изменилось за последние десятилетия, независимо от того, насколько улучшились наши инструменты.

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

Почему писать хороший код сложнее?

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

Только из-за упомянутых факторов, времени и сложности?

Да, достижимая сложность, безусловно, увеличилась (и продолжает увеличиваться) с увеличением мощности наших инструментов. Другими словами, мы продолжаем раздвигать границы. Что для меня переводится так, что одинаково трудно решить самые большие проблемы сегодняшнего дня, как это было 30 лет назад, чтобы решить самые большие проблемы того дня.

OTOH с тех пор, как область выросла настолько, что сейчас существует гораздо больше «маленьких» или «известных» проблем, чем было 30 лет назад. Эти проблемы технически (не должны) больше (быть) проблемой, но ... сюда входит вышеприведенный принцип :-(

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

Это что методологии не практикуются правильно?

ИМХО конечно нет. У Демарко и Листера есть несколько резких слов о методологиях Big-M. Они говорят, что никакая методология не может сделать проект успешным - только люди в команде могут. OTOH методологии small-m, которые они хвалят, довольно близки к тому, что мы сейчас знаем как «agile», который широко распространен (ИМХО по уважительной причине). Не говоря уже о такой хорошей практике, как модульное тестирование и рефакторинг, которые всего 10 лет назад не были широко известны, и в настоящее время даже многие выпускники знают об этом.

Вопросы, связанные с кодированием в нереальные сроки и с техническими долгами, были известны с Вайнберга 71 года, а также с Бруксом 72 года. До этого литературу становится трудно найти в Интернете, но я вполне уверен, что старые отчеты CDC, IBM и NASA говорят о том же.

Я думаю, что у всех нас есть свои собственные идеи и пороги для «Хорошего кода». Тем не менее, есть ряд вопросов, которые все способствуют:

• Неправильное применение «заставить его работать, а затем улучшить его» означает, что мы оставляем мертвый код и 10 различных вариантов одного и того же метода, каждый из которых используется только один раз в базе кода. Этот материал, кажется, никогда не очищается.
• Недостаток времени и бюджета. Клиенту нужно 100 новых функций за 3 месяца, некоторые из которых нетривиальны, и они не хотят тратить деньги на вещи, которые они не видят напрямую.
• Отсутствие заботы. Посмотрим правде в глаза, некоторые разработчики заботятся о том, как код выглядит и ведет себя больше, чем другие. Смотрите первый пункт для примера.
• Мы действительно не знаем, как создать «хороший код». Моя концепция хорошего кода постоянно развивается. То, что я думал, было хорошо десять лет назад, уже не так хорошо.
• «Хороший код» - это ценностное суждение. Кроме «это работает», и нет известных ошибок, любые другие критерии для хорошего кода, по сути, вопрос мнений.

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

Почему писать хороший код сложнее?

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

Хороший код невозможен в современной разработке программного обеспечения?

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

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

Мы сделали это, мы решили проблему сложности, но это не устранило большую проблему, которая у нас была раньше.

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

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

Мы никогда не сможем это сделать.

И если мы не сможем, мы никогда не создадим качественный код.

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

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

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

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

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

Я не хочу выбирать какого-либо конкретного поставщика, но сравнивать Windows 1.0 с Windows 7. Последний содержит в тысячи раз больше кода, но среднее время между сбоями увеличилось в сто раз. Мы должны были иметь возможность встраивать электронную таблицу Excel в документ Word начиная с Windows 3.1, но в наши дни это на самом деле более или менее работает.

Не желая впадать в сентиментальность «Вы, ребята, в наши дни с типизацией утки и виртуальной машиной», я хотел бы предположить, что вы не представляете, как трудно было написать хороший код в 80-е годы: модели памяти TINY, SMALL и HUGE, оверлеи , не арендная ОС звонки (содрогание). Хорошее избавление от всего этого.

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

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

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

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

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

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

Я думаю, что есть древний закон науки, который стоит запомнить:

Природа не терпит пустоты.

Франсуа Рабелас (французский монах и сатирик 1494-1553)

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

Так почему бы и нет?

ИМО основной причиной является то, что мы постоянно ищем пути и оправдания для злоупотреблений. Вместо того чтобы идти старомодным, простым, вероятно, скучным путем, например, создавать исполняемый файл Windows, мы раздвигаем границы возможного и ищем способы, например, воссоздать что-то вроде PhotoShop в качестве веб-приложения. Почему? Потому что мы можем. Или, по крайней мере, мы так думаем.

Когда в последний раз НИКТО не писал эксплойт и не учился делать это, обманывая ассемблером (не считая хакеров ядра и ребят из ASIC)? Сколько ошибок было обнаружено в основных библиотеках C? Почти никто и немногие. Все, что я говорю, это то, что люди способны на отличный код. Лучшие инструменты и языки просто делают его менее «обязательным» и более «необязательным». Не то чтобы я думал, что мы все должны писать действительно ужасный код, но когда я думаю о сложных логических конструкциях ... никто бы не мечтал написать что-то с использованием хеш-массивов в сборке. Должен быть «лучший» способ обработки логики вместо использования сложной конструкции. Даже если код красив, иногда подход не так элегантен. Я думаю, что это как бы решает проблему, которую вы упомянули. Хороший код не всегда просто организован,

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

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

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

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

Как люди стали хуже делать хороший код?

Если вы возьмете, например, .NET и такой язык, как C # (и я понимаю, что это не единственная платформа / язык), я бы сказал, что хорошее программирование стало намного, намного проще благодаря автоматизации многих вещей в Visual Studio. окружающая обстановка.

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

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

Мои два цента.

Да, мы как отрасль не практикуем то, что известно как хорошие методологии. Ссылка: Стив Макконнелл в разработке программного обеспечения Construx Software Low Low Hang Fruit .

качество кода не стало лучше

пожалуйста, не застрять в интерпретации «хорошего кода»

Великая логическая тавтология.

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

Если вы можете «обсудить« хороший код », то вы не можете сравнивать, и вы действительно не можете решить, является ли это« проблемой »или нет.