동의, 놀라운 일이 아니다;

}else if (사장님은 매우 개명합니다) {//아무것도 아니지만 개명합니다.

프로그래머의 관행을 신뢰하고 존중하다.

}else{ // 아무것도 모르는 것이 아니라 함부로 추측하고 있다.

합리적인 설명이 필요할 수 있습니다.

}

프로그래머는 왜 인터넷에서 코드를 표절합니까? 우리 프로그래머는 이런 표절을 부르지 않고, 일반적으로' 코드 재사용' 이라고 부른다.

프로그래머가 새로운 프레임워크, 클래스 또는 메서드를 사용해야 하는 경우 소급 가능하고 합리적이어야 합니다. 즉, 함부로 사용하지 마십시오.

예를 들어 Spring Boot 프로젝트 중 하나가 현재 Rabbit MQ 를 사용하려고 하지만 이전에는 사용하지 않았습니다. 어떻게 해야 할까요? 프로그래머는 일반적으로 여러 가지 방법으로 이 작업을 수행합니다.

제안 사항 중 일부는 먼저 방안 1 과 3 을 시도해 보고, 스스로 해결할 수 없다면 다른 동료에게 문의하는 것이 좋습니다.

Java 개발, 아키텍처 디자인, 프로그래머 경력 개발 등에 대한 저의 견해를 계속 공유하겠습니다. 여러분의 관심을 받기를 바랍니다.

복사 코드에는 세 가지가 있습니다.

첫째, 전체 프로젝트를 복사하고, 다른 사람의 코드를 복사하고, 어떠한 변경도 하지 않는다. 이런 상황은 매우 드물다. 첫째, 저작권 문제가 관련되어 있습니다. 둘째, 온라인 코드는 모두 좋지 않다. 그들을 베끼는 것은 무의미하고 수확도 없다.

둘째, 베끼기, 이것은 비교적 흔하다. 건물을 짓는 것을 예로 들면, 다른 사람이 쌓은 기초와 세워진 비계를 직접 이용하여 인프라 작업을 줄일 수 있다. (윌리엄 셰익스피어, 템플릿, 자기관리명언) 집을 지을 때는 직접 벽돌을 쌓기 시작하고, 코딩할 때는 직접 업무 논리를 쓰기 시작한다. 이점은 분명합니다. 프로젝트 초반의 반복 작업을 줄이고 많은 인력과 물력을 절약할 수 있습니다. 사장의 집에 광산이 없다면, 일반적으로 다른 사람의 틀을 사용하는 것에 반대하지 않는다.

셋째, 복제 알고리즘입니다. 간단한 알고리즘은 직접 쓸 수 있습니다. 예를 들어, 두 숫자의 합계를 구하는 것은 매우 간단합니다. 한 줄의 코드를 완성할 수 있습니다. 복잡하고 얼굴 인식 알고리즘, 수백만 줄도 없고 수십만 줄의 코드도 있어 회사의 모든 자원을 투입하는 것이 반드시 가능한 것은 아니며, 기술 함량이 매우 높다. 이때 우리는 종종 전문 알고리즘 회사의 협력을 구하고 관련 코드를 유료로 얻는다.

프로그래머가 사장에게 인터넷에서 코드를 베끼는 것을 발견하면 어떻게 될까? 이런 일은 사장에게 들켰는데, 적어도 지금부터는 아무 일도 없다. 만약 미리 항목을 베껴 쓸 수 있다면, 문제없고, 버그도 없고, 분쟁도 없으면 사장은 크게 기뻐할 것이다. 그에게 적지 않은 돈을 절약했고, 그도 기분이 좋지 않았다.

물론, 인터넷에서 코드를 표절한다고 해서 전체 프로젝트가 인수되는 것은 아니다. 특히 지적재산권이 있는 사람은 원저작권자에게 들키면 분쟁을 일으킬 수 있다. 대부분의 프로그래머들은 코드를 작은 조각으로 복제하여 작은 기능을 구현하거나 메소드, 클래스 등의 용도를 복제하여 자신의 프로젝트에서 필요한 기능을 실현하고 자신의 프로젝트에 통합하는 것입니다. 맹목적으로 그대로 복사하고 이식하는 것이 아니라, 자신의 프로젝트에 통합하는 것이다. (윌리엄 셰익스피어, 윈스턴, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머) 프로그래머는 이런 일을 거의 하지 않는다.

프로그래머는 인터넷 학습 조회를 거의 하지 않는다. 현재 많은 사장이 원래 소프트웨어 프로젝트나 프로그래머 출신이다. 그들은 이미 이런 수법들이 자기도 사용했다는 것을 알고 있었다. 전혀 크게 놀랄 만한 가치가 없다. 기본적으로 프로그래머는 아무것도 모르면 바이두에 가서 인터넷 관련 해결책을 찾도록 독려된다.

