풀링 스파게티 코드 : 관리 가능한 자바 스크립트 작성

이 기사는 Tom Greco, Dan Prince 및 Yaphi Berhanu가 검토 한 동료입니다. Sitepoint 콘텐츠를 최선을 다해 Sitepoint의 동료 리뷰어 덕분에! 거의 모든 개발자는 레거시 프로젝트를 유지하거나 인계 한 경험이있었습니다. 아니면 다시 픽업 된 오래된 프로젝트 일 수도 있습니다. 일반적인 첫 번째 생각은 코드 기반을 버리고 처음부터 시작하는 것입니다. 코드는 지저분하고 문서화되지 않았으며 모든 것을 완전히 이해하는 데 며칠이 걸릴 수 있습니다. 그러나 적절한 계획, 분석 및 우수한 워크 플로를 사용하면 스파게티 코드베이스를 깨끗하고 체계적이며 확장 가능한 제품으로 바꿀 수 있습니다. 많은 프로젝트를 인계하고 정리해야했습니다. 처음부터 시작한 사람은 많지 않았습니다. 사실, 나는 현재 그것을 정확하게하고 있습니다. 나는 JavaScript에 관해 많은 것을 배웠고, 코드베이스를 정리하고 가장 중요한 것은

가 이전 개발자에게 미치지 않는 것이 아닙니다. 이 기사에서 나는 당신에게 내 단계를 보여주고 내 경험을 말하고 싶습니다.

키 테이크 아웃

프로젝트 이해 첫 번째 이해 : 코딩으로 다이빙하기 전에 기존 코드베이스를 철저히 분석하고 사용 된 기술과 도구를 이해하고 사용 가능한 문서 또는 단위 테스트를 연구하여 프로젝트 기능에 대한 더 깊은 통찰력을 얻으십시오.

. 일관된 코딩 표준 설정 :`. editorconfig` 파일을 구현하여 다양한 개발자가 사용하는 다양한 편집자 및 IDE에서 일관된 코딩 스타일을 유지합니다. 여기에는 일관된 압입과 명명 규칙에 대한 준수가 포함됩니다.

