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

У мене навряд чи рік досвіду в кодуванні. Після того, як я почав працювати, більшу частину часу я працював над чужим кодом, або додаючи нові функції над існуючими, або змінюючи існуючі функції. Хлопець, який написав фактичний код, більше не працює в моїй компанії. Мені важко зрозуміти його код і виконувати свої завдання. Кожного разу, коли я намагався змінити код, я певним чином змішувався з робочими функціями. Що я повинен пам’ятати, працюючи над чужим кодом?

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

Написання одиничних тестів для коду, який ви не повністю розумієте, допоможе вам зрозуміти зазначений код. Звичайно, слід додавати функціональні тести, якщо вони ще не існують. Моє враження було, що ці питання вже існували з питання про ОП. Якщо я помиляюся з цього приводу, то ці функціональні тести повинні стати вашим першим кроком.

Eagle76dk має велике значення щодо того, щоб отримати свого менеджера на борту для виконання цієї роботи - детальніше у публікації Eagle76dk.

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

На додаток до іншої відповіді, в якій згадувались одиничні тести, я б запропонував вам переконатися, що все в контролі версій, щоб ви могли легко відновити зміни. І внесення невеликих змін, щоб зробити код більш ретельним.

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

Почніть з перегляду того, що, здається, є основним циклом / основними методами програми. Використовуйте крок в і вийти функції , щоб побачити , що робить різні методи. Це навчить вас загальній структурі коду.

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

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

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

Зробивши це багато, ви почнете вивчати структуру коду на диво швидко. Я почав так само, як ви робили на моїх перших роботах з програмування, з великою кількістю коду, який був написаний багато років тому і змінений багатьма людьми протягом багатьох років. Код був не моїм лише там, де одночасно працюють над ним інші люди. Я не міг все це переписати. Написання тестів на весь цей код зайняло б у мене місяці чи роки. Відладчик дійсно врятував мене, не знаю, як би я дізнався код без нього ...

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

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

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

Не варто занадто швидко припускати, що код іншого хлопця смердить.

Але завжди будьте підозрілі.

Але так, для розуміння коду іншого розробника потрібен час. Чим більше функція або об'єкт використовується декількома частинами системи, тим обережніше потрібно бути уважним. Якщо ви зможете вирішити проблему ближче до симптому, це іноді може бути корисним. Наприклад, нормалізуйте вхідні дані з іншого об’єкта на стороні проблемного об’єкта після забору даних, але раніше, ніж щось інше станеться.

Це поганий знак, коли зміна однієї речі несподівано зламає іншу. Якщо у вас є інші досвідченіші розробники, на яких ви можете покластися на допомогу, я рекомендую їм поглянути на матеріали, які викликають у вас проблеми. Як мінімум, ви можете вибрати кілька речей, спостерігаючи за їх налагодженням.

В ідеальному світі весь код, написаний даним розробником, буде добре задокументований, добре структурований і зрозуміло випробуваний, як з автоматичними інструментами, такими як тести одиниць, так і з використанням сценаріїв справи, через які користувач проходить, щоб перевірити, чи отримаєте ви очікуваний результат.

Однак перше, що ти дізнаєшся, це те, що ми не живемо в ідеальному світі!

Дуже багато розробників не документують свій код належним чином, якщо вони взагалі змішують бізнес-логіку з незв’язаним кодом, і єдиний тест, який вони роблять, - це швидкий аналіз того, що, на їхню думку, є звичайним випадком використання.

Працюючи з таким кодом, перше, що вам потрібно зробити, це встановити, що він має на увазі робити. Якщо є коментарі, вони можуть дати вам підказки, але на це не розраховуйте. З мого досвіду, що багато кодерів не дуже добре пояснюють себе, і навіть якщо вони залишають коментарі, вони можуть бути безглуздими. Однак, якщо ви не єдиний кодер в компанії, хтось, безумовно, повинен мати принаймні базове уявлення про те, для чого призначений код і що він має робити. Спитайте!

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

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

