Работа над чужим кодом [закрыто]

У меня едва ли годовой опыт в программировании. После того, как я начал работать, большую часть времени я работал над чужим кодом, либо добавляя новые функции поверх существующих, либо модифицируя существующие. Парень, который написал настоящий код, больше не работает в моей компании. Мне трудно понять его код и выполнять свои задачи. Всякий раз, когда я пытался изменить код, я каким-то образом путался с работающими функциями. Что все я должен иметь в виду, работая над чужим кодом?

Есть ли в коде юнит-тесты? Если нет, я настоятельно рекомендую вам начать добавлять их. Таким образом, вы можете написать новые функции / исправления ошибок как неудачные тесты, а затем изменить код, который проходит тест. Чем больше из них вы создадите, тем больше у вас будет уверенности в том, что добавленный вами код не сломал что-то еще.

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

Eagle76dk делает большой акцент на привлечении вашего менеджера для выполнения этой работы - более подробно в посте Eagle76dk.

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

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

На мой взгляд, самый быстрый способ изучения чужого кода (особенно когда изменения вызывают неожиданное поведение, как вы описываете) - это пройтись по коду с помощью отладчика .

Начните с пошагового прохождения того, что кажется основным циклом / основными методами программы. Используйте функции step into и step, чтобы увидеть, что делают разные методы. Это научит вас общей структуре кода.

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

Установите точки останова на методы, которые вызывают поведение, которое вас касается. Например, если вы пытаетесь изменить текст в программе, и текст продолжает возвращаться к исходному значению, установите точки останова во всех местах, где текст был изменен, или попытайтесь переместить все эти изменения в один единственный метод. Используйте стек вызовов, чтобы увидеть, откуда вызывается этот метод и т. Д.

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

Делая это много, вы начнете изучать структуру кода на удивление быстро. Я начинал, как и вы, на моих первых работах по программированию, с большим количеством кода, который был написан много лет назад и изменялся многими людьми в течение многих лет. Код был не мой, потому что там, где другие люди работали над ним одновременно. Я не мог переписать все это в тот момент. Написание тестов для всего этого кода заняло бы у меня месяцы или годы. Отладчик действительно спас меня, не знаю, как бы я узнал код без него ...

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

Постарайтесь максимально приспособить существующий стиль - иначе парень после вас будет в два раза больше приспосабливаться.

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

Не спешите предполагать, что код другого парня воняет.

Но всегда будь подозрительным.

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

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

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

Тем не менее, первое, что вы узнаете, мы не живем в идеальном мире!

Многие разработчики не документируют свой код должным образом, если они вообще смешивают бизнес-логику с несвязанным кодом, и единственный тест, который они проводят, - это быстрый прогон того, что они ожидают от нормального варианта использования.

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

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

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

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

О, и теперь, когда вы увидели боль, которую может причинить плохо документированный, непроверенный и беспорядочный код, вы не будете делать это со следующим бедным разработчиком, верно? :) Учитесь на ошибках вашего предшественника, хорошо комментируйте свой код, убедитесь, что у каждого модуля есть четко определенная ответственность, которой он придерживается, и убедитесь, что у вас есть полный набор модульных тестов, которые вы либо пишете первыми (для методологий TDD), либо по крайней мере, наряду с разрабатываемым кодом.

Имейте в виду, что умение читать код, который вы не написали, является очень ценным навыком, вероятно, более ценным, чем написание кода. К сожалению, это широко недооценивают и недостаточно учат в школах.

Я пытаюсь сказать, что это нормально, что вы не всегда понимаете код при первом чтении (как обычно, когда вы не пишете идеальный код в первый раз). Если вы согласны с тем, что для получения иностранного кода требуется время, вы не будете возражать, если приложите дополнительные усилия. Небольшое резюме:

• Модульные тесты были бы идеальными, но не всегда реалистичными; особенно если вы работаете в крупной организации с тяжелой бюрократией.

• Научитесь правильно пользоваться системой контроля версий; Вы никогда не сломаете существующее (не совсем никогда , но это хорошая сеть безопасности).

• Не думайте, что это плохо просто потому, что вы не понимаете это мгновенно. Не думайте, что это хорошо просто потому, что это работает. Важно, чтобы вы понимали стиль кода предыдущего сопровождающего и адаптировали добавленные строки к его стилю. Ответственный за вас, сопровождающий, поблагодарит вас за это.

• К сожалению, в некоторых компаниях сложность чтения кода может быть недооценена. Это распространено в крупных корпорациях с жесткими процессами. Они часто (неявно) предпочитают использовать push-код, который работает быстро, а не тратить время на написание чего-то чистого. Я оставлю на ваше усмотрение решение, где ваша команда стоит в этом вопросе.

• Наконец, никогда не забывайте, что чтение кода - это навык . Чем больше вы это сделаете, тем лучше вы добьетесь этого. Еще один способ сказать, что единственный способ добиться этого - практиковать это много раз. Как упоминалось выше, чтение кода является и будет гораздо большей частью вашей работы, чем написание.

Судя по вашим проблемам с непреднамеренным взломом, я предполагаю, что код не покрыт автоматическими тестами. Шаг № 0 состоит в том, чтобы немедленно заказать и прочитать « Эффективная работа с устаревшим кодом » Майкла Фезерса. Это просто бесценно.

Основные шаги, которые я бы предложил:

• Покройте код тестами, охватывающими текущую функциональность.
• Рефакторинг пока не понятно.
• Написать тест на новую или измененную функциональность.
• Реализуйте новый функционал.
• Рефакторинг до удовлетворения.

