당신의 팀은 가능한 한 효율적입니까?어쩌면 조금 모자랄지도 모르지만, 나는 여전히 어느 곳에서 개선할 수 있는 공간에 돈을 쓸 것이다.
이제 IDE 확장을 통해 주요 문제가 해결되지는 않지만 팀에게 어떠한 요구 사항도 제시하지 않고 생산성을 향상시킬 수 있습니다.
이것이 바로 생산력의 의미이다.많은 작은 조정과 조정은 인류로 하여금 더 좋은 도구를 이용하여 그들이 가장 잘하는 일(공예와 창조적인 작업)을 할 수 있게 한다.
공자가 말한 바와 같다.

"If a craftsman wants to do good work, he must first sharpen his tools."

다음은 다섯 개의 VS 코드 확장입니다. 저는 팀의 모든 엔지니어들이 그것을 사용하도록 격려합니다.모든 항목이 생산력에 미미하지만 가치 있는 증량 공헌을 하기 때문에 건의합니다.

5 – 업무 트리

묘사

Todo Tree 는 작업공간에서 TODO, HACK 및 FIXME 주석 태그를 빠르게 검색하고 측면 막대의 트리 뷰에 표시합니다.
트리에서 처리해야 할 사항을 누르면 파일을 열고 정확한 줄로 이동하며 주석 자체가 돋보이기 때문에 무시할 수 없습니다.이것은 설정에서 구성할 수 있습니다.

왜?

나는 보통 코드에서 이런'todo'주석을 보는 것을 좋아하지 않는다. 특히'완성'과/또는 생산에 들어가야 하는 코드는 좋아하지 않는다.

// TODO: implement new feature
// FIXME: this is a known issue I haven't fixed yet
// HACK: revisit this later when we have more time

그럼에도 불구하고 생활은 혼란스러워서 항상 이런 일을 피할 수는 없다.개발자들은 반드시 이런 평론을 쓸 것이다. 그들은 때때로 의외로 원본 코드 관리에 힘쓰는데, 이것은 자주 발생하는 일이다.🤷‍♂️
어떤 때는 이런 평론들이 실질적인 가치를 지니고 있다. 예를 들어 일요일이 끝날 때 코드를 내일의 알림으로 전송하거나 개발자가 병이 나면 다른 사람들은 그들이 멈춘 곳에서 다시 시작해야 한다.
나는 이 평론들을 격려하는 경향이 없지만, 그것들이 갑자기 어디에 나타날지 감안하면, 우리는 그것들을 발견하고 처리할 수 있는 좋은 도구가 있을지도 모른다.코드가 새 프로젝트의 초기 단계에서 빠르게 변할 때 특히 유용하다.

4-GitLens

묘사

GitLens는 Git 저장소를 처리하는 데 더욱 직관적이고 우호적인 사용자 인터페이스를 제공하고 이 도구의 많은 흔한 용도에 단축키를 제공한다.
이것은 코드 편집기에서 유용한 정보를 직접 보여주고git 탓, 역사 내비게이션, 코드 비교에 사용되는 도구를 통해 코드 작성자의 신분을 시각화하는 데 도움을 준다.
이 확장은 사용자의 취향에 따라 행동을 조정할 수 있는 맞춤형 옵션도 많이 제공합니다.

왜?

여러 해 동안 나는 모든 프로젝트에서 Git를 사용해 왔다. 너도 마찬가지라고 생각한다.Git는 팀의 엔지니어가 서로 다른 학습 단계에 처할 수 있도록 완전히 파악해야 하는 복잡한 도구이다.
이것이 바로 이 확장의 의미이다.복잡한 도구를 간소화하는 것은 가치 있는 일이다.이 확장은 개발자가 IDE, 명령줄, VCS 공급자 사이에서 상하문을 전환할 필요가 없다는 것을 의미한다.
마이크로소프트가 GitHub을 인수한 이래로 Git의 VS 코드 통합은 비약을 이루었다.아마도 미래에 이 확장은 전혀 필요없을 것이다.
현재로서GitLens는 명령줄이나 투기적인 온라인 도구를 빌리지 않아도 코드 라이브러리의 변화에 대해 가치 있는 견해를 제공할 수 있다.

3 - 구성 편집

묘사

EditorConfig는 서로 다른 편집기와 IDE에서 같은 프로젝트의 여러 개발자에게 일치하는 인코딩 스타일을 유지하는 데 도움이 됩니다.
이 확장자는 프로젝트 저장소에 제출된 .editorconfig를 읽고 프로젝트로 전환할 때 의 설정을 자동으로 적용합니다.사용 가능한 옵션에 대한 전체 정의는 다음을 참조하십시오.https://editorconfig.org

왜?

나에게 있어서 일치성은 고품질 공사의 중요한 원칙이다.일치성은 오류를 줄였다. 코드를 읽거나 작성하는 사람들의 인지적 부담을 줄이고, 유사한 문제가 발생할 때마다 깊이 연구할 필요가 없이 어떤 것들이 어떻게 작동해야 하는지 은밀하게 이해할 수 있기 때문이다.
편집기 설정은 개발자 간의 일치성을 확보하는 아주 간단한 도구로 상당히 오랫동안 존재해 왔다.나는 가능한 한 git Diff의 깔끔함을 유지하는 것을 좋아한다. 빈칸, 줄 바꾸기, 축소 문자 등의 변화를 보면 곧 사람을 고통스럽게 할 것이다.
확장은 저장소 루트 디렉토리의 .editorconfig 파일에 따라 자동으로 전환된 각 항목에 대해 올바른 IDE 설정을 설정합니다.
따라야 할 풍격에 대해 결정을 내리고 처리하다.이 확장자를 설치한 모든 개발자는 같은 스타일로 코드를 작성하여git Diff의 공백 소음을 피할 것입니다.

