Обзор различных обстоятельств, при которых программист может и не может копировать

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

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

Давай начнем!

Сценарий 1. «Работая над своими сторонними проектами, я иногда просто копирую и вставляю блоки своего предыдущего кода, чтобы решить повторяющуюся проблему».

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

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

Сценарий 2. "Я не знал, что делать, поэтому погуглил и скопировал код, найденный в блоге, который отвечает на мой вопрос".

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

Эффективно ли это? Да, но только при строгом и не подлежащем обсуждению условии: вы понимаете, как работает код, прежде чем копировать его. Принятие решений от того, кто предлагает их бесплатно, не может быть неправильным, но интерполяция кода, который вы не понимаете, в свой проект — верный путь к катастрофе. На самом деле, «копирование» в такой ситуации на самом деле не относится к «копированию и вставке» (если только фрагмент не является просто крошечным фрагментом). Обычно это означает копирование решения в аннотации, а затем переписывание его в своем собственном стиле или, что еще лучше, в стиле вашей команды (если они уже привержены синтаксису ES6, а пример находится в ES5, то вам решать). перепишите его). Таким образом вы можете убедиться, что код — это то, с чем вы сможете снова работать в будущем, а не просто патч для обстоятельств.

Сценарий 3. "Мы с коллегой работаем над одним проектом, и я скопировал то, что она сделала, чтобы решить проблему на моей стороне".

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

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

Сценарий 4. "Я работаю над сложным проектом для своей компании, и его нужно закончить на этой неделе. Я наткнулся на фрагмент кода с открытым исходным кодом, поэтому я использовал его в своем проекте, чтобы ускорить свою работу».

Этично ли это? Абсолютно нет. Ни при каких обстоятельствах вы не должны считать приемлемым брать открытый исходный код и вставлять его в свой проект. Программное обеспечение с открытым исходным кодом общедоступно, но это не значит, что оно не лицензировано — и несоблюдение лицензии может легко привести к потере работы, а в случае судебного процесса — к банкротству и вашей компании. Условия, связанные с лицензиями, могут быть различными: от простой аккредитации любым пользователем кода до создания собственного проекта с открытым исходным кодом. Но одно можно сказать наверняка: если проект, над которым вы работаете, является собственностью (то есть он принадлежит частному лицу, включая вас как свободного агента), то вам точно не разрешат использовать лицензионный код. Единственным исключением является код общественного достояния, то есть код, в отношении которого его создатели отказались от всех притязаний на авторские права, и который можно свободно копировать. Даже в этом случае было бы неплохо прояснить, откуда оно взялось.

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

Заключение

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

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