> 라인 도구 구현 : Eslint와 같은 JavaScript Linter를 사용하여 코딩 표준 및 모범 사례를 시행하고 코드 품질을 보장하며 개발 프로세스 초기에 오류를 식별하고 수정하는 데 도움을줍니다. 현명하게 의존성 관리 : 프로젝트 종속성을 신중하게 업데이트하고, 프로젝트에 새로운 오류를 도입하지 않도록 주요, 미성년자 및 패치 버전의 변화의 의미를 이해합니다. 주의를 기울인 리팩터 : 적절한 경우 코드베이스 모듈화에 중점을 두어 단일 책임 원칙을 따르는 복잡한 기능을 작고 관리하기 쉽고 재사용 가능한 모듈로 나눕니다. 정기적으로 문서화 및 커밋 : 종합 문서화를 위해 JSDOC를 사용하고 정기적으로 커밋 워크 플로우를 유지하여 변경 사항을 추적하고 필요한 경우 롤백을 용이하게합니다. 리팩토링 및 새로운 기능을 효과적으로 관리하기 위해 항상 마스터와 별도의 지점에서 작업하십시오.
프로젝트를 분석하십시오 첫 번째 단계는 무슨 일이 일어나고 있는지에 대한 개요를 얻는 것입니다. 웹 사이트 인 경우 모든 기능 (개방형 모달, 양식 보내기 등)을 클릭하십시오. 그렇게하는 동안 개발자 도구를 열어두고 오류가 팝업되는지 또는 무엇이든 기록되고 있는지 확인하십시오. Node.js 프로젝트 인 경우 명령 줄 인터페이스를 열고 API를 통과하십시오. 최선의 경우 프로젝트에는 진입 점 (예 : main.js, index.js, app.js,…)이 있습니다. 여기서 모든 모듈이 초기화되거나 최악의 경우 전체 비즈니스 로직이 있습니다. 사용중인 도구를 찾으십시오. jQuery? 반응? 표현하다? 알아야 할 중요한 모든 목록을 만드십시오. 프로젝트가 Angular 2로 작성되었으며 그 작업을 수행하지 않았고 문서로 바로 가서 기본적인 이해를 얻었습니다. 모범 사례를 검색하십시오. 더 높은 수준에서 프로젝트를 이해하십시오 기술을 아는 것은 좋은 출발이지만, 실제 느낌과 이해를 얻으려면 단위 테스트를 살펴볼 시간입니다. 단위 테스트는 기능을 테스트하는 방법이며 코드가 의도 한대로 동작하도록 코드의 방법입니다. 독서 및 실행 - 단위 테스트는 코드 만 읽는 것보다 훨씬 더 깊은 이해를 제공합니다. 프로젝트에서 단위 테스트가 없다면 걱정하지 마십시오.
• 기준을 만듭니다 이것은 일관성을 확립하는 것입니다. 프로젝트 툴체인에 대한 모든 정보를 얻었으므로 구조와 논리가 어떻게 연결되어 있는지 알 수 있으므로 이제 기준선을 만들 시간입니다. 코딩 스타일 가이드를 다른 편집자, IDE 및 개발자간에 일관성있게 유지하기 위해 .editorconfig 파일을 추가하는 것이 좋습니다. 코 히어 런트 계약 공백이나 탭을 사용해야하는지 여부는 중요하지 않습니다. 코드베이스는 공간으로 작성됩니까? 공간을 계속하십시오. 탭으로? 사용하십시오. 코드베이스에 혼합 된 압입이있을 때만 사용할 것인지 결정해야합니다. 의견은 괜찮지 만 좋은 프로젝트는 모든 개발자가 번거 로움없이 작동 할 수 있도록합니다. 왜 이것이 중요한가? 모든 사람은 편집자 또는 IDE를 사용하는 자신의 방법이 있습니다. 예를 들어, 나는 코드 폴딩의 열렬한 팬입니다. 그 기능이 없으면 문자 그대로 파일에서 길을 잃었습니다. 인기가 일관되지 않으면이 기능이 실패합니다. 그래서 파일을 열 때마다 작동을 시작하기 전에 들여 쓰기를 수정해야했습니다. 이것은 큰 시간 낭비입니다.
  이름 지정

  프로젝트에 사용 된 명명 규칙이 존중되어 있는지 확인하십시오. Camelcase는 일반적으로 JavaScript 코드에서 사용되지만 혼합 규칙을 많이 보았습니다. 예를 들어, jQuery 프로젝트는 종종 jQuery 객체 변수 및 기타 변수의 혼합 된 이름을 혼합합니다.

  모든 것을 줄이 이전 단계는 더 화장품이었고 주로 코드를 더 빨리 스캔하는 데 도움이되었지만 여기서는 일반적인 모범 사례와 코드 품질을 소개하고 보장합니다. Eslint, Jslint 및 Jshint는 요즘 가장 인기있는 JavaScript Linters입니다. 개인적으로, 나는 Jshint와 많은 일을했지만 Eslint는 주로 맞춤형 규칙과 초기 ES2015 지원으로 인해 내가 가장 좋아하는 것이되기 시작했습니다.

  . 라인을 시작할 때 많은 오류가 나타나면 수정하십시오! 린터가 행복하기 전에 다른 것을 계속하지 마십시오! 의존성 업데이트 의존성 업데이트는 신중하게 수행해야합니다. 의존성이 겪은 변경 사항에주의를 기울이지 않을 때 더 많은 오류를 도입하기가 쉽습니다. 일부 프로젝트는 고정 버전 (예 : v1.12.5)에서 작동 할 수있는 반면 다른 프로젝트는 와일드 카드 버전 (예 : v1.12.x)을 사용합니다. 빠른 업데이트가 필요한 경우 버전 번호는 다음과 같이 구성됩니다 : major.minor.patch. 시맨틱 버전이 작동하는 방식에 익숙하지 않다면 Tim Oxley 의이 기사를 읽는 것이 좋습니다. 종속성을 업데이트하는 일반적인 규칙은 없습니다. 각 프로젝트는 다르므로 처리해야합니다. 종속성의 패치 번호를 업데이트하는 것은 전혀 문제가되지 않아야하며, 미성년자도 일반적으로 괜찮습니다. 의존성의 주요 수를 충돌 할 때만 정확히 변경된 내용을 찾아야합니다. API가 완전히 변경되었을 수 있으며 응용 프로그램의 많은 부분을 다시 작성해야합니다. 그만한 가치가 없다면 다음 주요 버전으로 업데이트를 피할 것입니다.

  프로젝트가 NPM을 종속성 관리자로 사용하고 경쟁 업체가없는 경우 CLI의 편리한 NPM 구식 명령으로 구식 종속성을 확인할 수 있습니다. FrontBook이라는 프로젝트 중 하나의 예제와 함께 모든 의존성을 자주 업데이트합니다.

  보시다시피 여기에는 많은 주요 업데이트가 있습니다. 한 번에 모두를 업데이트하지 않고 한 번에 하나씩 업데이트 할 것입니다. 물론, 이것은 많은 시간이 걸리지 만, 프로젝트에 테스트가없는 경우 아무것도 깨지지 않는 유일한 방법입니다. 손을 더럽 히 봅시다 내가 당신과 함께 가져 가고 싶은 주요 메시지는 청소가 반드시 큰 코드 섹션을 제거하고 다시 작성하는 것은 아닙니다. 물론 이것은 때때로 유일한 해결책이지만 첫 번째이자 유일한 단계가되어서는 안됩니다. JavaScript는 이상한 언어 일 수 있으므로 일반적인 조언을하는 것은 일반적으로 불가능합니다. 항상 특정 상황을 평가하고 작업 솔루션을 파악해야합니다.

  단위 테스트 설정 단위 테스트를 통해 코드가 어떻게 작동하는지 이해하고 우연히 아무것도 깨뜨리지 않습니다. JavaScript 단위 테스트는 자체 기사의 가치가 있으므로 여기서는 자세히 설명 할 수 없습니다. 널리 사용되는 프레임 워크는 카르마, 자스민, 모카 또는 아바입니다. 사용자 인터페이스를 테스트하려면 Nightwatch.js 및 Dalekjs가 권장됩니다. 단위 테스트와 브라우저 자동화의 차이점은 전자가 JavaScript 코드 자체를 테스트한다는 것입니다. 의도 한대로 모든 모듈과 일반 논리 작업을 보장합니다. 반면에 브라우저 자동화는 프로젝트의 표면 (사용자 인터페이스)을 테스트하여 요소가 올바른 위치에 있고 예상대로 작동하는지 확인합니다. 다른 것을 리팩토링하기 전에 단위 테스트를 처리하십시오. 프로젝트의 안정성이 향상되며 확장성에 대해 생각조차하지 않았습니다! 위대한 부작용은 당신이 무언가를 깨고 눈치 채지 못했을 때 항상 걱정하지 않는 것입니다.

  Rebecca Murphey 기존 JavaScript에 대한 단위 테스트 작성에 대한 훌륭한 기사를 작성했습니다.

  아키텍처 JavaScript 아키텍처는 또 다른 큰 주제입니다. 리팩토링 및 청소는 아키텍처를 수행하는 데 얼마나 많은 경험이 있는지에 귀를 기울입니다. 우리는 소프트웨어 개발에서 다양한 설계 패턴을 가지고 있지만 확장 성이 관련된 곳에 적합하지는 않습니다. 불행히도 나는이 기사의 모든 사례를 다룰 수는 없지만 최소한 일반적인 조언을 줄 수 있습니다.

  우선, 프로젝트에서 이미 어떤 디자인 패턴이 사용되었는지 알아 내야합니다. 패턴에 대해 읽고 일관성을 확인하십시오. 확장 성의 열쇠 중 하나는 방법론을 혼합하지 않고 패턴을 고수하는 것입니다. 물론 프로젝트에서 다른 목적으로 다른 디자인 패턴을 가질 수 있습니다 (예 : 데이터 구조 또는 짧은 네임 스펙트 드 헬퍼 기능의 싱글 톤 패턴 사용 및 모듈의 관찰자 패턴). 하나의 패턴으로 하나의 모듈을 쓰지 않아야합니다. 하나는 다른 패턴을 가진 것입니다.

  프로젝트에 실제로 아키텍처가 없다면 (모든 것이 하나의 거대한 App.js에 불과 함) 이제 변경해야합니다. 한 번에 모두하지 말고 조각별로하지 마십시오. 다시 말하지만, 일을하는 일반적인 방법은 없으며 모든 프로젝트 설정이 다릅니다. 폴더 구조는 크기와 복잡성에 따라 프로젝트마다 다릅니다. 일반적으로 매우 기본적인 수준에서 구조는 모든 모듈과 논리가 초기화되는 타사 라이브러리, 모듈, 데이터 및 입력 지점 (예 : index.js, main.js)으로 나뉩니다. 이것은 나를 모듈화로 이끌어냅니다 모든 것을 모듈화합니까? 모듈화는 위대한 JavaScript 확장 성 질문에 대한 해답이 아닙니다. 개발자가 익숙해 져야 할 API의 다른 계층을 추가합니다. 그러나 이것은 번거 로움의 가치가 있습니다. 원칙은 모든 기능을 작은 모듈로 나누고 있습니다. 그렇게함으로써 코드의 문제를 해결하고 동일한 코드베이스에서 팀에서 일하는 것이 더 쉽습니다. 모든 모듈에는 정확히 하나의 목적과 작업이 있어야합니다. 모듈은 응용 프로그램의 외부 논리에 대해 알지 못하며 다른 위치와 상황에서 재사용 할 수 있습니다. 단단히 연결된 논리로 큰 기능을 어떻게 분할합니까? 함께합시다.

  이것은 그다지 모듈식이 아닙니다. 모든 것이 단단히 연결되어 있으며 다른 조각에 의존합니다. 더 크고 더 복잡한 기능으로 이것을 상상해보십시오. 무언가가 깨지기 때문에 이것을 디버깅해야 할 것입니다. 아마도 API가 응답하지 않고 JSON 내부에서 무언가가 바뀌었을 수도 있습니다. 악몽이 아닌가?

  다른 책임을 분리합시다 :
  알겠습니다. 이제 세 개의 새로운 모듈이 있습니다. Refactored Fetch Call을 보자

  우리는 또한 .then () 메소드 내부에서 논리를 가져 와서 분리 할 수 ​​있지만 모듈화가 의미하는 바를 보여 주었다고 생각합니다.

  . if! 모듈화 다른 것? 이미 언급했듯이 코드베이스를 작은 모듈로 돌리면 API의 다른 레이어가 추가됩니다. 원하지 않지만 다른 개발자가 코드를보다 쉽게 ​​작업 할 수있게하려면 기능을 더 크게 유지하는 것이 좋습니다. 코드를 더 간단한 부분으로 나누고 테스트 가능한 코드에 더 집중할 수 있습니다.

  코드를 문서화하십시오 문서화는 심각하게 논의 된 주제입니다. 프로그래밍 커뮤니티의 한 부분은 모든 것을 문서화하는 것을 옹호하는 반면, 다른 그룹은 자체 문서화 코드가 갈 길이라고 생각합니다. 인생의 대부분의 것들과 마찬가지로, 나는 두 가지의 균형이 잘되어 코드를 읽을 수 있고 확장 할 수 있다고 생각합니다. 문서에 jsdoc을 사용하십시오.

  JSDOC는 JavaScript 용 API 문서 생성기입니다. 일반적으로 잘 알려진 모든 편집자 및 IDE를위한 플러그인으로 제공됩니다. 예를 들어 봅시다 :
  이 함수는 두 개의 매개 변수를 사용하고 객체 위로 반복 한 다음 배열을 반환합니다. 이것은 지나치게 복잡한 방법은 아니지만 코드를 작성하지 않은 사람에게는 무슨 일이 일어나고 있는지 알아내는 데 시간이 걸릴 수 있습니다. 또한 방법이 무엇을하는지는 분명하지 않습니다. 문서화를 시작합시다 :

  나는 코드 자체의 많은 부분을 만지지 않았다. 기능을 바꾸고 짧지 만 상세한 댓글 블록을 추가하면 가독성을 향상 시켰습니다.

  정리 된 커밋 워크 플로 가 있습니다 리팩토링은 그 자체로 큰 임무입니다. 변경 사항을 항상 롤백 할 수 있으려면 (무언가를 깨고 나중에 알 수있는 경우) 모든 업데이트를 저지르는 것이 좋습니다. 메소드를 다시 작성 하시겠습니까? GIT 커밋 (또는 SVN과 함께 일하는 경우 SVN 커밋). 네임 스페이스, 폴더 또는 몇 개의 이미지로 이름이 바뀌 었습니까? git 커밋. 당신은 아이디어를 얻습니다. 일부 사람들은 지루할 수도 있지만 실제로 정리하고 정리하는 데 도움이됩니다.

  . 전체 리팩토링 노력을위한 새 지점을 만듭니다. 마스터에서 일하지 마십시오! 빠른 변경 또는 프로덕션 환경에 버그 수정을 업로드해야 할 수도 있으며 테스트 및 완료 될 때까지 (테스트되지 않은) 코드를 배포하고 싶지 않습니다. 따라서 항상 다른 지점에서 작업하는 것이 좋습니다.

  이 모든 것이 어떻게 작동하는지 짧은 업데이트가 필요한 경우 버전 제어 워크 플로우에 Github의 흥미로운 안내서가 있습니다. 당신의 마음을 잃지 않는 방법

  청소에 필요한 모든 기술 단계 외에도, 어느 곳에서나 언급하지 않는 중요한 단계가 있습니다. 이전 개발자에게 화를 내지 않습니다. 물론 이것은 모든 사람에게 적용되는 것은 아니지만 어떤 사람들은 이것을 경험한다는 것을 알고 있습니다. 이것을 정말로 이해하고 극복하는 데 몇 년이 걸렸습니다. 나는 이전 개발자 코드, 그들의 솔루션, 그리고 모든 것이 왜 그런지 엉망인 이유에 꽤 화를 냈다. 결국, 그 모든 부정성은 결코 나를 어디에도 없게 만들지 않았습니다. 그것은 단지 필요한 것보다 더 많은 리팩토링, 시간을 낭비하고 아마도 물건을 깨는 것입니다. 이것은 단지 당신을 점점 더 짜증나게 만듭니다. 당신은 여분의 시간을 보낼 수 있으며 이미 작동하는 모듈을 다시 작성해 주셔서 감사합니다. 그만한 가치가 없습니다. 필요한 것을 수행하고 상황을 분석하십시오. 모듈로 돌아갈 때마다 항상 작은 비트를 리팩터 할 수 있습니다.

  코드가 그 방식대로 작성되는 이유는 항상 있습니다. 아마도 이전 개발자는 제대로 할 시간이 충분하지 않았거나 더 잘 알지 못했거나 어쨌든 어쩌면 우리는 모두 거기에있었습니다.

  포장 다음 프로젝트의 체크리스트를 만들려면 모든 단계를 다시 살펴 보겠습니다.
  프로젝트를 분석하십시오
  개발자 모자를 잠시 버리고 그 모든 것이 무엇인지 알 수있는 사용자가 되십시오.

  코드베이스를 통과하여 사용중인 도구 목록을 작성하십시오.

  도구의 문서 및 모범 사례를 읽으십시오 단위 테스트를 거쳐 프로젝트에 대한 느낌을 더 높은 수준으로 얻으십시오.
  .
  기준을 만듭니다
  • 소개 .EditorConfig를 소개하여 코딩 스타일 안내서가 다른 IDE간에 일관되게 유지됩니다. 들여 쓰기를 일관성있게 만드십시오. 탭이나 공백은 중요하지 않습니다 명명 규칙을 시행합니다. 아직 존재하지 않으면 eslint, jslint 또는 jshint와 같은 라이터를 추가하십시오. 의존성을 업데이트하지만 현명하게 수행하고 정확히 업데이트 된 내용을 조심하십시오.
  • 청소
  Karma, Jasmine 또는 Nightwatch.js와 같은 도구로 단위 테스트 및 브라우저 자동화를 설정하십시오. 아키텍처와 디자인 패턴이 일관되어 있는지 확인하십시오 디자인 패턴을 혼합하지 말고 이미 거기에있는 패턴을 고수하십시오.
  • 코드베이스를 모듈로 분할 할 것인지 결정하십시오. 각각은 하나의 목적 만 가지고 있어야하며 나머지 코드베이스 로직을 알지 못합니다. 그렇게하고 싶지 않다면 테스트 가능한 코드에 더 집중하고 더 간단한 블록으로 분류하십시오. 기능과 코드를 적절하게 명명 된 함수로 균형 잡힌 방식으로 문서화하십시오. JSDOC를 사용하여 JavaScript에 대한 문서를 생성합니다 정기적으로 그리고 중요한 변경 후에 커밋하십시오. 무언가가 부러지면 돌아가는 것이 더 쉽습니다.
  마음을 잃지 마십시오.
  이전 개발자에게 화 내지 마십시오. 부정성은 불필요한 리팩토링과 시간을 낭비 할뿐입니다.
  코드가 그대로 작성된 이유가있었습니다. 우리 모두가 거기에 있다는 것을 명심하십시오.
  이 기사가 당신을 도왔기를 정말로 바랍니다. 당신이 어떤 단계에 어려움을 겪고 있는지 알려 주거나 언급하지 않은 좋은 조언이있을 수 있습니다! 관리 가능한 JavaScript 작성에 대한 자주 묻는 질문 (FAQ) 스파게티 코드 란 무엇이며 왜 피해야 하는가?
  스파게티 코드는 읽고 이해하고 유지하기가 어려운 복잡하고 얽힌 코드 웹을 설명하는 데 사용되는 용어입니다. 종종 계획 부족, 코딩 표준을 따르지 않거나 객체 지향 프로그래밍 원리를 사용하지 않는 것과 같은 열악한 프로그래밍 관행으로 인해 발생합니다. 이러한 유형의 코드는 추적하기 어려운 버그, 새로운 기능 추가의 어려움, 시간 및 유지 보수 비용 증가를 포함하여 수많은 문제로 이어질 수 있습니다. 따라서 스파게티 코드를 쓰지 않고 대신 청정하고 관리 가능한 코드를 위해 노력하는 것이 중요합니다.

  관리 가능한 JavaScript 코드를 어떻게 작성할 수 있습니까?

  관리 가능한 JavaScript 코드 작성에는 몇 가지 모범 사례가 포함됩니다. 먼저, 글쓰기를 시작하기 전에 항상 코드를 계획하십시오. 여기에는 해결하려는 문제를 이해하고 솔루션을 설계하는 것이 포함됩니다. 둘째, 코딩 표준 및 규칙을 따르십시오. 이로 인해 코드를 쉽게 읽고 이해할 수 있습니다. 셋째, 객체 지향 프로그래밍 원리를 사용하십시오. 이것은 코드를 구성하는 데 도움이되고 더 재사용 가능합니다. 마지막으로, 항상 코드를 문서화하십시오. 여기에는 코드가하는 일과 특정 결정을 내린 이유를 설명하기위한 의견을 작성하는 것이 포함됩니다.

  JavaScript 코드를 작성할 때 피해야 할 일반적인 함정은 무엇입니까?

  JavaScript 코드를 작성할 때 피할 수있는 일반적인 함정 '==='대신 '=='연산자를 사용하여 변수를 제대로 선언하지 않고 엄격한 모드를 사용하지 않고 오류를 올바르게 처리하지 않습니다. 이러한 함정을 피하면 청소기,보다 유지 관리 가능한 코드를 작성하는 데 도움이 될 수 있습니다.

  기존의 스파게티 코드를 관리 가능한 코드로 리팩토링하는 방법은 무엇입니까?

  스파게티 코드를 유지 관리 가능한 코드로 리팩토링하는 데 여러 단계가 포함됩니다. 먼저 기존 코드를 이해해야합니다. 여기에는 코드를 읽고 각 부분이하는 일을 문서화하는 것이 포함될 수 있습니다. 둘째, 개선 될 수있는 코드 영역을 식별하십시오. 이것은 반복되고 복잡한 조건부 논리 또는 이해하기 어려운 코드 섹션 일 수 있습니다. 셋째, 코드를 변경하십시오. 여기에는 복잡한 기능을 더 작고 관리하기 쉬운 기능으로 나누거나 중복 코드를 제거하거나 코드를 쉽게 이해할 수 있도록 코드 섹션을 다시 작성하는 것이 포함될 수 있습니다. 마지막으로, 변경 사항을 테스트하여 코드의 기능이 동일하게 유지되도록합니다.

  유지 관리 가능한 JavaScript 코드를 작성하는 데 도움이 될 수있는 도구는 무엇입니까?
  관리 가능한 JavaScript 코드를 작성하는 데 도움이되는 몇 가지 도구가 있습니다. 여기에는 코드 표준을 시행하고 코드의 잠재적 문제를 강조 할 수있는 eslint와 같은 라이터가 포함됩니다. Visual Studio Code와 같은 코드 편집기는 구문 강조 및 자동 완성과 같은 기능을 제공함으로써 도움이 될 수 있습니다. 또한 GIT와 같은 버전 제어 시스템은 코드 변경을 추적하고 다른 사람과 쉽게 협업 할 수 있도록 도와 줄 수 있습니다.

  객체 지향 프로그래밍이 유지 관리 가능한 코드를 작성하는 데 어떻게 도움이됩니까?

  OP (Object-Oriented Programming)는 유지 관리 가능한 코드를 작성하는 데 도움이되는 프로그래밍 패러다임입니다. 데이터와 기능을 모두 포함 할 수있는 객체로 코드를 구성 할 수 있습니다. 따라서 특정 작업을 수행 한 다음 코드 전체에서 사용할 수있는 객체를 작성할 수 있으므로 코드를보다 모듈화하고 재사용 할 수 있습니다. OOP는 또한 코드의 실제 개념을 모델링 할 수 있으므로 코드를 쉽게 이해할 수있게 해줍니다.

  JavaScript 코드를 유지하는 데 주석이 얼마나 중요한가?

  주석은 JavaScript 유지 관리에 중요합니다. 암호. 그것은 다른 개발자 (및 미래의 자아)가 코드가 무엇을하는지, 왜 특정 결정이 내려진지 이해하는 데 도움이됩니다. 이는 코드 기능을 이해하는 것이 어려울 수있는 복잡한 코드베이스에서 특히 중요합니다. 그러나 의견은 신중하게 사용되어야합니다. 과잉 연설은 코드를 혼란스럽고 읽기가 더 어려워 질 수 있습니다. 이상적으로, 귀하의 코드는 특정 결정이 이루어진 이유를 설명하거나 복잡한 코드 섹션을 명확하게 설명하기위한 의견을 제출하여 자체 설명이어야합니다.

  내 JavaScript 코드가 확장 가능하는지 확인하려면 어떻게해야합니까?
  JavaScript 코드는 확장 가능합니다. 증가 된 하중을 효율적으로 처리 할 수있는 방식으로 코드를 설계하는 것이 포함됩니다. 이는 효율적인 알고리즘 및 데이터 구조 사용, 글로벌 변수를 피하고 DOM 조작을 최소화하는 것과 같은 우수한 프로그래밍 관행에 따라 달성 할 수 있습니다. 또한 코드가 더 작고 재사용 가능한 조각으로 분해되는 코딩에 대한 모듈 식 접근 방식을 사용하여 확장 성을 향상시킬 수 있습니다.

  유지 관리 가능한 JavaScript 코드를 작성하는 데있어 테스트의 역할은 무엇입니까?

  테스트는 유지 관리 가능한 JavaScript 코드를 작성하는 데 중요한 역할을합니다. 코드가 예상대로 작동하고 개발 프로세스 초기에 버그를 잡을 수 있도록 도와줍니다. 단위 테스트, 통합 테스트 및 엔드 투 엔드 테스트를 포함하여 사용할 수있는 여러 유형의 테스트가 있습니다. 이러한 테스트 방법의 조합을 사용하면 코드가 강력하고 신뢰할 수 있는지 확인할 수 있습니다. 유지 관리 가능한 JavaScript 코드를 작성하기위한 최신 모범 사례를 유지하려면 어떻게해야합니까?

  관리 가능한 JavaScript 코드를 작성하기위한 최신 모범 사례를 유지하는 것은 업계 블로그를 정기적으로 읽고 웹 세미나 및 회의에 참석하여 달성 할 수 있습니다. 그리고 온라인 커뮤니티에 참여합니다. 또한, 지속적인 학습을 연습하고 코드를 정기적으로 검토하고 리팩토링하는 것도 최신 모범 사례를 최신 상태로 유지하는 데 도움이 될 수 있습니다.

위 내용은 풀링 스파게티 코드 : 관리 가능한 자바 스크립트 작성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!