M>Вот взяли вас на работу (php, legacy). Как вы разбираетесь в чужом коде? Есть какая-то методика?
зависит от конторы. если сажают за легаси, дают сложную задачу и говорят сделать ее вчера — скорее всего никак.
если все же есть какое-то постепенное погружение + нолидж трансфер — все придет само собой.
M>Вот взяли вас на работу (php, legacy). Как вы разбираетесь в чужом коде? Есть какая-то методика?
Беру первую задачу (несложную), делаю ее, попутно понимая какой-то участок кода. Потом беру вторую задачу, узнавая новый участок кода. И так далее.
Хорошая практика из опен-сорс проектов, которую можно применять и для проприетарного кода — иметь список задач с лейблом "Good First Issue", которые как раз простые и подходящие для знакомства с кодом. Ну и до которых могут никогда не дойти руки у более опытных членов команды, например.
Хороший вопрос. Сам очень мучился, ничего не мог понять. Методики нет, есть идея общего подхода и отношения к делу, описанная в посте 2009 года: https://gaperton.livejournal.com/32772.html
Но прочитать этот пост мало, надо основательно вдуматься и прийти к выводу, что дело не в коде, а в общих предпосылках мотивации и мотивации работать в данной организации, в причинах, почему информационная система в ней так работает.
Здравствуйте, Marzec19, Вы писали:
M>Сам очень мучился, ничего не мог понять.
Ага, тоже всегда ненавидел ковырять чужой код, вплоть до того, что предпочитал с нуля написать, чем разбираться.
M>дело не в коде, а в общих предпосылках мотивации и мотивации работать в данной организации, в причинах, почему информационная система в ней так работает.
Ну и еще наверное в каком-то отторжении, нежелании сильно в него погружаться, повышать его значимость для себя.
G>Ага, тоже всегда ненавидел ковырять чужой код, вплоть до того, что предпочитал с нуля написать, чем разбираться.
а зря, кстати, помню писал одну хрень на с++. там было достаточно много матана, в котором я особо не рублю. была прога на фортране, где многие алгоритмы реализованы. вник, позаимствовал. сильно облегчил себе жизнь.
Здравствуйте, magnum2005, Вы писали:
M>Вот взяли вас на работу (php, legacy). Как вы разбираетесь в чужом коде? Есть какая-то методика?
Садишься и пишешь нужный функционал по таску, посматривая в коде на примеры приёмов работы.
Здравствуйте, magnum2005, Вы писали: M>Вот взяли вас на работу (php, legacy). Как вы разбираетесь в чужом коде? Есть какая-то методика?
для начала надо начальству с умным видом обьяснить, что php это набор утилит для создания домашних веб страничец, а не язык после этого поцокать гляда на говнокод, называя всех контрибьютеров говнокодерами, потом найти того, что уже работает в проекте и расспросить его что они курили, потом свалить всю работу на него и спокойно уйти в другой проект
__>для начала надо начальству с умным видом обьяснить, что php это набор утилит для создания домашних веб страничец, а не язык после этого поцокать гляда на говнокод, называя всех контрибьютеров говнокодерами, потом найти того, что уже работает в проекте и расспросить его что они курили, потом свалить всю работу на него и спокойно уйти в другой проект
примерно такое же отношение к данному языку. но извращенцы ваяют на нем достаточно крупные системы. как правило не масштабируемые или масштабируемые с помощью такой-то матери и клочками вырванных волос.
S>Садишься и пишешь нужный функционал по таску, посматривая в коде на примеры приёмов работы.
а если продукт огромен с кучей спагетти-кода? когда закорюку в одном месте поправишь — выстрелит в 10 местах, о существовании которых ты даже не подозревал. простейший пример — сторонняя система, о которой ты не знал забирает данные из этой и выполняет какие-то с ними действиями. по коду ты такую хрень не отследишь. нужно просто это знать и иметь в виду.
S>>Садишься и пишешь нужный функционал по таску, посматривая в коде на примеры приёмов работы. N>а если продукт огромен с кучей спагетти-кода? ...
Было и такое. Совет тот-же, но при планировании количество предполагаемых часов как минимум дополнительно ещё на 2π умножай.
Здравствуйте, mike_rs, Вы писали:
N>>когда закорюку в одном месте поправишь — выстрелит в 10 местах, о существовании которых ты даже не подозревал. _>code-review же есть
Далеко не всегда. Особенно если легаси, которое не трогали некоторое время.
Здравствуйте, nikkit, Вы писали:
N>а если продукт огромен с кучей спагетти-кода? когда закорюку в одном месте поправишь — выстрелит в 10 местах, о существовании которых ты даже не подозревал.
Бывало и не раз. А бывало и хуже. Например, хитро вывернутое наследование. Есть примерно 6-8 слоев, причем между предками и потомками, судя по выполняемым ими действиям, нет ничего общего. Просто в предке есть некий метод, который хочется позвать.
В реальности все немного сложнее. Этот вызванный метод тоже в объйете что-то вызывает. И нужно строго следить, какого типа переменную объявить. Потому что метод объекта соответственно может вызвать что-то либо из предка, лиюо из потомка. По сравнению с этим макаронный код — просто детский сад.
Здравствуйте, nikkit, Вы писали:
N>а зря, кстати, помню писал одну хрень на с++. там было достаточно много матана, в котором я особо не рублю. была прога на фортране, где многие алгоритмы реализованы. вник, позаимствовал. сильно облегчил себе жизнь.
Мне проще было фортрановские функции и подпрограммы к Сям подключить. Тем более, что фортрановский код уже был проверен временем.
Здравствуйте, magnum2005, Вы писали:
M>Вот взяли вас на работу (php, legacy). Как вы разбираетесь в чужом коде? Есть какая-то методика?
Ну как, сижу, да разбираюсь. Если совсем непонятно, спрашиваю
В идеале есть какие-то вводные документы, типа зачем это всё нужно и как устроено.
Их можно посмотреть, даже если они устарели на годы.
Еще можно тикеты смотреть, если все нормально связано, конечно.
Типа из строчки кода перейти на тикет который объясняет зачем она была написана и что еще с ней связано.
Дает хороший контекст.
