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