가능한 한 빨리 해결책을 찾으면 문제를 줄이고 거기에 너무 많은 시간을 할애할 수 있다. 대부분의 사장은 당신이 연구 코드의 선봉이 될 것을 요구하지 않고, 프로젝트 기능을 실현할 수 있는 기술 전문가가 될 것을 요구한다. 대부분의 사장은 네가 어떻게 그 기술을 얻을 수 있는지 신경 쓰지 않는다.

그래서 아무도 당신이 코드를 베끼는지 신경쓰지 않습니다. 가장 중요한 것은 복사된 코드가 프로젝트 문제를 해결하고, 프로젝트 진행 속도를 높이고, 프로젝트 비용을 절감할 수 있는지 여부입니다. 문제를 해결하고 프로젝트에 이익을 가져다 줄 수만 있다면, 감독이나 사장은 모두 네가 대가이며 유능한 사람이라고 칭찬할 것이다. (윌리엄 셰익스피어, 윈스턴, 일명언)

더 많은 공유 상호 작용은 오른쪽 위 구석을 클릭하여 동풍 고양 주목해 주세요.

코드를 복사할 수 있다면 올바른 코드 복사 방법을 선택하고 내가 괜찮다고 생각하는 몇 가지 사이트를 추천한다.

일상적인 개발 문제의 90% 이상을 덮을 수 있는 웹사이트가 있다면 바로 이 사이트입니다. 여기에는 다양한 코드가 있습니다. 만약 네가 훌륭한 프로그래머라면, 나는 네가 여기에 와서 코드를 복사하는 것을 추천한다.

자신의 github 계정이 없다면 빨리 등록해야 합니다. GitHub 에는 Vue, React 등과 같은 좋은 오픈 소스 프로젝트가 많이 있습니다. 좋은 프로젝트를보고 싶다면 GitHub 에 오는 것이 좋습니다.

만약 네가 검색 엔진을 잘 사용한다면, 너는 이미 일반인보다 훨씬 강하다. 몇 가지 검색 기술을 사용하는 법을 배우면 문제를 빠르게 발견하는 데 도움이 될 수 있다.

그래서, 나는 표절 코드에 무슨 잘못이 있다고 생각하지 않는다. 제 생각에는 좋은 코드를 복사하고, 다른 사람의 장점을 보고, 자신의 프로젝트에 사용하는 것이 옳다고 생각합니다. 이것은 전혀 문제가 없다.

고임금 프로그래머에게 가장 익숙한 두 가지 바로 가기는 ctrl+c 와 CTRL+V 입니다.

여기 보시면, 이렇게 생각하실 겁니다.

와, 프로그래머가 되기가 너무 쉬워요. 관련 지식을 알고, 그냥 매일 복사하여 붙여 넣고, 그렇게 높은 임금을 받고, 또 천리가 있습니까?

첫째, "코드 재사용" 은 매우 일반적입니다. 사회학과 경제학의 관점에서 볼 때, 재활용은 한정된 사회 자원의 낭비를 피할 수 있기 때문에 긍정적이다.

오픈 소스 코드를 합리적으로 사용하면' 바퀴 반복' 동작을 피할 수 있어 많은 프로그래머들이 보다 가치 있는 개발 작업을 수행하고 개발 효율성을 가속화하며 자원 가치를 극대화할 수 있습니다.

소스 코드를 회사에 적합한 프로젝트로 놓으려면 탄탄한 기초가 있어야 한다. (윌리엄 셰익스피어, 소스, 소스, 소스, 소스, 소스, 소스, 소스) 관련 프로젝트 경험이 없다면 코드를 어떻게 유지합니까?

그 이유를 알고, 그 이유를 더 잘 안다.

이것이 고임금 프로그래머들의 고명한 점이다. 오픈소스 코드를 이용해 자신의 문제를 해결하고, 아키텍처와 사상을 자신의 논리에 융합해 표현한다는 것이다.

프로그래머는 주로 기능 요구 사항을 달성합니다. 어떻게 실현할지는 인터넷에서 베끼는 것은 상관없다. 실제로 얼마나 많은 프로그래머가 인터넷에서 코드를 직접 복사하지 않고 자신의 모듈에 적용합니까? 실제 코드 작성 과정에서 우수한 코드를 이해하고 유연하게 작성하는 경우가 흔하다. 이제 오픈 소스 커뮤니티가 전형적입니다. 많은 회사들이 공명정대하게 이렇게 할 것이며, 오늘날의 기술 분야에서는 특히 정상적이다.