Я намеренно пропускаю указание вида тестов (модуль, интеграция, ...) - просто получаю какое-то автоматическое покрытие тестами.

(и, да, придерживайтесь стиля кодирования с точки зрения разметки и именования)

Как уже упоминалось ранее: добро пожаловать в реальный мир. Я могу только согласиться с более ранними ответами. Я только хотел бы расширить ответ с моим опытом работы об оценках времени.

Хорошее предложение, чтобы прояснить ваш босс, потребуется время, чтобы узнать, как думают другие разработчики. Обычно вы сталкиваетесь с тем, что текущее решение часто зависит от возраста и опыта разработчика.

Если вам повезет, нужно проанализировать задачу, и понимание документации поможет вам (но часто это не так).

Мой опыт показывает, что при изменении чужого кода старайтесь не изменять код, который не связан с вашей текущей задачей. Возможно, вы знаете лучшее решение или оно может быть написано более интуитивно, но его изменение часто приводит к таким проблемам, как:

• Задача займет больше времени, и ваш начальник не поймет этого.
• Код, который вы меняете, должен быть протестирован, и он стоит. Текущее решение было проверено и одобрено.
• Будет трудно увидеть, какие изменения решают текущую задачу, а какие являются «просто» исправлениями.

Но не стесняйтесь сказать своему боссу, если вы видите что-то, что, по вашему мнению, должно быть другим (это просто показывает, что вы можете думать).

Наконец, убедитесь, что у вас есть достаточно времени, чтобы принять решение. Более быстрое решение приходит с опытом. Но редко бывает быстрое решение, так как это первая / главная причина ошибок и неисправимого кода.

Думайте об этом как о выполнении операции на человеке.

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

Удивительно, но ваш пациент умирает почти сразу.

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

Я бы попросил старшего инженера сидеть с тобой около часа каждый понедельник и объяснять другой аспект системы. Сделайте заметки о том, что он говорит, и отправьте по электронной почте заметки ему и вашему менеджеру, чтобы узнать, есть ли у вашего менеджера что-нибудь добавить. Таким образом, вы должны быстро набрать скорость.

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

Одна вещь, которую я действительно не видел, затронута здесь - не работать на острове.

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

Задавать вопросы. Много их.

Не беспокойтесь о том, чтобы «раздражать» кого-то другого (в пределах разумного) - я бы предпочел, чтобы кто-то перебил меня вопросом или двумя во время обычного цикла разработки, чем необходимость тушить пожар в производственной среде позже.

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

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

И пять лет спустя поощряйте следующего Нового парня использовать вас в качестве наставника.

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

• Я просто недостаточно умен, чтобы понять, как работает этот код

• Парень, который написал этот код, понятия не имел, что он делал

• Волшебство вовлечено: очень черная магия

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

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

Если код работает в основном - звучит так, как он работает - тогда я бы сохранил стиль форматирования кода для этого модуля, будь то ваш стиль или нет. Это держит вещи единообразно. Тем не менее, хорошие комментарии никогда не выходят из моды.

Я советую тестовую систему и тестовую платформу, где вы можете модифицировать и тестировать этот код, не нарушая производство.

Если вы можете удалить элементы кода в библиотеку, я бы сделал это, если вы не работаете над библиотекой.

Со временем, когда вы поймете логику, вы сможете переписать и протестировать.

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

Попробуйте использовать некоторые инструменты для анализа кода, чтобы найти неиспользуемый код, который можно удалить - так что, по крайней мере, вам не нужно беспокоиться об этом коде.

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

Короче говоря, вы должны понимать не только «нормальный поток», но и все отступления, которые необходимы, если кто-то совершит ошибку или передумает. Это становится еще хуже с переопределениями супервизора, где некоторый код может быть запущен только с определенными привилегиями учетной записи.

Если кто-то пишет 10 000 строк кода в год, а приложение имеет 10-летнюю «жизнь», то программисту, отвечающему за выбор чужой работы, возможно, придется понимать 100 000 строк кода. Разделите это на 50 строк на странице, это 2000 страниц. Если программа написана по шаблону проектирования, программист обнаружит, что понимание одного «блока» приводит, по крайней мере, к общему пониманию большинства остальных. Если нет, то необходимо прочитать каждую чертову строку.

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

Здесь есть несколько действительно хороших ответов. Но я думаю, что также стоит упомянуть, насколько полезно знакомство с хорошими шаблонами проектирования , для чтения (хорошо написанного) существующего кода и для написания читаемого кода.

Конечно, это может быть очень запутанным, когда вы сталкиваетесь с SomethingFactoryсуществующим кодом, который на самом деле не следует фабричному шаблону . Но насколько позволяет ваша команда и структура, может быть полезно свести такие случаи к минимуму.

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

Некоторые хорошие источники по шаблонам дизайна

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

и конечно же книга

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

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

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

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

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

И визуализация рабочего процесса идеальна:

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

Рекомендации

• Понимание устаревших рабочих процессов с помощью анализа времени выполнения (pdf)
• Объектно-ориентированное устаревшее системное логическое тестирование на основе трассировки (pdf)
• console.trace () - веб-API | MDN
• Отслеживание вызовов методов через прокси
• Как шпионить за вашими методами Ruby
• Легкая трассировка вызовов вложенных функций в Python - сайт Эли Бендерского
• Метод входа / выхода из журнала - Mebyon Kernow
• Trace: инструментарий для отображения вызовов функций
• -Xtrace -
• GitHub - johnno1962 / SwiftTrace: вызовы трассировки Swift и Objective-C
• Debug :: Trace - расширение Perl для отслеживания вызовов подпрограмм - metacpan.org

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