Перевод статьи «5 Effective tips for maintaining code written by someone else».
Из вашей команды кто-то уходит? Вам передают legacy-код? Вы сами переходите в другую команду? Это лишь некоторые из причин, по которым разработчики могут столкнуться с задачей поддержки чужого кода.
Работа с кодом, который не вы писали и с которым вы не знакомы, может быть связана с некоторыми проблемами. Вам могут передать код для незнакомой вам технологии, причем код, требующий доработки. Или может возникнуть необходимость срочно исправить баг, обнаруженный в старой кодовой базе.
Чтобы лучше справляться с подобными задачами, важно знать о потенциальных проблемах и иметь какую-то наработанную систему их решения.
Если вы занимаетесь разработкой на профессиональном уровне, скорее всего, вы уже попадали в ситуации, когда приходилось работать с чужим кодом. Но если нет — поверьте мне, это лишь вопрос времени!
Я читал чужой код и вот что узнал
В этой статье мы рассмотрим несколько советов, способных облегчить работу с унаследованным кодом.
1. Проведите сеанс передачи кода с автором
Если у вас еще есть контакт с человеком, который написал этот код, проведите с ним сеанс передачи. Или два! А может и три.
Используйте эти сеансы как способ ускорить процесс ознакомления с кодовой базой. Без этого вам придется разбираться во всем самостоятельно, а это займет больше времени. Разработчик, создавший этот код, может рассказать вам о его логике, а также указать на любые скрытые «секреты» или «хаки».
Перед сеансом передачи непременно сами просмотрите код и запишите возникающие у вас вопросы. Таким образом во время совместного просмотра кода с его автором вы будете знать, на что обращать внимание и что спрашивать. И конечно же, во время совместных сеансов ведите записи.
Передача вам кода самим автором — вероятно, самый быстрый способ познакомиться с новой для вас кодовой базой.
Поэтому, если у вас еще есть возможность обратиться к этому разработчику, непременно ею воспользуйтесь. Если ваш коллега собирается покинуть компанию, сеансы передачи кода должны быть у вас в приоритете, ведь вам нужно успеть их провести до его ухода.
Бывают и другие ситуации, когда полезно пройтись по кодовой базе вместе с кем-то, кто ее хорошо знает. Например, если вы сменили команду, нужно, чтобы кто-то из новых коллег рассказал вам о структуре кода. Это позволит ускорить ваше знакомство с новой для вас кодовой базой.
2. Прочтите всю доступную документацию
Документация — это все доступные документы, относящиеся к проекту, для которого был написан код.
Спецификации проекта? Спецификации программы? Файлы README? Прочтите все это.
Время, потраченное на чтение этих документов, вы сэкономите в будущем.
КАК ЧИТАТЬ ИСХОДНЫЕ КОДЫ | СОВЕТЫ ОТ СОЕРА
Вы можете часами биться в попытках выяснить, почему код был реализован определенным образом, но ответ можно найти, просто прочитав README. Можно попытаться самостоятельно понять назначение разделов кода, но они могут быть хорошо описаны в спецификациях приложения.
Читать документацию важно, даже если вы провели сеанс передачи с разработчиком, написавшим код. Все эти документы существуют не без причины. А сеансы передачи вряд ли охватят все существенные моменты.
Чтение документации особенно важно для устаревшего программного обеспечения. Речь идет о случаях, когда у вас нет ни малейшего шанса поработать с авторами кода. Поскольку сеанс передачи невозможен, все, что у вас есть, — это исходный код и любая доступная документация.
Последний совет по этому поводу: помните, что файлы README не зря называются README («прочти меня» — прим. перев.)!
3. Запустите программу и попользуйтесь ею
Этот совет надо понимать буквально. Запустите код и попробуйте использовать приложение так, как задумано. Таким образом вы сможете лучше понять, что оно делает.
Это может показаться очевидным, но практика показывает, что многие игнорируют этот этап.
Если разработчик составляет представление о программе, лишь читая код и строя догадки, это может привести к проблемам. Поэтому обязательно запустите приложение и попробуйте использовать его как конечный пользователь. Это даст вам общее понимание того, что на самом деле делает приложение, а также представление о его функциях и ограничениях. В результате вам будет проще разобраться в коде.
Это относится и к приложениям, написанным для определенного оборудования или платформ. Получите доступ ко всему необходимому и запустите приложение на соответствующих платформах.
Если вы пытаетесь исправить баг, запуск кода — логичный первый шаг в процессе отладки. Это тоже вроде бы очевидно, но лучше еще раз об этом сказать.
4. Тестируйте, тестируйте, тестируйте!
Если вы имеете дело с незнакомой кодовой базой, прежде чем вносить какие-либо изменения, убедитесь, что есть тесты для проверки работоспособности программы. Тесты помогут подтвердить, что после внесения изменений ничто не сломалось.
Безопасное внесение изменений — еще более сложная задача, чем просто знакомство с чужим кодом!
И если исходить из того, что вам передали код именно для внесения правок и улучшений, то наличие тестов имеет решающее значение.
Если тестов нет, попробуйте написать их самостоятельно. Это могут быть юнит-тесты, дымовые, ручные или автоматизированные. Любое тестирование обычно лучше, чем его отсутствие.
5. Примите вызов
Когда вам приходится взяться на поддержку незнакомого кода, попробуйте воспринять это как личный вызов. Справляясь со всеми сопутствующими трудностями, вы существенно улучшите свои навыки.
Во-первых, вы разовьете навыки чтения и интерпретации чужого кода. Это позволит вам лучше улавливать намерения разработчиков при чтении кода. Благодаря практике вы сможете легче справляться с задачами поддержки программ.
Во-вторых, поддерживая чужой код, вы сможете перенять полезные методы и приемы, которые улучшат ваш собственный. Чтение кода других разработчиков можно считать методом непрямого обучения. Только будьте осторожны и избирательны в отношении перенимаемых методов.
Осознание того, что в конечном итоге вы получите выгоду от этого опыта, должно вас мотивировать. Так что не бойтесь и принимайте брошенный вам вызов!
Вывод
Поддержание кода, написанного кем-то другим, безусловно, связано со многими проблемами. Но это всего лишь еще одна сторона работы разработчика, с которой нам всем когда-нибудь придется столкнуться.
И вы сможете куда лучше подготовиться к работе с чужим кодом, если не только будете следовать советам из этой статьи, но и разработаете собственные систематические методы для работы с незнакомой кодовой базой.
Источник: techrocks.ru
Использование чужого кода в своих программах
Комментарии
Популярные По порядку
Не удалось загрузить комментарии.
ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ
20 рабочих советов от Junior Front-end developer
В начале изучения важна каждая крупица знаний. Для статьи мы отобрали список полезных советов для совсем зеленого front-end developer-а.
Карьерный рост: в чем разница между Junior, Middle и Senior?
В форме вопрос-ответ кратко обсуждаем ключевые особенности карьерного роста разработчика и отличия позиций Junior, Middle и Senior.
С чего начать, чтобы стать айтишником, если вы далеки от IT
В статье мы расскажем, какие шаги предпринять, с чего начать и как построить свое обучение, чтобы стать айтишником, если вы далеки от ИТ.
Источник: proglib.io
Использование чужого кода в своих программах
Как пользоваться чужим кодом?
Работа с кодом — задача не из простых. Зачастую мы ищем готовые программные решения для своего проекта, но можно ли их копировать без разрешения?
Веб-разработка
4 мая 2021
Представим, что вам необходимо написать код. Есть два пути: погрузиться в язык программирования и несколько недель самостоятельно писать программу или за 20 минут найти в интернете уже готовый код, адаптировать его под свой проект и спокойно продолжить работу.
Первый вариант, безусловно, корректнет и полезен для развития ваших навыков программирования. Это идеальный вариант, который только можно представить. Второй вариант практичнее, поскольку вы затратите меньше ресурсов и сделайте задачи быстрее, но возникает вопрос — можно ли копировать чужой код и как это делать правильно?
Код — это интеллектуальная собственность
По закону код — это объект авторского права. Написав код, вы являетесь его автором, и никто не сможет лишить вас этого статуса.
Если вы работаете на компанию и пишете код для кого-то, то им могут владеть правообладатели или держатели исключительных прав, но вы все равно остаетесь автором кода. Ваши взаимоотношения с компанией, желающей получить права на использование вашего кода, скорее всего, будут прописаны в рамках трудового договора.
Почти у любого кода, размещенного в интернете, есть лицензия, которая описывает как, для каких целей и на каких условиях можно его использовать.
Какие бывают лицензии на код?
Лицензии на программное обеспечение бывают несвободными (проприетарными) и свободными. У каждой из этих категорий есть существенные различия, которые определяют права использования. Давайте разберемся, какие виды открытых лицензий бывают и что они означают.
Открытая лицензия позволяет свободно и совместно использовать, модифицировать программное обеспечение. То есть исходный код таких программ полностью доступен. Лицензией здесь будет обозначено, что можно делать с этим кодом, а что нет.
Организация по продвижению открытого ПО Open Source Initiative составила список популярных подтвержденных лицензий, которые помогут вам определить ваши права на использование кода:
GNU, General Public License (GPL)
Эта лицензия дает право распространения ПО, участия в его разработке или изменения различными способами при соблюдении этого правила: любые изменения программы, сделанные пользователем и распространенные им, должны иметь исходный код этих изменений.
Apache License 2.0.
Гибкая лицензия, которая дает право на безвозмездное, вечное, не эксклюзивное и глобальное использование ПО. Если вы распространяете код, вы должны указать имя разработчика.
BSD (Berkeley Software Distribution)
Используя эту лицензию, необходимо выполнить следующие условия: указать в документации, что в продукте используются разработки создателей оригинального программного обеспечения и не использовать имена (или названия) создателей этого ПО в рекламных целях без письменного согласия. Например, компания Apple использует преимущественно лицензии BSD.
GNU Lesser General Public License (LGPL)
Лицензия GNU дает больше прав, чем GPL. Главное отличие в том, что она позволяет использовать продукты LGPL в проектах, которые распространяются под другими лицензиями.
MIT license (Massachusetts Institute of Technology)
Лицензия разрешает использовать, копировать и модифицировать программное обеспечение на ваше усмотрение. ПО можно предоставлять бесплатно или даже продавать. По правилам этой лицензии ваше ПО должно сопровождаться лицензионным соглашением.
Лицензия схожа с BSD. Но в MIT можно использовать название продукта и имена создателей в рекламных целях. Под MIT распространяются X Window System (X11) и Ruby on Rails.
Как использовать код в своих целях
Использование чужого кода в процессе учебы
Если вы студент технического Университета, создавать собственный код бывает сложно, хотя и нужно, чтобы научиться. Проще всего скопировать чужой код из интернета, чтобы получить нужную оценку. Однако этот способ не является корректным, поскольку и дипломные, и курсовые работы проверяются на антиплагиат.
Если все сроки сдачи работ поджимают или вы не можете справить с заданием, попробуйте обратиться за помощью к преподавателю или однокурсникам. Такой жест оценят больше, чем попытки скопировать готовую работу. В противном случае постарайтесь использовать непопулярные имена для переменных и комментировать код в своем стиле. Так вы будете больше понимать принципы его работы и сможете ответить на вопросы преподавателей.
Использование чужого кода на работе
Многие работодатели уверены, что с вами достаточно заключить трудовой договор, и с этого момента всё, что бы вы ни создали на работе, будет принадлежать компании. Но это, как мы выяснили выше, абсолютно не так. Если работодатель не пропишет права на ваш код в трудовом договоре, он рискует, что одним днем вы превратитесь из его сотрудника в его злейшего конкурента.
За использование чужого кода в целях компании отвечает сам сотрудник, поскольку именно он получает зарплату за оригинальные программные решения. Поэтому обязательно отслеживайте источник кода и не забывайте уточнять, по какой лицензии он распространяется.
Использование чужого кода в целях бизнеса
Компании Google и Oracle судятся уже больше десяти лет. Причиной конфликта стало обладание Oracle правами на язык Java, который используется в экосистеме Android, принадлежащей Google. Корпорации не сумели договориться об условиях использования Java (точнее, его API), и Oracle подал иск почти на девять миллиардов долларов.
В случае с использования кода бизнесом риск повышается: нарушение бизнесом лицензий, авторских прав и исключительных имущественных прав грозит судебными разбирательствами. Судебные процессы не только отнимают уйму денежных средств, но и бьют по репутации компаний, замедляя процесс развития технологических продуктов во всем мире.
Источник: itlogia.ru