만약 사장이 정말로 코드가 인터넷과 매우 가깝다는 것을 발견했지만, 기능 사용에 문제가 없다면, 프로그래머를 찾아 이야기하면, 그 사장은 문제가 있을 것이다. 일반적으로 코드의 감사는 주로 직접적인 기술 책임자에 있다. 사장은 코드가 인터넷에서 찾았는지, 방향이 어림잡힐까 봐 걱정했다. 사장은 보통 결과가 달성되었는지에 관심이 있다. 만약 그가 자신의 상권을 더욱 확대한다면 생산액을 극대화해라.

당신을 도울 수 있기를 바랍니다.

사장의 태도는 무시하거나 비판적으로 거들떠보지도 않는 것이다. 사장의 태도에서 많은 것을 반영할 수 있다.

그것을 무시하지 마라: 사장은 절차를 모르거나 알고 있다. 사장이 절차를 이해하지 못하고 무시하는 것은 정상이다. 만약 사장이 절차를 안다면, 그는 이것이 정상이라는 것을 이해해야 한다. 이런 태도는 현명한 행동이다.

비판 또는 해고: 사장은 분명히 절차를 모른다. 그가 절차를 모르기 때문에 거기서 명령을 내리지 마라. 대오에는 자연히 상수가 있을 것이다. 사장의 직책은 전반을 총괄하는 것이다. 만약 네가 이런 사소한 일에 끼어들고 싶다면, 머물지 말고 바로 떠나라. 이것은 분명히 너의 발전을 제한할 것이다.

프로젝트는 원래 결과 지향적이어서 임무가 긴박하고 공사 기간이 짧다. 특히 창업형 회사, 무에서 유무에 이르는 발전에 얼마나 많은 정력과 인력이 필요한가? 반드시' 가져오기주의' 를 배우고, 그 찌꺼기를 버리고, 그 정수를 취해야 한다!

코드 농부로서, 나는 다른 기능 코드를 복사하고, 약간의 수정을 하고, 자신의 일을 완성했다. 이 방법은 간단하고, 빠르고, 사용하기 쉽고, 버그가 적습니다.

코드를 복사할 수 있고, 어디서 코드를 복사할 수 있는지, 어떤 코드를 복사할 것인지, 어떤 코드를 복사할 것인지, 복사 후 어떻게 통합할 수 있는지, 문제를 해결할 수 있는지, 코드가 실제로 실행되었습니다! 이것도 일종의 기술이다! 이것도 자신을 단련하는 한 가지 방법이다!

그래서, 나는 복사 코드에 대해 깨어 있는 인식을 유지해야 복제될 수 있다!

이른바' 천하 문장 모두 베껴 쓴다' 는 것이다. " 우리가 일할 때, 보도 자료, 회의록 등. 일정한 템플릿도 있고, 우리는 조롱박과 바가지를 맞추기만 하면 된다. (윌리엄 셰익스피어, 템플릿, 템플릿, 템플릿, 템플릿, 템플릿, 템플릿, 템플릿명언) 그렇다면 프로그래머가 인터넷에서 코드를 베끼면 어떤 처분 결과가 나올까?

실제로 코드를 작성하는 가장 중요한 것은 다른 프로그래머의 코드와 사고를 이용하여 문제를 해결하는 방법을 배우는 것이다. 프로그래머의 표절 코드도 상황에 따라 세 가지로 나눌 수 있다: 표절 알고리즘, 표절 프레임, 전체 프로젝트 표절.

사실, 간단한 알고리즘은 스스로 쓸 수 있습니다. 복잡한 게임, 예를 들어, 코드는 회사 전체의 프로그래머들이 인생을 의심하게 하기에 충분합니다. (존 F. 케네디, 컴퓨터명언) 그리고 일반적으로 이 복잡한 코드는 대형 알고리즘 회사와 협력해야 하며, 단순한 온라인 복제가 아닙니다.

응용 프로그램이나 기능 프레임워크를 복제하는 이점도 분명합니다. 이 프로젝트의 초기 반복 작업을 줄이고 많은 인력과 물력을 절약할 수 있습니다. 동료도 기존의 기초 위에서 자신의 요구에 따라 약간의 개선을 할 수 있다. 왜 안돼? 또한, 실제로 가장 기초적인 시기부터 한 글자 한 글자 한 글자 한 글자 전체 프로그램 코드를 두드리는 프로그래머는 매우 적을 것이다.

하지만! 전체 프로젝트는 다른 사람의 코드를 표절했고, 아무런 변화도 없었다. 이것은 저작권과 프라이버시 문제를 포함하며, 심하면 법적 책임을 져야 한다.

그래서 프로그래머가 인터넷에서 코드를 베끼기 위해 직면해야 할 결과는 두 가지밖에 없다. 사장이 아랑곳하지 않거나 비판을 받는 것이다.

프로그래머가 해야 할 일은 코드를 복사할 곳, 복사할 코드, 복사 후 통합할 코드, 문제 해결 등을 아는 것이 가장 중요하다.

