Написание программного обеспечения легче, чем чтение и понимание с нуля? [закрыто]

Я и мой друг обсуждали вчера различие между написанием большого программного обеспечения на C ++ и пониманием его как новобранца.

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

Сначала это звучит странно, но после того, как мы немного подумали, это показалось разумным

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

1. Чтение хорошего кода
2. Написание плохого кода
3. Написание хорошего кода
4. Чтение плохого кода

Приведенный выше рейтинг приводит к 2 выводам

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

Конечно, хороший код и плохой код - это широкие обобщения. Я рекомендую Code Complete и Clean Code для более подробной информации о хорошем коде.

Этот вопрос обращается к ложному консенсусу. http://en.wikipedia.org/wiki/False-consensus_effect

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

Различия между написанием большого программного обеспечения на C ++ и пониманием его как новобранца

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

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

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

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

Если вы ветеран, опытный программист, то вы, вероятно, прочитаете код и скажете: «Да, хороший выбор, проверьте, о, я мог бы сделать X вместо Y» и т. Д. Вы можете изменить или настроить, но это сэкономьте огромное время на написании с нуля (если нет причин для этого).

Если вы новичок в программировании, то «вы не знаете, чего не знаете», и поэтому вам придется изобретать / изучать все мелочи, и, скорее всего, у вас будут некоторые недостатки в код. Тем не менее, вы, вероятно, будете лучше понимать язык.

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

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

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

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

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

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

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

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

Это приводит к вопросу: имеет ли это значение?

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

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

Я нахожусь в ответе StMotorSpark, просто добавив: «
Это зависит от многих факторов, это не может быть вопрос« да »или« нет », например:

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