Майте на увазі, що навіть добре написаний і добре задокументований код може бути важким для розуміння стороннім. Код - це, по суті, вираження того, як людина, яка його написала, в той час думала, і кожен має свій унікальний процес мислення. Вам доведеться навчитися бути трохи терплячим і бути детективом. Бути в змозі потрапити в процес мислення іншої людини важко, але програміст, який займається підтримкою існуючого коду, є важливим вмінням. Оскільки більша частина кодування (близько 70%) пов'язана із підтримкою існуючого коду, важливо навчитися.

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

Майте на увазі, що вміння читати не написаний вами код - це дуже цінний навик, мабуть, більш цінний, ніж написання коду. На жаль, це в школах недостатньо занижене та недооцінене.

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

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

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

• Не вважайте, що це погано просто тому, що ви його не розумієте миттєво. Не вважайте, що це добре просто тому, що він працює. Важливим є те, що ви розумієте стиль коду попереднього виконавця та адаптуєте додані рядки до його стилю. Супроводжувач, що прийде після вас, буде вам за це вдячний.

• У деяких компаніях, на жаль, труднощі зчитування коду можна недооцінити. Це часто зустрічається у великих корпораціях з жорсткими процесами. Вони часто (неявно) воліють, щоб ви натискали код, який працює швидко, а не витрачали час, щоб написати щось чисте. Я залишаю за вами вирішити, де ваша команда стоїть з цього приводу.

• Нарешті, ніколи не забувайте, що читання коду - це навичка . Чим більше ви це зробите, тим краще ви отримаєте на це. Ще один спосіб сказати це, що єдиний спосіб отримати хороший результат - це практикувати це багато разів. Як згадувалося вище, читання коду є і буде значно більшою частиною вашої роботи, ніж написання.

Судячи з ваших проблем з ненавмисним розбиттям матеріалів, я припускаю, що код не покривається автоматизованими тестами. Крок № 0 - це негайно замовити та прочитати « Ефективна робота зі застарілим кодексом » Майкла Пір’я. Він просто неоціненний.

Основні кроки, які я б запропонував:

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

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

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

Як згадувалося раніше: ласкаво просимо в реальний світ. Я можу погодитися лише з попередніми відповідями. Я хочу лише поширити відповідь своїм досвідом роботи щодо оцінки часу.

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

Якщо вам пощастить, завдання, яке підходить вам, потрібно проаналізувати, і розуміння документації допоможе вам дуже багато (але це часто не так).

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

• Завдання займе більше часу, і ваш начальник цього не зрозуміє.
• Змінений код повинен бути протестований, і він коштує. Поточне рішення перевірено та затверджено.
• Буде важко зрозуміти, які зміни вирішують поточну задачу, а які - "лише" виправлення.

Але не соромтеся сказати своєму начальнику, якщо ви бачите щось, на вашу думку, має бути інше (це просто показує, що ви можете думати).

Нарешті, переконайтеся, що у вас є достатньо часу для прийняття рішення. Більш швидке рішення має досвід. Але рідко є швидке рішення, оскільки це перша / основна причина помилок і неможливого коду.

Подумайте про це, як провести операцію над людиною.

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

Дивно, але ваш пацієнт помирає майже відразу.

Спадкові програми однакові. У них вже є спосіб роботи - вам потрібно зрозуміти різні компоненти програмного забезпечення та те, як вони співвідносяться один з одним, а потім внести зміни, щоб воно працювало так само. Це не захоплююче, як відпускати свою творчість дико, але ви можете робити це на особистих проектах.

Я б попросив старшого інженера сісти з вами на годину або близько того щопонеділка і пояснити інший аспект системи. Запишіть те, що він говорить, та надішліть йому повідомлення та менеджеру по електронній пошті, щоб побачити, чи має ваш менеджер що-небудь додати. Таким чином, ви повинні швидко набрати швидкість.

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

Одне, чого я насправді не бачив, тут торкалися - не працюй на острові.

Якщо ви не єдиний програміст у вашому вбранні, неодмінно може бути хтось, хто має більше досвіду, ніж ви, і, можливо, багато людей, на яких ви можете спертися.