첫째, 일반 회사 사장은 결코 기술을 이해하지 못한다. 그는 네가 정보를 찾고 있는지 아니면 베끼고 있는지 전혀 이해하지 못한다. 둘째, 표절이 들켜도 정상이고 초급 프로그래머가 코드를 베끼는 것도 정상이다. 아래와 같은 하이라이트를 주시하고 시청합니다.

텍스트 | 쇼빈에서 과학 기술 블랙홀

나는 세계 500 대 기업에 있는데, 회사 사장은 분명히 본 적이 없을 것이다. 부서 사장은 우리 같은 일반 프로그래머들을 거의 방문하지 않는다. 기술도 우리는 이해하지 못한다. 소위 사장이라고 하는 것은 기술감독이어야 하지만, 아쉽게도 기술감독은 일반적으로 너의 답안을 건드리지 않는다. 기술 감독은 보통 기술 관리자이고, 일반 프로그래머는 기술 관리자를 주관하며, 프로젝트에서 일한다. 설령 그가 네가 코드를 베끼는 것을 발견하더라도, 그는 아무 말도 하지 않을 것이다. 네가 맡은 임무를 완수할 수만 있다면, 네가 어떻게 하든 간에. 심지어 그가 당신에게' 베끼기' 를 가르쳐 줄 수도 있지만, 사실 이것은 당신이 코드를 배워서 자신의 좌우를 완성할 수 있게 하는 것이다. (존 F. 케네디, 공부명언)

현재 프로그래머가 코드를 베끼는 것은 흔히 볼 수 있는데, 인터넷이나 동료의 것이다. 동료의 기능을 직접 바꾸지 않고 베끼는 것은 약간 무뇌한 반면, 다른 사람의 코드를 재사용하는 것은 정확하다. 종종 코드의 깔끔함을 높일 수 있다. 인터넷에서 베끼면, 일반적으로 기성품 코드를 사용할 수 없다. 너는 그것의 생각을 빌려서 자신의 업무와 결합하여 자신의 코드를 쓸 수 밖에 없다. 이것은 종종 프로그래머가 좋은 기초를 가지고 있어야 한다. 그렇지 않으면 너는 다른 사람의 코드도 어떻게 사용하는지 모른다.

프로그래머 유 는 말했다:

"복사" 코드를 잘하는 것은 프로그래밍 미학이지만 우아하게 해주세요. 나는 그것을 말하는 것이 좋다고 생각한다. 주의하다.

제품 기능 내보내기 프로세스:

1. 제품 관리자: 요구 사항 조사, 제품 요구 사항 문서 및 프로토타입 도면의 출력입니다.

둘째, 수요의 타당성 (이동, 프런트엔드, 백엔드, UI, 테스트, 제품) 에 대해 논의합니다.

셋째, 각 직능직의 의견과 수요 산출의 시간 비용 등 조건 요소에 따라 수요를 수정한다.

넷째, 요구 사항 문서 및 프로토타입 다이어그램은 UI, 백엔드 및 테스트에 제공됩니다.

1. 요구 사항 문서 및 프로토타입에 따른 UI 디자인 효과, 레이블 및 자르기 차트.

2. 백엔드 요구 사항 문서 및 프로토타입 다이어그램을 기반으로 데이터베이스 테이블 구조, 인터페이스 데이터 구조 및 인터페이스 문서를 설계합니다.

요구 사항 문서 및 프로토 타입 도면을 기반으로 테스트 케이스를 작성하십시오.

5. 위에서 언급한 출력 (설계도, 스티커, 오려내기) (인터페이스 문서) 은 이동측과 프런트 개발자에게 개발된다.

6. 개발자가 자체 테스트를 완료한 후 기능 테스트 및 성능 테스트를 위해 테스터에게 전달됩니다.

1. 테스터는 테스트 사례에 따라 기능 테스트를 수행하고 보고 피드백 (모바일, 프런트 엔드, 백 엔드, UI, 테스트, 제품), 버그 복구, 요구 사항 개선, 상호 작용 최적화 등을 구성합니다.

2. 성능 테스트에는 백엔드 스트레스 테스트, 모바일 메모리 등이 포함됩니다.

마지막으로 그레이 스케일 테스트 또는 내부 공개 측정을 수행하십시오.

여덟, 최종 제품 업데이트 온라인.

앞서 언급했듯이 프로그래머는 기능 개발 과정에서 제품 기능의 안정성과 확장성을 보장하는 것이 가장 중요합니다. 어떻게 실현할지에 관해서는, 만약 뜻밖의 일이 아니라면. 지도자는 네가 어떻게 실현하는지 개의치 않는다. 그리고 프로그래머들은 이 업계에서 일하며 붙여넣기 코드를 어떻게 복사할지 생각하는 것은 흔한 일이다. (윌리엄 셰익스피어, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머, 프로그래머) 그래서. 。 너의 이 문제는 사실 문제가 아니다.