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

Question

[Urukhayy]

Какие методы Вы используете, чтобы быстро найти участок в проекте с сотней тысяч строк?
К примеру для CTR + F у Вас запрос комментариев или названия функций, а может переменных?

Answer 1

[GavriKos]

При правильной архитектуре - никакие особые инструменты не нужны. Достаточно понимать что ищется - и ответ "где оно может лежать" придет сам собой.

Comments

[justaguest]

При большой правильной архитектуре ответ может с равной вероятностью лежать в любом из десятка файлов в директории, к которой получилось свести местоположение. Чтобы далеко не ходить за примерами — ядро Линукс, его трудно обвинить в неправильной архитектуре. И я только что подсчитал: в Linux-4.0.5 3159 директорий, и 48948 файлов.

[Анатолий Медведев]

justaguest: "При большой правильной архитектуре ответ может с равной вероятностью лежать в любом из десятка файлов в директории" - неверно, если только код не размазывать по всему что можно, это уже код на букву Г.

"ядро Линукс, его трудно обвинить в неправильной архитектуре" - сомнительное утверждение, учитывая что все ядро написано на "чистом" Си.

[justaguest]

Анатолий Медведев: ну, вот возьмем например функцию sendmsg(). Скажу сразу, она лежит в файле linux/net/socket.c. Но опять же, там около пятидесяти директорий — большинство из которых относятся к вендорам, но можно увидеть и более абстрактные, как «unix», «ipv4», «ipv6» — с первого взгляда не становится очевидно, куда смотреть.
Насчет С я тоже не соглашусь. Нет, я тоже не понимаю, почему нельзя писать на С++ — но нельзя определять плохую архитектуру по языку. Я предлагаю сразу тогда определять плохой архитектурой все, что написано не на Common Lisp — а что, отличный критерий, вон чуваки конкурентную войну в лохматых годах выиграли, пока Yahoo не продались.

[Анатолий Медведев]

justaguest: я не говорю что ядро Linux это плохая архитектура из-за того что ядро написано полностью(почти) на Си, но сама задача написания ядра вынуждает к такой архитектуре и писанине на Си. В любом случае ядро Linux это особый случай. Перед данным проектом стоят достаточно не тривиальные задачи (сточки зрения программирования).

Answer 2

[Максим Кудрявцев]

1)Ctrl + F
2)PHPStorm автоматически может перекидывать на определение функции
3)Отладчик

Если мы упоролись по хардкору, тогда любой hex-редактор

Answer 3

[nonlux]

vim + grep/ack + g]

Answer 4

[Анатолий Медведев]

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

Comments

[Urukhayy]

А если у вас одна функция в одном участке, а вызов ее в другом? И таких случаев множество. И Вам нужно в этой цепи найти функцию, которая вызывается той функцией, с которой вы сейчас работаете..

[Анатолий Медведев]

Urukhayy: вообще слабо понял о чем вы говорите. Давайте на примере. Есть участок кода с которым вы работаете в текущий момент (функция). В нем есть другие "функции", лично я получаю их "тела" если такое вдруг нужно при помощи стандартных средств IDE, а именно Ктр+ЛКМ. Так же если допустим я пришел в файл и знаю что нужная функция мне в нем то пользуюсь списком функций, предоставляемых IDE, с помощью него и произвожу навигацию. А есть еще такая удобная штука как иерархия классов.
Если вы говорите о том что вам нужно узнать где вызывается эта функция в коде проекта вообще, то вам помогут инструменты рефакторинга вашей IDE. Но лично у меня такой необходимости никогда не возникало, кроме как переименования класса допустим.

[justaguest]

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

[Анатолий Медведев]