Задавати питання. Багато їх.

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

Коли ви готові щось перевірити, перегляньте це зі своїм наставником. Вони повинні бути в змозі сказати вам не тільки, якщо щось щось порушить, але ще важливіше, чому. Перегляд коду також зробить наставника кращим програмістом, даючи йому / їй уявлення про систему, яку вони інакше не можуть розглядати так часто.

Пам'ятайте - ви не тільки вивчаєте систему, як це повинен був би зробити кожен новий працівник, але ви також вчитеся, як стати програмістом.

І п’ять років закликайте наступного нового хлопця використовувати вас як наставника.

Що стосується коду налагодження, пам’ятайте: завжди є причина . Коли ви кілька днів намагаєтеся знайти та виправити ту саму дурну помилку, і ви не досягли жодного прогресу, спокусливо почати думати про одне чи декілька:

• Я просто недостатньо розумний, щоб зрозуміти, як працює цей код

• Хлопець, який написав цей код, поняття не мав, що він робить

• Магія бере участь: дуже чорна магія

Це все форми відмови. Протиотрута полягає в тому, щоб завжди пам’ятати, що комп’ютери детерміновані: завжди є причина того, що вони роблять. Код може пахнути відливом на рибному консерві і нагадувати гігантську миску з лінгвіном, але , будучи невимушено раціональним і зберігаючи відкриту думку, ви зрозумієте це .

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

Якщо код працює здебільшого - це звучить так, як це відбувається - я б зберегла стиль форматування коду для цього модуля, будь то ваш стиль чи ні. Це тримає речі рівномірними. Однак хороші коментарі ніколи не виходять із стилю.

Я раджу тестову систему та тестову платформу, де ви можете змінювати та тестувати цей код, не порушуючи виробництво.

Якщо ви можете видалити елементи коду в бібліотеку, я б це зробив, якщо ви не працюєте над бібліотекою.

З часом, як тільки ви зрозумієте логіку, ви можете переписати і протестувати.

Ця порада враховується мовою, якою ви користуєтеся, можливістю отримати тестовий шар та іншими вашими обмеженнями.

Спробуйте скористатися деякими інструментами для аналізу коду, щоб знайти невикористаний код, який можна видалити - так що принаймні вам не доведеться турбуватися про цей код.

Вище було зауважено, що вам потрібно зрозуміти призначення системи, а не лише деталі коду. Програміст, який має достатньо досвіду для написання системи внесення замовлень, як правило, комфортний із частиною "просування вперед", яка передбачає вибір продуктів, форматування рахунку та обробку платежу. Там, де вони застрягають, це коли користувач вирішує "не заважати" і починає здійснювати резервне копіювання транзакцій, або коли робить помилку в обробці платежів і натискає кнопку "назад". У цей момент багато програмістів розбиваються, тому що вони бачать код "з'являється з нізвідки" і не можуть зрозуміти, чому він є.

Коротше кажучи, ви повинні розуміти не просто "нормальний потік", але і весь зворотний трек, який необхідний, якщо хтось помилився або змінив свою думку. Це ще більше погіршується при скасуваннях супервізора, де деякий код може працювати лише з певними привілеями облікового запису.

Якщо хтось пише 10 000 рядків коду на рік, а у програми тривалість життя на десять років, тоді програмісту, відповідальному за підбір чужої роботи, можливо, доведеться розуміти 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
• Трасування: приладобудування для показу функціональних викликів
• -Xtrace -
• GitHub - johnno1962 / SwiftTrace: виклики методу Trace Swift та Objective-C
• Налагодження :: Trace - розширення Perl для відстеження викликів підпрограми - metacpan.org

Переконайтеся, що ви використовуєте програму, яка допоможе вам знайти речі в поточному файлі. Нічого гіршого, ніж знати те, що ви шукаєте, є у поточному файлі, але ви прокручуєте та прокручуєте, і не можете його знайти. Вигляд контуру в інструменті, який ви використовуєте для редагування коду, справді допомагає в цій проблемі.