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

19

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

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

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

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

Амир Резаи
источник

Ответы:

34

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

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

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

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

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

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

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

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

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

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

Петер Тёрёк
источник
2
Не быть нацистской грамматикой или чем-то иным, но «нереальным» (во втором абзаце) - это не слово. Я думаю, что вы имеете в виду «нереально».
Я могу поддержать только «младший» вопрос. Я один из них, и мне бы очень хотелось, чтобы у меня был наставник, чтобы выручить меня. Благодарно, что сегодня есть Интернет, и Amazon и ТАК помогают, но все же ...
Matthieu M.
1
+1: Также следует отметить, что из-за быстрых изменений и роста инструментов / технологий / методологий, в определенной степени, мы все младшие, по крайней мере, пару раз в год. Опыт просто позволяет некоторым ветеринарам набрать скорость быстрее, чем некоторые младшие.
Стивен Эверс
Я отказываюсь принимать этот вопрос всерьез, если у нас нет формальных правил, чтобы отделить красивый код от уродливого.
Шабун
17

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

Пол Натан
источник
1
+ За "технический долг" и справки.
Амир Резаи
10

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

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

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

Берин Лорич
источник
1
+1 Хороший вопрос. Под «хорошим кодом» я не имел в виду идеальный код. Идеальный код не существует. «Хороший код» - это код, который не доставляет вам головной боли, например, он хорошо продуман.
Амир Резаи
1
Отличное замечание о том, что «хороший код» - это движущаяся цель. Однако я не согласен с тем, что это просто оценочное суждение. Я считаю, что чистый код легче модульно тестировать, расширять и поддерживать, чем грязный код, поэтому в долгосрочной перспективе он измеримо дешевле. Конечно, так как мы обычно не проводим двойные слепые тесты с контрольными группами в реальных проектах ПО ;-), этому есть только отдельные примеры, никаких веских научных доказательств.
Петер Тёрёк
Похоже, что оба наших нынешних определения «хорошего кода» совпадают. Тем не менее, я видел несколько довольно ярких примеров хорошего дизайна API, которые сделали мою жизнь намного проще - но в библиотеке не было модульных тестов. Это не значит, что оно не было проверено, просто не было ничего, чтобы автоматизировать тестирование. Я оставляю место для этого.
Берин Лорич
8

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

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

Pemdas
источник
+1 Очень хороший момент, новые инструменты увеличивают производительность, что может привести к большей сложности.
Амир Резаи
1
+1. Также известный как «Закон Утечки Абстракций». :)
Бобби Столы
6

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

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

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

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

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

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

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

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

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

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

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

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


источник
Мне нравится этот ответ, если бы он не был написан таким пессимистическим, фаталистским тоном ...
Тимви
1
@ Тимви: Не пессимистично на самом деле. Должен был принести вам облегчение бремени. :)
4

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

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

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

Чарльз Э. Грант
источник
Ненавижу уходить не по теме, но лично я бы сказал, что Windows 1.0 - 3.11 на самом деле очень стабильны, по-видимому, из-за их сложности. Самыми аварийными версиями Windows были 95, 98 и ME. Конечно, какие версии были «хорошими» другими способами, это другое дело.
Тимви
Как насчет кодирования на миникомпьютерах или мэйнфреймах вместо систем с низким энергопотреблением? Проблемы, на которые вы ссылаетесь, относятся к модели Intel 8086 ...
Пол Натан,
@ Пол, проблемы 8086 были теми, с которыми я больше всего был связан, поэтому они кажутся мне большими. Однако инструменты для написания программного обеспечения даже на мэйнфреймах были поразительно сырыми по современным стандартам. Редакторы, как правило, были ближе к Эдлину, чем к Emacs. Еще в 1982 году я использовал NUROS (удаленная операционная система университета Небраски) на оборудовании IBM. Задания были запрограммированы и выполнялись с использованием «виртуальных» перфокарт. И давайте не будем забывать об ошибках 2000 года, в основном порожденных большим железом из-за ощутимых ограничений в хранении.
Чарльз Грант
2

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

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

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

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

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


источник
+1 «Современные приложения являются более сложными, чем они были 20-30 лет назад»
Амир Резаи
2

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

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

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

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

Майк Данлавей
источник
1

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

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

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

user281377
источник
1
Я не согласен с тем, что следует избегать инноваций и что устаревшие технологии или методы никогда не должны быть устаревшими. Можно также прекратить писать любые программы и просто использовать то, что у нас есть ...
Тимви,
Тимви: Я не спорю с инновациями. Это просто причина, по которой так сложно писать хороший код.
user281377
1

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

RobotHumans
источник
Встраиваемые парни пишут приличное количество сборок.
Пол Натан
@Paul Nathan True
RobotHumans
0

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

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

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

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

Омега Центавра
источник
Похоже, молодая компания, которая еще не
Торбьерн: Удивительно, что это было вокруг в течение почти трех десятилетий. И это на самом деле очень хорошо. Конечно, есть бизнес-модели, которые очень чутко реагируют на запросы клиентов (нас), а некоторые очень ориентированы на качество. Это действительно трудно быть обоими.
Омега Центавра
0

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

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

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

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

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

Ник Бедфорд
источник
0

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

Брайан Карлтон
источник
-2

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

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

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

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

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

С. Лотт
источник
Для меня «хороший код» таков, что уменьшает количество ошибок. Теперь это может быть достигнуто многими способами.
Амир Резаи
@ Амир Резаи: «Определение« хорошего кода »индивидуально». «Хороший код таков, что уменьшает количество ошибок». Пожалуйста, выберите только одно определение и обновите свой вопрос, включив в него только одно определение.
С.Лотт
Что ж, «хороший код» таков, что он уменьшает количество ошибок »- это мое личное представление о« хорошем коде ». Я думаю, что все знают, когда проект нуждается в очистке или нет .
Амир Резаи
@ Амир Резаи: Это моя точка зрения. Если вы не можете (или не хотите) определить «хорошо» в вопросе, мы не можем сравнивать. Вы можете утверждать, что количество ошибок одинаково. Некоторые могут утверждать, что стоимость ошибок снижается. Другой может утверждать, что бизнес-риск из-за планирования ошибок повышается. Без единого определения «хорошо» мы все можем говорить о разных вещах. Пожалуйста, обновите вопрос.
С.Лотт
Хороший код: он скомпилирован, прошел тестирование, получил одобрение пользователя и запущен в производство. Просто надеюсь, что никто не хочет изменить это.
JeffO