justaguest: под правильной архитектурой подразумевается именно легко читаемость кода, когда код сам тебе говорит из каких частей состоит программа и как эти части взаимодействуют друг с другом. Документация здесь не причем, с плохой архитектурой она мало чем поможет.
Простой пример для С++/Qt проекта.
Есть некое главное окно в котором есть менюшка которая допустим имеет пункт "Компании", этот пункт открывает окошко в котором список компаний, и их можно удалять/добавлять/редактировать/etc. Ну и мне вдруг надо поправить что то по поводу добавления новой компании, автозаполнение для полей допустим каких то сделать. Что я ожидаю и при должной архитектуре должен увидеть в коде? Ну первое функцию main в которой создается объект класса MainWindows (главное окно), в данном классе в конструкторе должна каким то образом создаваться эта менюшка. Находим к какой слот вызывает соответсвующий пункт меню. В данном слоте должен создаваться объект класса CompanyDialog или CompanyList (главное что бы имена функций, слотов и классов явно отражали свою суть). Уже в данном классе смотрим в ожидаемом месте (в конструкторе) менюшку, ищем слот который ожидаемо называеться addCompany ну и т.д. Главное в правильной архитектуре четкое разделение и однозначность имен функций и классов. Что бы человек смотря на программу уже примерно представлял как могут называться нужные ему классы и функции. Вот что я называю правильной архитектурой. Я привел пример завязаный на GUI, но данный подход должен быть во всем и в первую очередь в бекэнде(краткие но емкие комментарии о том что делается, обязательны) , просто с GUI проще понять о чем я хотел сказать.

[justaguest]

Анатолий Медведев: да в том то и дела, что читаемость кода отнюдь не означает, что местонахождение той или иной функции будет очевидно. Оно очевидно, пока проект не стал большим. Вот захожу я, например, в директорию UI редактора YI(кстати у него как раз кода немного), и спрашиваю себя, где находится функция, которая помещает надпись текущего включенного режима на нижнюю часть графического интерфейса. Здесь есть файл «Pango.hs» — судя по названию, там какая-то базовая инициализация, и обертки над базовыми функциями, типа «создать текстовый виджет», наша функция может находится там. Еще здесь есть файл «SimpleLayout.hs» — нетрудно догадаться, что там расположение виджетов по-умолчанию, потому что нигде нет xml-файла «.glade», т.е. все описано в коде. Может наша функция там быть? Да! Потому что, если виджет с текстом текущего режима создается тут, то именно отсюда должна экспортироваться функция, дающая возможность что-то поменять. Есть еще некий «Utils.hs» — вероятно какие-то вспомогательные абстрактные от интерфейса функции — может наша функция быть там? Почему бы и нет: редактор поддерживает два интерфейса, в обоих установка текста с режимом — необходимый функционал, следовательно там может находится наша функция, работающая независимо от интерфейса. Тут есть еще файлы, но я и так много написал, потому просто скажу, что, наверное, можно найти и к ним причины, почему функция должна быть именно там. И, под конец главный вопрос: можно ли назвать эту архитектуру плохой? Да ни в коем случае, я не могу себе представить, как можно дать файлам исходного кода еще более говорящие имена, чем они есть сейчас! Но это не лишает нас необходимости искать функцию по файлам.

[Анатолий Медведев]

justaguest: я нашел проект о котором вы говорите. Попытался вникнуть но я не знаю Хаскель и его особенностей. Но вашу задачу я бы решал так, нашел функцию отвечающей за включение/переключение режима, как по мне логичнее было бы от туда посылать "сигнал" о том какой режим сейчас активен и уже бы посмотрел кто "ловит" этот сигнал, иначе пришлось бы по по таймауту проверять какой режим активен, а это мягко говоря неэффективно.

[justaguest]

Анатолий Медведев: ну да, само использование там в файле «StateUtils.hs» вдалеке от ГУЙ, вот только он там вызывает еще одну функцию, которая другую… Но суть не в том — я просто показал конкретный пример, когда местонахождение функции не очевидно, а я бы отнюдь не назвал архитектуру плохой, да и проект не особо велик.

[Анатолий Медведев]

justaguest: не могу говорить о качестве архитектуры проекта не зная языка на котором он пишется.

[justaguest]

Анатолий Медведев: да черт с ним, с языком — я привел примеры по именам файлов, ведь суть же спора: если не знаешь, в каком файле находится, следовательно плохая архитектура? Вот я и расписал имена файлов, что бы показать, что их нельзя было назвать лучше, но очевиднее от этого ничего не становится. Можно представить, что там находится код на С++, это сути в данном случае не изменит.

[Анатолий Медведев]

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

[justaguest]

