Придираетесь. В любом более-менее крупном проекте множество классов, и рефакторинг предполагает изменение интерфейса части из них, а это подразумевает, само собой, изменение тестов. В итоге, вы тратите в 2 раза больше времени, чем на просто рефакторинг без тестов. Если вам надо править еще документацию − то в 3 раза больше времени.
1) гуглить/читать диздоки, hakers guide, architecture overview и подобные документы
2) прочтя, открыть код, например, начав с функции main() (или с кода загрузки, если речь о ядре Линукса) и смотреть, кто кого и как вызывает.
3) делать пометки и рисовать схемы на заранее припасенных листочках бумаги
4) периодически сопоставлять то, что написано в коде, с тем, что в документации
5) после определенного времени понимание кода придет само собой.
// file db.cpp: Defines main() for the mongod program.
И, ниже,
int main(int argc, char* argv[]) {
int exitCode = mongoDbMain(argc, argv);
::_exit(exitCode);
}
Вот он, main. Он вызывает mongoDbMain(), которая, в свою очередь:
— создает объект staticObserver
— большой портянкой кода заполняет описание опций для boost::program_options (парсер опций командной строки из библиотеки Boost, гуглите и изучайте, если не знаете, что это, так как любой уважающий себя разработчик знает эту библиотеку)
— вызывает setupCoreSignals(), видимо что-то связанное с сигналами
— хитрым-прехитрым (и наверняка недокументированным) костылем проверяет порядок следования байт в процессоре, LE или BE и отказывается работать с BE
— долго и мучительно разбирает опции командной строки
—
— вызывает dataFileSync.go();, запуская в отдельном потоке бесконечный цикл, который сбрасывает данные на диск, спит несколько миллисекунд и начинает все сначала.
— обрабатывает параметр command: если передано значение run, вызвается initAndListen(), которая заслуживает отдельного описания, если кратко, то она разбирается с временными файлами, инициализирует модули и scriptEngine, чинит БД, если надо, и начинает слушать порт на входящие соединения и обрабатывать их (assembleResponse()) в крошечном классе class MyMessageHandler ()
Как видите, ничего сверхсложного нет — просто читаете код, и смотрите, что он делает. Изучать код гораздо удобнее (чем читать через браузер на гитхабе, как я это делаю обычно), используя профессиональную ИДЕ с функцией перехода к определению класса/функции по Ctrl + click.
В общем, попробуйте начать, потом, если что-то непонятно, можете более конкретные вопросы задавать.
У меня есть вторая версия — если речь идет об ИБ и атаках, то очевидно, что все сервера с точки зрения участника атаки можно разделить на 3 группы: нейтральные (не принимают участия в атаке), те, что ЗА (на нашей стороне) и те, что ПРОТИВ (на стороне врага). Хотя, в вопросе говорится только о 2 группах, это странно.
А вообще, интуиция подсказывает, что это могут быть какие-то фоновые сервисы, которые зачем-то индексируют в фоновом режиме ваш NTFS диск и тормозят работу.
Однако, способ-костыль есть. Если элементу внутри overflow: hidden присвоить AP, и убрать position: relative у всех его предков внутри скрытого дива, элемент не будет обрезаться.
Есть же должности типа Junior Developer и стажер (это обычно студентов, которые ничего не знают, берут). Изучайте основы выбранного языка (лучше наверно Java), основные библиотеки и рассылайте резюме. Уверен, что это более чем реально.
HTML можно резать регуляркой на блоки (блоки типов: доктайп, комментарий, PI, тег, CDATA, текст), например, с помощью preg_split и дальше проходить по массиву матчей и в них менять что требуется. Но это не очень простая задача, например, для тега, если вы пишете регулярку, надо помнить, что символ «больше» внутри кавычек не закрывает тег, и подобные сложности. Это сложно и чревато ошибками.
Вам наверно проще использовать DOM или потоковый парсер XML.
ssh (name@host/port) mysqldump remoteDatabase | mysql -uusername -p localDatabase
, тогда сервер для ssh не нужен.
ssh (команда) выполняет команду на удаленном хосте без открытия интерактивной сессии.