Скажите как понять, какая часть за что отвечает в больших проектах, состаящих из сотен файлов, как например ядро линукс. Лично я путаюсь в этом океане кода, и не могу представить как ведется поддержка таких гигантов. Как дописывать новый функционал и искать ошибки?
- Вопрос задан более двух лет назад
- 1689 просмотров
3 комментария
Простой 3 комментария
Мне кажется, на этот вопрос не может быть однозначного ответа. Главное —
периодически нужно проветривать помещение и самому выходить на улицу, делать зарядку для глаз.
А так, все средства для визуализации хороши, лично мне нравится карандаш, ручка, ватман и стикеры. Нашел точку входа — и погнал.
Если есть документация — это, конечно, хорошо, а если есть знающие люди — это тоже замечательно. Но в любом случае, чтобы погрузиться в проект, как ни крути, придется код прочесть и как-то у себя в воображении отобразить.
Как НЕ надо писать программы! Обсуждаем весь процесс разработки ПО | Ошибки программиста
Как разбираться в огромных исходниках?
нужно проветривать помещение и самому выходить на улицу
Наверное имелось ввиду что выходить на улицу нужно через окно, которое открыли для проветривания помещения.
Решения вопроса 2
Perl 5, C, C++, компьютерные сети
В программировании есть такое понятие как модульность — большие системы делятся на модули, каждые из которых отвечают за свою часть работы — ядро linux, графическая подсистема, драйвера. Если взять ядро линукс, то там есть много модулей — драйвера на оборудование — видеокаты, звуковые карты и т.д. на самом нижнем уровне, подсистема для мултиплексирования ввода-вывода (select/poll/epoll) и т.д. Каждый разработчик занимается своей задачей, своим модулем в ядре Linux. Например, если ты пишешь на Node.js можно начать интерисоваться, что же внутри. И найти цепочку, которая ведет в ядро Linux (упрощенно): Node.js -> libuv -> epoll и далее разбираться, как этот системный вызов работает на уровне ядра и начать изучать исходный код ядра Linux для этого системного вызова.
Ответ написан более двух лет назад
Комментировать
Нравится 4 Комментировать
React.JS/FrontEnd engineer
Самым твоим большим ограничением, внезапно, будет твоя собственная оперативная память, которая, в моменте, согласно исследований британских ученых, способна удерживать 7+-2 объекта (от 5 до 9 в среднем). Если у тебя объектов для рассмотрения тысячи, десятки тысяч или сотен тысяч и больше — желаю успехов. 🙂
Вторым твоим ограничением будет неспособность долго и пристально фокусироваться на процессе сканирования чужого кода. Внимание будет постоянно пытаться убежать куда-то, на что-то менее пугающее, что-то более понятное и привычное, приятное. Это называется прокрастинация, Макс Дорофеев фпомасч.
Программирование. Как начать писать программу?
Более того, по мере сканирования кода будет возникать масса моментов, где непонятно что сделано, как сделано, зачем сделано, какие у этого последствия, соответственно все это надо расследовать отдельно и как-то запоминать, документировать, структурировать и пр. Что будет еще больше переключать из контекста в контекст и нужно уметь их фиксировать и как-то возвращаться, восстанавливать картину. Это весьма утомительно, а ресурс мозга таки ограничен.
Если ты живешь на вредных привычках, в частности презрительно относишься к важности сна, увлекаешься его депривацией, а, тем паче, сломал себе режим, то возможности будут еще более ограничены.
Третьим твоим ограничением будет глубинное нежелание заниматься этой фигнёй, ибо душа требует великого и прекрасного, а тут. Существенный процент разработчиков программируют не для души, а для прокорму, пока проекту умещаются в разумные пределы, их страдания умеренные. На больших/сложных/запутанных/некачественных/запущенных проектах начинается стремительное выгорание в труху.
Ах да, если ты уже успел подвыгореть, то всё вышесказанное сильно усугубляется.
Между тем существуют разработчики, которые испытывают удовольствие от той власти, которую они имеют над машинами, их буквально прёт, поэтому все эти сложности им нипочём. В отдельные временные промежутки разные разработчики могут на время или даже надолго входить в подобное потоковое состояние.
Подспудно многие мечтают, ищут для себя такой проект, который вот так вот будет зажигать изнутри, когда совершенно фиолетово, какой день на календаре, какое время суток, как давно ты ел/пил/спал — тебя так прёт, что остановиться невозможно. В некотором смысле это сверхчеловеческое состояние.
Основные прорывы происходят именно в этом ресурсном состоянии. Искать надо его, если сумеешь найти и удержать — считай что ты счастливый человек.
Источник: qna.habr.com
Как писать большие программы и не путаться в них
Есть такой вопрос: Подскажите пожалуйста как вы строите приложение? Ну на бумаге или на компьютере может блок схемы строите (если можно поконкретнее)? А то когда в приложении становиться более менее много функций, да и проект если не маленький, начинаешь путаться, что-то забывать, где-то если исправил, что-то, то от него зависящее бывает, тоже нужно подправить, а забыл. Вообще, что можете посоветовать? И сразу прошу не оставлять тут «умные изречения», которые не отвечают на вопрос, просто если кого-то хочется окорбить (хоть даже шутя), то оставьте при себе своё мнение P.S. просто достали «шутники».
Как лучше писать более менее большой проект?
Последний раз редактировалось Casper-SC; 01.12.2009 в 04:49 .
конкретных функций явно не указано. В статье Modules called, they want their integrity back Джош Чик описывает некоторые подводные камни, связанные с непродуманным включением модулей, реализующих ненужный или неожиданный функционал.
Неверное форматирование
Существуют антипаттерны форматирования, связанные с расстановкой отступов, пробелов, именованиями и комментированием, из-за которых восприятие кода излишне усложняется. Особенно следует отметить важность правильного именования, поскольку грамотно составленные названия методов значительно облегчают жизнь разработчику. Аналогично, важно учитывать количество и имена параметров. Хотя, подобные ошибки усложняют код не так сильно, как излишне глубокие вложения, их не стоит сбрасывать со счетов. Рассмотрим следующий пример:
(defn resume-game [] (let [file-name (get-file) game-type (:game-type file-name)] (if (= 1 game-type) (display «We’ve loaded your game. It’s the computer’s turn.») (display «We’ve loaded your game. It’s the human’s turn.»))))
Это простая функция, но чтобы ее понять, требуется приложить некоторые усилия. Дело в несогласованном использовании отступов, пробелов и имен. Давайте подробнее рассмотрим ошибки, допущенные в это функции. Отступы в специальной форме let отличаются на каждой из трех строк. Такая же проблема с отступами наблюдается и в специальной форме if.
Поскольку в Clojure подразумевается else, важно правильно выравнивать код, чтобы обеспечить его удобочитаемость. Кроме того, отметим ненужный пробел после связки game-type. Наконец, имена тоже очень странные. Может показаться, что file-name соответствует содержимому, а не имени файла. Значение game-type выражается в целых числах; соответственно, речь идет не о типе игры, а о числе, ассоциируемом с типом игры.
Неправильное сложение, сильное связывание и неверное форматирование – вот три наиболее распространенные причины, по которым излишне усложняется код. К счастью, существует ряд способов измерения сложности и выяснения, на каком этапе она начала возникать.
Параметры сложности кода
Ученые-информатики занимаются измерением сложности кода уже не одно десятилетие, но нам по-прежнему очень сложно выразить ее количественно. В отличие от обрабатывающей промышленности, где процессы и процедуры обычно анализируются в контексте детально описанных параметров, при разработке ПО зачастую не удается дать реальные, количественно исчисляемые измерения качеств нашего кода. На производственном предприятии могут существовать методы выявления излишней сложности или неэффективности рабочих процессов. Недостатки могут заключаться и в том, как упорядочены процессы, и в способах машинного исполнения этих процессов, и в порядке коммуникации управленцев с подчиненными, обучения персонала. В нашем же деле аналогичные точки обнаружения сложности и неэффективности выражены гораздо менее явно.
Сложность организации циклов в программе
Наиболее распространенный параметр для анализа сложности кода называется «Cyclomatic Metric» (уровень сложности циклов в программе). Он измеряет структурную сложность, определяемую в результате анализа логики управляющих конструкций (в сущности – количество путей в программе). Этот параметр был предложен Томасом Маккейдом, рекомендовавшим разработчикам измерять сложность кода, и если ее коэффициент превышает 10 – разбивать код на более мелкие модули. Данный параметр, конечно же, не гарантирует точной характеристики сложности софтверной системы, но он хорошо помогает при оценке покрытия кода тестами.
Сложность выражения в рамках условного оператора никогда не берется в расчет.
Параметры сложности Голстеда
В 1977 году Морис Голстед предложил учитывать ряд оценочных атрибутов, в частности, длину (length), словарь (vocabulary), объем (volume), трудоемкость (difficulty) и количество усилий (effort), затраченных на написание кода. В основном, эти параметры основаны на оценке операторов (изменений данных) и операндов (изменяемых данных) в коде.
Длина кода зависит от количества операторов и операндов. Сложность, обусловленная словарными проблемами, определяется степенью уникальности операторов и операндов (где небольшое количество часто повторяемых единиц свидетельствует о сравнительно низкой сложности). Первые два параметра в комбинации образуют третий – объем.
Объем позволяет судить о сложности кода в зависимости от размера базы кода. Трудоемкость связана с написанием и поддержкой кода, причем она прямо пропорциональна количеству уникальных операторов и операндов. Наконец, количество усилий связано с объемом и трудоемкостью кода. Все эти параметры определяются по исходному коду, выполнять код при этом не требуется.
Упомянутые параметры могут сообщить ценную информацию, но не следует их переоценивать. Как минимум, они стимулируют разработчиков обсуждать важные аспекты кода – используемый словарь, длину кода, трудоемкость его написания и поддержки.
Принцип абсолютного приоритета
Мика Мартин в одноименной статье предложил «условие абсолютного приоритета» (Absolute Priority Premise) как средство оценивания кода для объективного суждения о нем. Поскольку мы привыкли расценивать код в зависимости от его статических и динамических качеств – а такие оценки по определению являются субъективными – Мика попытался исключить из этой системы критериев динамический аспект.
В качестве отправной точки он взял «условие очередности преобразований» (Transformation Priority Premise). В презентации Мики меня особенно заинтересовал тезис о том, что разработка через тестирование (TDD) может давать далеко не идеальные алгоритмы в случаях, когда решение достигается окольным путем.
Подобный «далеко не идеальный» путь возникает именно из-за упомянутой выше случайной сложности. Не всегда удается с уверенностью определить, на каком этапе зародилась такая сложность, и как от нее избавиться. Потенциальная польза условия абсолютного приоритета (APP) заключается в том, что он позволяет присваивать различным операциям балльные значения.
При этом, учитываются сущности шести категорий: константы, связки, вызовы методов, условные операторы, циклы и операторы присваивания. Каждый из этих компонентов добавляет баллы к общей сумме. Так, константа оценивается в 1 балл, а цикл while – в 5 баллов. В сумме получаем общую «массу» кода, по которой мы можем судить об общей сложности кода. Теоретически, малая сумма должна свидетельствовать о том, что данное решение является сравнительно простым, прямолинейным и не содержит лишних ненужных наворотов.