Как людям удается писать и поддерживать чрезвычайно сложный и трудный для чтения код? [закрыто]

Чтение исходного кода SQLite - миссия IMO, невозможная. Тем не менее, это полезная часть довольно сложного программного обеспечения (в конце концов, это полноценная встроенная база данных), которую можно загружать, компилировать и использовать из чужого кода, и она постоянно обновляется.

Как людям удается писать и поддерживать такой чрезвычайно сложный и трудный для чтения код?

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

http://codebetter.com/blogs/dru.sellers/archive/2009/09/25/complex-vs-complicated.aspx

Если говорить более лично, я работаю над базой кода, содержащей более 1 миллиона строк кода. Я был в нем от линии 1 до ее текущего состояния. Чем больше вы заняты (читайте больше в коде), тем легче становится. Я не могу сказать вам, что делает каждая строка, но я могу сказать, что вам нужно было начать поиск определенной задачи или ошибки. Это просто естественно.

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

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

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

http://sqlite.org/testing.html

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

РЕДАКТИРОВАТЬ: Этот вопрос был поднят из мертвых, кажется! И чуть больше года спустя, на той же странице сообщается, что у них в 1177 раз больше строк тестирования кода, чем при производстве!

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

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

На самом деле SQLite относительно мал в масштабах «больших программных проектов», но если вы посмотрите на что-то вроде операционной системы Windows, у вас будут люди, которые просто работают над ядром, люди, которые просто работают над оболочкой, люди, которые просто работают в Internet Explorer - люди, которые просто работают в диспетчере окон и т. д. и т. д. Тот, кто работает в «оболочке», не сможет исправить ошибку в ядре без промедления.

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

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

Для проектов с открытым исходным кодом, таких как SQLite, на самом деле это немного сложнее, потому что у существующих разработчиков нет мотивации «обучать» новых разработчиков. Таким образом, вы обнаружите, что вы немного больше. Но вы все равно можете найти помощь на форумах разработчиков или в списках рассылки (например, просто опубликовать вопрос типа «Я хотел бы реализовать такую ​​функцию» или «Я нашел ошибку XYZ, где мне начать искать?», И вы, вероятно, получите некоторая форма помощи.

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

Мой совет:

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

Для меня SQLite далеко не сложен и ничего сложного. Область этого проекта требует глубокого понимания широких концепций.

Одна вещь, не упомянутая в других ответах: «Это естественно для них». Большинство людей хотят писать хороший код, но они настроены на написание плохого кода. Некоторые из программистов, с которыми я встречался, являются, естественно, ЛИНЕЙНЫМИ мыслителями + иногда очень умно они предлагают сложные решения. Большинство таких людей не тратят время на чтение или изучение книги, которую они изучают, когда и когда работа требует этого.

Как людям удается писать и поддерживать такой чрезвычайно сложный и трудный для чтения код?

Если они являются оригинальными программистами, и они продолжают поддерживать его, они не видят его «сложным и трудным для чтения». Они, вероятно, считают это «простым и легким для чтения», так как они написали это сами.

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

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

Управлять становится намного проще, если все делается одинаково. Я не знаю код SQLite, но я работаю в среде, где есть несколько проектов. Помимо понимания бизнес-кейса (например, логики), поскольку все в основном делается одинаково везде (доступ к базе данных и т. Д.), Относительно легко начать работу над другим проектом. Короткий текст: Руководящие указания по кодированию - соответствующим образом - делают жизнь и такой код намного проще. Это может быть одним из помощников кодеров SQLite.

• Если вы являетесь первоначальным автором программного обеспечения, и вы работали с ним более 10 лет, и вы гений, то, возможно, можно понять все это. У больших частей сложного программного обеспечения (такого как SQLite или ядро ​​Linux) действительно обычно есть только один оригинальный автор, имеющий полное, глубокое понимание этого, даже если другие люди внесли свой вклад.
• Если архитектура программного обеспечения нормальна (высокая сплоченность, низкая связь), понимание всего этого не является обязательным условием для внесения в нее полезных дополнений и модификаций.
• Понимание СУБД или ОС - это особые случаи, требующие глубокого понимания основополагающих принципов CS. Не так с «обычными» программными приложениями.

Они пытаются написать это простым, но не простым способом.

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

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

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