Анатолий Медведев: так ведь ясен же контент каждого из этих файлов — но это не приближает к пониманию, где находится та функция. Если критиковать, то критиковать с аргументами: я привел названия файлов, и на мой взгляд они достаточно полно описывают свой функционал. Ты бы мог их назвать еще лучше?

[Анатолий Медведев]

justaguest: ну так если из названия можно определить контент файла, соответственно можно с легкостью определить и какие функции там лежат. Если нет, значит тут что то не так c названием файла или с контентом файла (возможно стоит разбить или объединить файл(ы)). Конечно все это верно при учете знания языка. Я не знаю хаскел и не могу сказать что понимаю контент файлов в полной мере, так что не могу судить о названиях файлов.

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

И надеюсь мы говорим о ООП, а не функциональщине. ФП подразумевает говнокод в плане архитектуры сколько-нибудь большого приложения априори.

[justaguest]

Анатолий Медведев: мы говорим абстрактно — я не вижу способов, как на обсуждаемый вопрос может повлиять парадигма.

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

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

[Анатолий Медведев]

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

Да, база такая, но все нужно использовать разумно. Если одна и таже функция используется в разных частях программы на разных слоях абстрактности, значит что то мы делаем не так. Если функция(не челен класса) используется во множестве разных файлов не объединенных в один "модуль" (не файл), то это порождает задачи которые высказал ТС, а так же влечет за собой повышенные риски при модификации кода.

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

[justaguest]

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

Одна и та же функция может использоваться на разных слоях абстракции, когда все сделано правильно — к примеру конкатенация строк. Плюс разного рода абстрактные функции; предполагаю, что количество таких функций может варьироваться в зависимости от языка — например в Хаскелл к этому набору можно добавить функторы и монады.

Второе замечание: разницы между «свободной» функцией и методом класса особой нет, потому что, например, в языке C# функции не-члены не могут быть созданы в принципе; там это прекрасно обходится статическими методами — которые, думаю, можно семантически приравнять к обычным функциям. Кто-то мог бы аргументировать, что это лучше, т.к. позволяет видеть, из какого класса функция вызывается — на случай существования одноименных функций. Но этот случай должен прекрасно решаться аргументами различных типов — если же не решается, значит функции все же делают нечто различное, и должны быть названы так же по-разному (кстати, в свете такой ситуации обычные функции даже лучше ☺).

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

[Анатолий Медведев]

justaguest: конкатенция строк это перегруженная функция(оператор) класса строк, суть метод класса, как правило оператор +.
Функция может использоваться но это ИМХО неправильно, нарушается восприятие и усложняется архитектура, увеличиваются риски модификации.

Разницы между «свободной» функцией и методом класса особой нет если работать в режиме ФП. C# все правильно в этом плане сделано, обходить это неверный путь. Мне кажется проблема в том что вы мыслите в разрезе взаимодействия данных и функций, а я говорю о взаимодействии объектов в контексте архитектуры программы. В программе может быть только одна функция не принадлежащая классу, это Main. ИМХО конечно.

[justaguest]

Анатолий Медведев: из первого параграфа я так и не понял — было это возражение, или согласие с чем-то? Конкатенация — метод класса… Хорошо. Но это же не мешает им пользоваться на разных методах абстракции? А второе предложение относится к первому? То есть все таки нельзя?
У меня имеется подозрение, что мы немного разошлись в беседе.

Кстати в C# даже Main принадлежит классу ☺ Прошу прощения, я вот после того, как написал прошлый комментарий, подумал, что его можно неправильно понять, потому я допишу тут немного пояснений — когда я говорил об отсутствии разницы, я думал о сравнении статического метода класса с обычным «безклассовым» методом. Разумеется, если говорить о нестатическом методе класса, то разница большая, но я не это имел ввиду.

По последнему параграфу, я думаю, стоит рассказать одну вещь. Она имеет косвенное отношение к теме, но мне кажется, ее стоит упомянуть. Когда я впервые познакомился с языком C#, у меня почти не было опыта, и я написал некое приложение — и качество там было, откровенно хреновым. Наверное несправедливо будет возлагать вину только на мою неопытность — не раз приходилось делать кривые решения и по вине кривого дизайна API в .net, и порой библейской документации на MSDN.