2-코드 맞춤법 검사

묘사

코드 맞춤법 검사기는 기본 맞춤법 검사기로서camelCase 코드를 잘 처리할 수 있다.확장의 목표는 낮은 오보율을 유지하면서 흔히 볼 수 있는 맞춤법 오류를 포착하는 것이다.
그것의 디자인은 워드프로세서의 맞춤법 검사기처럼 전면적이지는 않지만, 어리석은 오류를 방지하기에 충분하다.
이 확장은 미국 영어보다 훨씬 많은 언어를 지원하는데, 이것은 다른 영어를 사용하거나 완전히 다른 언어를 사용하는 사람들에게 복음이다.

왜?

맞춤법 오류는 매우 흔하다.이것은 수동 코드 (예를 들어 주석, 문서, 사용자 알림을 포함하는 문자열 등) 의 파괴자가 아닐 수도 있지만, 커다란 연쇄 반응을 일으킬 수 있고, 오류는 종종 영원히 존재할 수 있다.
HTTP Referer 헤드의 예를 보십시오. 이 헤드는 20여 년 전의 원시 규범misspelled이고 계속 존재할 것입니다.

HTTP referer - Etymology
컴퓨터 과학자 필립 할람 베이커(Phillip Hallam Baker)가 최초의 제안에서 Referer의 맞춤법 오류를 도입하여 "Referer"헤더 필드를 HTTP 규범에 통합하였습니다[7] 이 맞춤법 오류는 (1996년 5월) 의견수렴 표준 파일인 RFC 1945에 포함되었을 때 이미 사실이 되었다(이 파일은 당시 "HTTP/1.0"이라고 불렸던 프로토콜의 흔한 사용법을 반영했다).문서의 공동 저자인 로이 필딩(Roy Fielding)은 1995년 3월 "당시의 표준 Unix 맞춤법 검사기는 모두 이해하지 못했다(referer 또는 referer)[9] "Referer"는 HTTP Referer를 토론할 때 업계에서 광범위하게 사용되는 맞춤법이 되었다.그러나 맞춤법 오류의 사용법은 보편적이지 않다. 일부 웹 규범에서 정확한 맞춤법'referer'를 사용했기 때문이다. 예를 들어 <코드>referer 정책 HTTP 헤더나 문서 대상 모델 [3]
View on Wikipedia
잘못된 이름의 함수, 변수 등이 삽입되면 바꾸기 어려울 뿐만 아니라, 미래에 이 코드를 읽거나 사용해야 할 모든 개발자들에게 곤혹과 좌절을 가져올 수도 있다.
이런 잘못은 종종 네가 고치려고 하는 것보다 더 많은 정력을 들여야 한다.그래서 영원한 어색함을 피하고 처음부터 잘해라.

1.더 예쁘다

묘사

Prettier는 자기 의견을 고집하는 코드 포맷 프로그램입니다.이것은 코드를 해석하고 자신의 규칙을 사용하여 코드를 다시 인쇄합니다. (최대 행장을 고려해서) 일치하는 스타일을 강제로 실행하고 필요할 때 코드를 포장합니다.
Pretter 지원: JavaScript,TypeScript,Flow,JSX,JSON,CSS,SCSS,Less,HTML,Vue,Angular,GraphQL,Markdown,YAML.사용 가능한 옵션에 대한 전체 정의는 다음을 참조하십시오.https://prettier.io

왜?

현재 나는 모든 엔지니어가 더 예쁜 언어로 코드를 작성하는 것은 아니라는 것을 알고 있지만, 이러한 개발자들에게 이것은 시간을 절약하는 커다란 도구이다.설정 편집기에 있어서 일치성과 읽을 수 있도록 하는 것은 매우 중요하지만, 설정 편집기에 있어서 이러한 확장은 곧 매우 가치가 있을 것이다.
Prettier는 지원하는 언어에 매우 유용하다. 왜냐하면 이 언어들은 매우 유연하고 다양한 스타일로 작성할 수 있기 때문이다.더 말할 것도 없이, 더욱 현대적인 언어와 달리, 그것들 중 대부분은 공식적인 스타일 안내서나 형식 도구가 없다.
개발자가 자바스크립트에서 번호를 나누어야 하는지, 탭이나 빈칸을 줄여야 하는지, 스타일 변화로 어려움을 겪는git의 차이를 읽는 데 얼마나 많은 시간을 낭비했는지 계산할 수 없습니다.
비록 모든 이 문제들에 대해 합리적인 답안이 있지만, 나는 이미 이 논쟁들이 모든 단체에서 계속 불필요하게 격렬하게 진행되는 것을 보았다.Prettier는 모든 개발자에게 자신의 의견을 고집하는 스타일을 강제로 추진함으로써 이 모든 것을 끝내고, 소량의 유연성으로 자신의 행동을 바꾸기만 하면 된다.
내가 Prettier를 좋아하는 점은 코드 스타일이 저장할 때 자동으로 적용되기 때문에 내가 얼마나 깔끔한지 고려할 필요도 없다. Prettier가 나를 위해 이 점을 해 줄 것이다.그리고 하나는 효율을 높이기 위해서!
🌍 Website | 📇 | 🐥 | 📕 | 📗 Medium