Понимание общих архитектурных принципов и взаимосвязей компонентов — шаг в правильном направлении, но то, что советую проделать я, это шаг ещё дальше. Детали реализации часто определяют поведение системы в не меньшей мере, чем высокоуровневая архитектура. Рутинные низкоуровневые операции на самом деле рано или поздно сложатся в вашем сознании в пазл, на котором яркими линиями проступят высокоуровневые связи компонентов и подсистем. Вы больше никогда не попадёте в ситуацию «а я думал это делается вот в той подсистеме...» или «я выполнял данную операцию здесь, поскольку не знал, что она должна быть выполнена раньше\позже». Вы окажетесь на том уровне «просветления», который позволит вам обсуждать с любым вашим коллегой или руководителем детали взаимодействия подсистем или потенциальные способы реализации будущего функционала.
После того, как вы прочитаете весь код вашей системы, то заметите как изменится ваш взгляд на задачи по разработке новых функций:
- Вы станете быстрее понимать, какие именно части системы будут затронуты новой функциональностью. Вы сможете лучше оценить сложность и время на разработку новой фичи. Общий взгляд на систему даже позволит вам высказывать рекомендации разработчикам отдельных её компонентов по поводу того, как будет лучше их состыковать вместе
- Поскольку вы понимаете работу всей системы, то можете предвидеть проблемы в некоторых ситуациях, на которые не обратили внимание разработчики отдельных подсистем
- Ваш менеджер сможет полагаться на вас в плане оценки сложности проблем и выбирать те из них, решение которых в данный момент может принести наибольший результат при наименьших трудозатратах. В принципе, менеджер мог бы обращаться за подобными оценками к разработчикам конкретных подсистем, но это хорошо работает лишь для очень небольших команд (человек до пяти). Но вам нужно стараться соблюдать баланс: не давайте вашим коллегам почувствовать себя забытыми. Ваши глубокие знания и понимание системы не принесут пользы, если остальные члены команды станут вас сторониться.
- Ваши коллеги, отвечающие за отдельные подсистемы, начнут сами спрашивать совета у вас (и ценить его). Когда вас просят помочь советом, это либо признак того, что вы начинаете заниматься микроменеджментом чужой работы (не очень хорошая вещь), либо того, что вы проходите фазу ситуативного лидерства в данной команде/проекте (ещё не являетесь официальным лидером команды, но уже являетесь одним из лидеров мнений).
Вне контекста разработки новых фич, вы, возможно, заметите также ещё несколько вещей:
- Вас официально назначат техлидом проекта, что откроет перед вами совершенно новые горизонты проблем
- Вам придётся просматривать всё больше и больше пул-реквестов. Их качественная обработка займёт много времени
- Вас будут приглашать на большее количество стратегических совещаний
- Вас будут чаще привлекать к разработке архитектуры
- У вас появится собственное виденье того, куда должна двигаться вся система для достижения долгосрочных целей
- Вам придётся консультировать внешних клиентов
- Ваши контакты с менеджером станут более частыми, на ваши суждения будут полагаться всё чаще и всё сильнее
- Вам будет редко удаваться найти время для написания кода самому
- К вам будут приходить высказывать свои идеи и просить их оценку
- Ваша зарплата вырастет
- В названии вашей должности появится слово “senior”
- Люди начнут видеть в вас своего лидера
- Ваши коллеги будут впечетлены вашей способностью предвидения проблем и «узких мест». Хотя они, в общем-то, тоже находятся на том же расстоянии протянутой руки до такой проницательности (всего-то нужно взять и прочесть весь код своего продукта)
- Каждая новая фича будет рассматриваться вами как ход в шахматной игре (так много позиций, угроз, возможностей).
- Вы осознаете, что весь проделанный труд дал вам лишь одномоментный снимок знаний о состоянии системы на какой-то момент. Ваши представления о коде будут устаревать с каждым пул-реквестом, и вам придётся день за днём сражаться с устареванием ваших знаний. Ну, знаете, «бежать со всех ног просто чтобы остаться на месте».
Так вот, знаете… Лучше уж вы не читайте весь этот код. Жизнь значительно проще без этого :)
Комментарии (16)
KirEv
17.07.2017 13:37Для этого есть документация: «Вот функция системы, она влияет некоторые другие функций которые делают вот это и вот так.»
В длительных проектах сложно держать все в голове, в нашей компании разрабатывалось изначально 3 программных продукта которые зависимы друг от друга, и в каждом из них более сотни фишек многие из которых влияют на поведение остальных, год назад появились дополнительные продукты и привлекаются новые команды, в том числе фрилансеры на небольшие задачи.
Если не документация — прочтение тонны кода превращаются в ад (первый релиз был 7 лет назад)…
правило «разделяй и властвую» — отлично справляется, иначе бы каждый программист то и делал что код читал… пока до конца дойдешь — не помнишь с чего начиналось…
а пробелы новых сотрудников есть смысл заполнять по мере создания ими (сотрудниками новыми) конкретных решений, с этим помогают люди которые создавали зависимые части программы.
быстрее спросить пояснение, чем лазить в дебрях чужого код… а херовый код пишут все. Условие разные и срочность решения задачи бывает не оставляет времени на поиск элегантного решения с хорошо структурированным кодом.
Amper
17.07.2017 15:47+2Занимательная математика:
В проекте, с которым я работаю около 15 000 000 строк кода.
Пусть я буду читать по строке в секунду без остановки (без сна, обеда, отпуска, выходных и перерывов) — на это мне понадобится примерно полгода. Если всё же предположить, что я буду читать по строке в секунду только в рабочее время, то у меня уйдёт более двух лет. Всё это время я не буду работать и буду только читать код, который, кстати, за два года кардинально изменится. Если заложить время не только на чтение, но и на его обдумывание, то, боюсь представить время на такое обдумывание.
Такие дела.vasIvas
17.07.2017 19:11И все написаны вашей командой? Или Вы считаете строки в скомпилированном виде, который включает множество используемых библиотек?
qrck13
17.07.2017 19:36Проект может быть достаточно большим, состоящим из разных компонентов, написанных разными отделами компании, так что даже без учета каких-то внешних библиотек — вполне может получиться дофига. Сам участвую в похожем проекте. Сколько строк кода — я не считал (как-то не дождался, когда отработает рекурсивный wc -l), но счет файлов идет на многие тысячи, и это да — все написанное компанией, где я работаю.
potorof
17.07.2017 20:46Можно читать только тот код, с которым как-то взаимодействуешь. И так по мере его поступления.
Danik-ik
17.07.2017 22:00-1Вредный совет, неправильные выводы. Чтобы знать всю систему, особенно, если это действительно большая система, надо уметь абстрагироваться от мелочей. ООП, с его декомпозицией, перетекающей в инкапсуляцию, позволило строить действительно большие системы именно благодаря разделению контекстов с сокращением их объёма до реально объемлемых пределов.
Быть экспертом по всей ли стстеме, либо по какому-то участку системы — не вредно, но всё имеет цену. Проблема не в "оно вам надо, такое беспокойство?", а в том, настлько ли оно полезно, насколько трудозатратно (читай: дорого).
Danik-ik
17.07.2017 22:12Или так: у тебя есть машина? Разбери её. Всю. Если машины нет, разбери троллейбус. Нет, собирать не обязательно, главное — разобрать, чтобы знать и понимать. И рассуждать об этом на собраниях. И будешь ценным кадром.
То есть нет, вру: оказывается, умение собирать может быть намного полезней, и ценится дороже.
PastorGL
17.07.2017 23:07Бессмысленно просто читать код, это же не книга, где есть начало и конец. Тем более, объём может быть в миллионы строк, и ещё он имеет естественное свойство постоянно меняться.
На самом деле, чтобы начать врубаться, достаточно читать диффы всех новых вмерженных в мастер веток — а не только того, что полагается в рамках назначенного лично тебе code review. В таком случае, будет достаточно нескольких месяцев, чтобы обрести новый, более глубокий уровень понимания (хотя экспертом по всему продукту стать не получится, для этого нужно писать код во всех его частях, а не только читать). Выделить на это достаточно полчаса в день — после обеда, или по приходу на работу, или ещё какое у кого малопродуктивное время. Заодно и в рабочее состояние проще становится войти.PavelZhigulin
18.07.2017 14:25Я боюсь, даже это может оказаться непосильной задачей. Я работаю в компании, в которой штат программистов 300+ человек и читать диффы даже только тех подсистем с которыми я взаимодействую — это очень трудозатратно. Я стараюсь, конечно, быть в теме происходящего, но уследить почти невозможно.
Bobolik
18.07.2017 14:25Читать код еще не значит овладеть продуктом и понять все детали работы.
Я много раз «читал» код, например при переходе на новый проект или при смене работы. Чтение требовала от несколько дней до месяца. Но это всего лишь ознакомление и ни как не овладение. Более того, этот процесс демотивирует и неинтересен и скорее всего знания кода будет временным.
Из моей практики, лучше просто узнать что и где находится, создать наброски и диаграммы. А углубляться уже при работе на конкретную часть кода. У меня я команде всегда кто то хорошо знал часть кода, и все зависели друг от друга. Все, всегда участвовали во всех стратегических совещаний. Тех лид никогда не знал код полностью а только, кто за что отвечает и что где находится, где какие проблемы возникали и их решение. Сам он всегда имел кучу документов со описанием кода, проблем и узких мест, списка желании и так далее. Но и даже после этого знать вес код не было реально а проект имел средние размеры.
Ни кто не хочет тратить собственное время на код и проект, так ка другого свободного времени нет, на работе работаем а после каждый по своим делам. Лучше поменять работу и таким образом получить прибавку к зарплате чем заниматься сомнительно выгодным делом за счет собственного времени. К тому же если даже тратить столько времени на один проект ради становления каким то лидом и/или прибавки зарплаты то тогда как профессионал не будет прогресса разве что в конкретной среде. Знаю многих кто по этой схеме двигались и после многих лет уже работу менять не могут и зарплата уже не поднимается. Но зато все обращаются к ним, потому что проект знают от А до Я. Наверно после такого авторитета поменять работу уже не хочется, ну и что нет радости в работе и жизнь не имеет смысла…
Sklott
18.07.2017 14:25Все это конечно замечательно, но только в применении к маленьким проектам. Для более-менее приличных проектов должно быть грамотное разделение проекта на функциональные блоки, и тогда этот совет скорее стоит перефразировать как «прочитайте весь код модуля в котором ты работаешь».
А то ведь некоторые работают над такими продуктами, что чтение всего коде без осмысления может занять несколько лет, а уж с осмыслением…
vasIvas
Я пишу один, но проекты бывают такими большими, что я ещё не закончив не могу без диаграмм вспомнить архитектуру. А Вы предлагаете забивать себе мозг тем, что пишет вообще кто-то другой. Обычные проекты, это штук 20 папок в каждой из которых куча файлов в которых реализуются части алгоритмов. Какой прок от чтения разрозненных частей алгоритмов?