Как бы то ни было, я совершил при разработке одну ошибку, которая абсолютно не очевидна, пока кто-то носом в нее не ткнет. Эта ошибка называется «побочные эффекты».

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

Значительно позже я познакомился с ФП, и меня настигло просветление. Все переменные, которые использует функция должны передаваться в аргументах. Если существует что-то в объекте класса, что функция использует, оно в идеале должно быть константой, и никогда не изменяться на протяжении жизни объекта. И, если функция не полагается ни на какие переменные в объекте, ее лучше всего сделать статической — хуже не будет, зато сразу очевидно отсутствие побочных эффектов.

Вообще ФП — по-крайней мере Хаскелл — настоящая кладезь идей. Существует даже шутка «Haskell is the best Imperative language», не без доли правды в ней. Правда писать код с непривычки сложно, надо очень серьезно поменять мышление, но есть одна особенность — если ты написал приложение, и оно скомпилировалось, значит почти наверняка будет работать (не исключены логические ошибки, но значительная часть проблем императивного кода в функциональном просто отсутствует). Но самое главное — эти идеи, они абстрактны, и не относятся к конкретному языку, их можно применять в любой парадигме! Я за время работы успел слишком много времени потратить на отладку чего-то, мистическим образом работающего неправильно, и идея заставить компилятор проверять как можно больше кода вместо меня, мне очень по душе.

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

[justaguest]

Упс, баг на тостере — там в ссылке продолжение текста. Там был смайл, намек на то, что статья по ссылке саркастическая.

[justaguest]

Ого-у… о.О Еще один баг — я перезагрузил страницу, и параграф исчез…

Там был последний параграф, что некоторые считают, что изучение Хаскелл и Питон ухудшает программиста, и ссылка на lukeplant.me.uk/blog/posts/why-learning-haskell-py...

[justaguest]

Да, «статичность» = «отсутствие побочных эффектов» — это я именно про C#, конечно же.

Answer 5

[Рамиль Хамитов]

Ctrl+F

Comments

[Urukhayy]

Ищите комментарий?

[justaguest]

Urukhayy: видимо да, но вероятно промахнулся, и нажал на ответ.

[Urukhayy]

justaguest: Забавно получилось. Имелось в виду, Вы ищите комментарий в коде, или название функций?)

[justaguest]

Urukhayy: это был очевидный сарказм на основании бессмысленности этого ответа☺ Вот вы знаете, что такое «Ctrl+f»? В Vim это перемотка экрана. Даже, если предположить, что «Ctrl+f» стоит за «Ctrl + Find» — все равно остается куча вопросов: что ищет, где ищет, как ищет, с регулярками, или без… Черт, да это один из самых бессмысленных ответов!

Answer 6

[Виталий Пухов]

сотня тысяч строк в нормальном проекте в 1 файле не лежит, в своей работе использую notepad++ с его поиском в папке
на выходе получается массив строк с подстрокой, чаще всего по ним можно определить та эта строка или нет, даже если их несколько тысяч выходит.

Answer 7

[Mrrl]

Go to definition и Find all references в Visual Studio. Реже - поиск имени функции или строки по всему solution.

Answer 8

[justaguest]

grep с регулярными выражениями, и немного смекалки — самый лучший набор инструментов.

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

Живой пример: только вчера закончил писать курсовую, где в качестве практики фиксил небольшой баг в GUI текстового редактора Yi на Haskell (в котором я на момент написания этих слова разбираюсь чуть ниже среднего). Поскольку я не знаю ни архитектуры, не API, а в существующих статьях про интерфейс редактора нет ни слова, большая часть работы выглядела следующим образом:

1. Войти в директорию, в которой предположительно — исходя из ее названия — находится интригующая меня часть кода
   
2. Пойдя от обратного, спросить себя, как могла бы быть реализована та часть, которая меня сейчас интересует
   
3. Найти в своих рассуждениях ключевые моменты, перевести их в ключевые слова, которые могли бы быть упомянуты в именах переменных/функций, комментариях, частично или полностью
   
4. grep'нуть ключевые слова по коду, и пробежаться глазами по имеющимся линиям; особо интересные моменты просмотреть, открыв в текстовом редакторе
   
5. Спросить, собрал ли я достаточно информации для понимания проблемы и возможного фикса; если нет, goto §2