Comments 17
Я пишу один, но проекты бывают такими большими, что я ещё не закончив не могу без диаграмм вспомнить архитектуру. А Вы предлагаете забивать себе мозг тем, что пишет вообще кто-то другой. Обычные проекты, это штук 20 папок в каждой из которых куча файлов в которых реализуются части алгоритмов. Какой прок от чтения разрозненных частей алгоритмов?
Для этого есть документация: «Вот функция системы, она влияет некоторые другие функций которые делают вот это и вот так.»
В длительных проектах сложно держать все в голове, в нашей компании разрабатывалось изначально 3 программных продукта которые зависимы друг от друга, и в каждом из них более сотни фишек многие из которых влияют на поведение остальных, год назад появились дополнительные продукты и привлекаются новые команды, в том числе фрилансеры на небольшие задачи.
Если не документация — прочтение тонны кода превращаются в ад (первый релиз был 7 лет назад)…
правило «разделяй и властвую» — отлично справляется, иначе бы каждый программист то и делал что код читал… пока до конца дойдешь — не помнишь с чего начиналось…
а пробелы новых сотрудников есть смысл заполнять по мере создания ими (сотрудниками новыми) конкретных решений, с этим помогают люди которые создавали зависимые части программы.
быстрее спросить пояснение, чем лазить в дебрях чужого код… а херовый код пишут все. Условие разные и срочность решения задачи бывает не оставляет времени на поиск элегантного решения с хорошо структурированным кодом.
В длительных проектах сложно держать все в голове, в нашей компании разрабатывалось изначально 3 программных продукта которые зависимы друг от друга, и в каждом из них более сотни фишек многие из которых влияют на поведение остальных, год назад появились дополнительные продукты и привлекаются новые команды, в том числе фрилансеры на небольшие задачи.
Если не документация — прочтение тонны кода превращаются в ад (первый релиз был 7 лет назад)…
правило «разделяй и властвую» — отлично справляется, иначе бы каждый программист то и делал что код читал… пока до конца дойдешь — не помнишь с чего начиналось…
а пробелы новых сотрудников есть смысл заполнять по мере создания ими (сотрудниками новыми) конкретных решений, с этим помогают люди которые создавали зависимые части программы.
быстрее спросить пояснение, чем лазить в дебрях чужого код… а херовый код пишут все. Условие разные и срочность решения задачи бывает не оставляет времени на поиск элегантного решения с хорошо структурированным кодом.
Для некоторых проектов на почтение всего исходного кода могут уйти годы, а то и вся жизнь. Как тогда быть?
Покажите эту стаью разработчикам Microsoft Office!
Занимательная математика:
В проекте, с которым я работаю около 15 000 000 строк кода.
Пусть я буду читать по строке в секунду без остановки (без сна, обеда, отпуска, выходных и перерывов) — на это мне понадобится примерно полгода. Если всё же предположить, что я буду читать по строке в секунду только в рабочее время, то у меня уйдёт более двух лет. Всё это время я не буду работать и буду только читать код, который, кстати, за два года кардинально изменится. Если заложить время не только на чтение, но и на его обдумывание, то, боюсь представить время на такое обдумывание.
Такие дела.
В проекте, с которым я работаю около 15 000 000 строк кода.
Пусть я буду читать по строке в секунду без остановки (без сна, обеда, отпуска, выходных и перерывов) — на это мне понадобится примерно полгода. Если всё же предположить, что я буду читать по строке в секунду только в рабочее время, то у меня уйдёт более двух лет. Всё это время я не буду работать и буду только читать код, который, кстати, за два года кардинально изменится. Если заложить время не только на чтение, но и на его обдумывание, то, боюсь представить время на такое обдумывание.
Такие дела.
И все написаны вашей командой? Или Вы считаете строки в скомпилированном виде, который включает множество используемых библиотек?
Проект может быть достаточно большим, состоящим из разных компонентов, написанных разными отделами компании, так что даже без учета каких-то внешних библиотек — вполне может получиться дофига. Сам участвую в похожем проекте. Сколько строк кода — я не считал (как-то не дождался, когда отработает рекурсивный wc -l), но счет файлов идет на многие тысячи, и это да — все написанное компанией, где я работаю.
Сколько строк кода — я не считал (как-то не дождался, когда отработает рекурсивный wc -l)
Более правильно подсчитывать с помощью специальной утилиты cloc (и в репозиториях обычно есть).
Можно читать только тот код, с которым как-то взаимодействуешь. И так по мере его поступления.
Вредный совет, неправильные выводы. Чтобы знать всю систему, особенно, если это действительно большая система, надо уметь абстрагироваться от мелочей. ООП, с его декомпозицией, перетекающей в инкапсуляцию, позволило строить действительно большие системы именно благодаря разделению контекстов с сокращением их объёма до реально объемлемых пределов.
Быть экспертом по всей ли стстеме, либо по какому-то участку системы — не вредно, но всё имеет цену. Проблема не в "оно вам надо, такое беспокойство?", а в том, настлько ли оно полезно, насколько трудозатратно (читай: дорого).
Или так: у тебя есть машина? Разбери её. Всю. Если машины нет, разбери троллейбус. Нет, собирать не обязательно, главное — разобрать, чтобы знать и понимать. И рассуждать об этом на собраниях. И будешь ценным кадром.
То есть нет, вру: оказывается, умение собирать может быть намного полезней, и ценится дороже.
Бессмысленно просто читать код, это же не книга, где есть начало и конец. Тем более, объём может быть в миллионы строк, и ещё он имеет естественное свойство постоянно меняться.
На самом деле, чтобы начать врубаться, достаточно читать диффы всех новых вмерженных в мастер веток — а не только того, что полагается в рамках назначенного лично тебе code review. В таком случае, будет достаточно нескольких месяцев, чтобы обрести новый, более глубокий уровень понимания (хотя экспертом по всему продукту стать не получится, для этого нужно писать код во всех его частях, а не только читать). Выделить на это достаточно полчаса в день — после обеда, или по приходу на работу, или ещё какое у кого малопродуктивное время. Заодно и в рабочее состояние проще становится войти.
На самом деле, чтобы начать врубаться, достаточно читать диффы всех новых вмерженных в мастер веток — а не только того, что полагается в рамках назначенного лично тебе code review. В таком случае, будет достаточно нескольких месяцев, чтобы обрести новый, более глубокий уровень понимания (хотя экспертом по всему продукту стать не получится, для этого нужно писать код во всех его частях, а не только читать). Выделить на это достаточно полчаса в день — после обеда, или по приходу на работу, или ещё какое у кого малопродуктивное время. Заодно и в рабочее состояние проще становится войти.
Читать код еще не значит овладеть продуктом и понять все детали работы.
Я много раз «читал» код, например при переходе на новый проект или при смене работы. Чтение требовала от несколько дней до месяца. Но это всего лишь ознакомление и ни как не овладение. Более того, этот процесс демотивирует и неинтересен и скорее всего знания кода будет временным.
Из моей практики, лучше просто узнать что и где находится, создать наброски и диаграммы. А углубляться уже при работе на конкретную часть кода. У меня я команде всегда кто то хорошо знал часть кода, и все зависели друг от друга. Все, всегда участвовали во всех стратегических совещаний. Тех лид никогда не знал код полностью а только, кто за что отвечает и что где находится, где какие проблемы возникали и их решение. Сам он всегда имел кучу документов со описанием кода, проблем и узких мест, списка желании и так далее. Но и даже после этого знать вес код не было реально а проект имел средние размеры.
Ни кто не хочет тратить собственное время на код и проект, так ка другого свободного времени нет, на работе работаем а после каждый по своим делам. Лучше поменять работу и таким образом получить прибавку к зарплате чем заниматься сомнительно выгодным делом за счет собственного времени. К тому же если даже тратить столько времени на один проект ради становления каким то лидом и/или прибавки зарплаты то тогда как профессионал не будет прогресса разве что в конкретной среде. Знаю многих кто по этой схеме двигались и после многих лет уже работу менять не могут и зарплата уже не поднимается. Но зато все обращаются к ним, потому что проект знают от А до Я. Наверно после такого авторитета поменять работу уже не хочется, ну и что нет радости в работе и жизнь не имеет смысла…
Я много раз «читал» код, например при переходе на новый проект или при смене работы. Чтение требовала от несколько дней до месяца. Но это всего лишь ознакомление и ни как не овладение. Более того, этот процесс демотивирует и неинтересен и скорее всего знания кода будет временным.
Из моей практики, лучше просто узнать что и где находится, создать наброски и диаграммы. А углубляться уже при работе на конкретную часть кода. У меня я команде всегда кто то хорошо знал часть кода, и все зависели друг от друга. Все, всегда участвовали во всех стратегических совещаний. Тех лид никогда не знал код полностью а только, кто за что отвечает и что где находится, где какие проблемы возникали и их решение. Сам он всегда имел кучу документов со описанием кода, проблем и узких мест, списка желании и так далее. Но и даже после этого знать вес код не было реально а проект имел средние размеры.
Ни кто не хочет тратить собственное время на код и проект, так ка другого свободного времени нет, на работе работаем а после каждый по своим делам. Лучше поменять работу и таким образом получить прибавку к зарплате чем заниматься сомнительно выгодным делом за счет собственного времени. К тому же если даже тратить столько времени на один проект ради становления каким то лидом и/или прибавки зарплаты то тогда как профессионал не будет прогресса разве что в конкретной среде. Знаю многих кто по этой схеме двигались и после многих лет уже работу менять не могут и зарплата уже не поднимается. Но зато все обращаются к ним, потому что проект знают от А до Я. Наверно после такого авторитета поменять работу уже не хочется, ну и что нет радости в работе и жизнь не имеет смысла…
Все это конечно замечательно, но только в применении к маленьким проектам. Для более-менее приличных проектов должно быть грамотное разделение проекта на функциональные блоки, и тогда этот совет скорее стоит перефразировать как «прочитайте весь код модуля в котором ты работаешь».
А то ведь некоторые работают над такими продуктами, что чтение всего коде без осмысления может занять несколько лет, а уж с осмыслением…
А то ведь некоторые работают над такими продуктами, что чтение всего коде без осмысления может занять несколько лет, а уж с осмыслением…
Завидую я тем, кто может прочитать код проекта. Весь.
У нас в фирме почти 700 разработчиков и кода за десятки лет написано не просто много, а до… фига.
Главное понимать, как работает система в целом, знать ее шаблоны, особенности и дыры. А читать тысячи строк кода… ну, это если совсем много свободного времени…
У нас в фирме почти 700 разработчиков и кода за десятки лет написано не просто много, а до… фига.
Главное понимать, как работает система в целом, знать ее шаблоны, особенности и дыры. А читать тысячи строк кода… ну, это если совсем много свободного времени…
Sign up to leave a comment.
Прочитайте код своего продукта. Весь