최근에 좋고 좋지는 않지만 대부분 추악한 Java를 통해 트러 깅하고 있으며 Java 및 Java 개발자와 JS 및 Java 개발자에 대한 총체적 과잉 총 생성이 발생 하면서이 질문에 대한 답변을 추가하고 싶습니다. 실제로 유용한 진실과 모호한 무언가에 기반을 둔 JS 개발자.
IDE가 있지만 많은 사람이없는 이유를 이해하는 것이 도움이 될 수 있습니다
나는 노드 개발에 관심이 있다는 사실을 알게되어 Webstorm을 시도해 왔으며 실제로 그것을 구입 한 것은 나쁘지 않지만 여전히 WS보다 자주 Scite에서 js 파일을 여는 경향이 있습니다. 그 이유는 JS에서 훨씬 적은 양으로 더 많은 일을 할 수 있지만 UI 작업은 즉각적인 피드백을 제공하기 때문에 브라우저 개발 도구 (특히 Chrome 및 Firebug)는 실제로 매우 뛰어나고 (브라우저가 아닌 컨텍스트를 고려함) ) 변경된 코드를 재실행하면 컴파일 단계없이 빠르고 쉽게 수행 할 수 있습니다.
내가 상당히 확신하는 또 다른 것은 IDE가 기본적으로 JavaScript에서 감당할 수없는 조잡한 코드를 활성화하여 자체 요구를 생성한다는 것입니다. JS에서 어떻게 관리하는지 배우고 싶습니까? IDE없이 Java로 사소한 것을 작성하여 시작하는 것이 도움이 될 수 있으며 IDE 이동없이 해당 코드를 실제로 유지 관리 / 수정하려면 실제로 시작하고 생각 해야하는 것들에주의를 기울이십시오. 앞으로. IMO는 IDE가 있든 없든 유지 관리 가능한 코드를 작성하는 데 여전히 똑같은 것들이 중요합니다. 4 년짜리 프로그래밍 커리큘럼을 작성해야한다면 툴과 종속성을 왜곡시키지 않기 위해 처음 2 년 동안 IDE를 만질 수 없었습니다.
구조
복잡한 응용 프로그램을 다루는 숙련 된 JS 개발자는 코드를 구조화 할 수 있습니다. 실제로 우리를 위해 코드를 읽을 IDE가 부족한 초기 역사에서 더 나은 경향이 있지만, 표현력이 뛰어난 언어는 신중하게 코드를 작성하지 않으면 유지 관리 할 수없는 재난 코드베이스를 매우 빠르게 강력하게 표현할 수 있기 때문입니다.
실제로 Java 코드베이스를 이해하는 데 실제로 상당히 가파른 학습 곡선을 보았습니다. 마지막으로 적절한 OOP가 없다는 것을 깨달았습니다. 클래스는 콩이나 DTO 또는 정적 게터 / 세터에 앉아있는 전역 적으로 사용 가능한 데이터를 변경하는 느슨하게 관련된 메서드 묶음에 지나지 않습니다. 기본적으로 OOP가 대체해야했던 것과 같은 오래된 짐승입니다. 그래서 기본적으로 코드를 찾고 생각하는 것을 중단했습니다. 방금 바로 가기 키를 배우고 혼란을 추적했으며 모든 것이 훨씬 순조롭게 진행되었습니다. 따라서 이미 습관이 없다면 OOD에 대해 훨씬 더 열심히 생각하십시오.
최상위 수준의 잘 구성된 JS 앱은 복잡한 기능 (예 : jQuery)과 서로 상호 작용하는 객체로 구성되는 경향이 있습니다. 어떤 언어로든 잘 구조화되고 쉽게 유지 관리되는 앱의 마크는 IDE 또는 메모장 ++로 볼 때 완벽하게 읽을 수 있다는 것입니다. 이것이 의존성 주입과 테스트 우선 TDD를 극도로 중요하게 여기는 주요 이유 중 하나입니다.
그리고 마지막으로 수업을 시작하십시오. 프로토 타입 상속을 배우십시오. 실제로 상속이 필요할 때 구현하기가 실제로 매우 우아합니다. 나는 JS에서 합성 접근법이 훨씬 더 잘 작동하는 경향이 있음을 발견하고 개인적으로 병이 나기 시작하고 어떤 언어로든 1-2 단계 이상의 상속이있을 때마다 EXTJS 야간 테러가 발생합니다.
핵심 원칙
DRY, YAGNI, 가장 놀랍게도의 원칙, 문제 영역의 깔끔한 분리, 인터페이스에 쓰기 및 사람이 읽을 수있는 코드 작성이 필자의 개인적 핵심입니다. 이러한 관행의 포기를 옹호하는 좀 더 복잡한 것은 어떤 언어로도 Kool Aid, 특히 다음 사람을 위해 매우 혼란스러운 코드를 남길 수있는 JavaScript와 같은 언어로 간주해야합니다. 예를 들어, 느슨한 커플 링은 객체 간 상호 작용이 발생하는 곳을 알 수 없을 때까지 사용할 수 있습니다.
동적 타이핑을 두려워하지 마십시오
JavaScript에는 많은 핵심 유형이 없습니다. 대부분의 경우 동적 캐스팅 규칙은 실용적이고 간단하지만 규칙을 배우는 데 비용이 들기 때문에 불필요한 캐스팅과 무의미한 유효성 검사 루틴없이 데이터 흐름을 관리하는 방법을 더 잘 배울 수 있습니다. 날 믿어. 엄격한 유형은 성능 및 컴파일 문제를 발견하는 데 유용하지만 어떤 것도 보호하지 못합니다.
JS 함수와 클로저에서 크랩을 배우십시오
JS의 일류 기능은 아마도 JS가 "고객 상 웹에 상을 건 드리는 언어 만 상"을 수상한 주된 이유 일 것입니다. 그렇습니다. 실제로 경쟁이있었습니다. 또한 JS의 핵심 기능입니다. 우리는 그들과 함께 물건을 만듭니다. 모든 것은 기능 범위입니다. 그리고 그들은 편리한 기능을 가지고 있습니다. arguments 키워드를 통해 params를 검사 할 수 있습니다. 다른 객체의 메소드라는 맥락에서 일시적으로 첨부하고 해고 할 수 있습니다. 또한 외설적으로 구현하기 쉬운 이벤트 중심 접근 방식을 만듭니다. 요컨대, JS는 복잡성을 줄이고 소스 자체에서 JS 자체 (대부분 DOM API)의 다양한 구현을 적응시키는 데있어 절대적인 짐승이되었습니다.
채택하기 전에 패턴 / 연습 재평가
퍼스트 클래스 함수와 동적 타입은 더 복잡한 디자인 패턴을 JS에서 완전히 무의미하고 번거롭게 만듭니다. 그러나 간단한 패턴 중 일부는 JS의 매우 유연한 특성으로 인해 매우 유용하고 구현하기 쉽습니다. 어댑터와 데코레이터가 특히 유용하며 단일 UI가 빌드하는 ui 요소의 이벤트 관리자 역할을하는 복잡한 UI 위젯 팩토리에 유용합니다.
언어의 리드를 따르고 적은 비용으로 더 많은 것을하십시오
Java 헤드 혼초 중 하나가 상세가 실제로 모든 당사자가 코드를 이해하기 쉽게 만드는 긍정적 인 기능이라는 주장을했다고 생각합니다. 호그 워시. 그것이 사실이라면, 합법적 인 사람들은 읽기가 더 쉬울 것입니다. 작가 만이 자신이 작성한 것을 이해하기 쉽게 만들 수 있으며 때로는 다른 사람의 신발에 자신을 넣어야 만 할 수 있습니다. 따라서이 두 규칙을 받아들이십시오. 1. 가능한 한 직접적이고 명확해야합니다. 2. 이미 망할 지점으로 가십시오. 승리는 깨끗하고 간결한 코드가 트리거에서 실제 원하는 동작으로 이동하기 위해 25 개의 레이어를 통과해야하는 것보다 이해하고 유지하기가 훨씬 쉽다는 것입니다. 더 엄격한 언어로 이런 종류의 것을 옹호하는 대부분의 패턴은 실제로 JavaScript에없는 제한 사항에 대한 해결 방법입니다.
모든 것은 가단성이며 괜찮습니다
JS는 아마도 가장 많이 사용되는 보호주의 언어 중 하나 일 것입니다. 받아 들여 잘 작동합니다. 예를 들어 생성자 함수에서 일반 vars를 선언하여 액세스 할 수없는 영구 "private"vars로 객체를 작성할 수 있으며이 작업을 자주 수행합니다. 그러나 내 코드 또는 코드 사용자를 "자신으로부터"보호하지는 않습니다 (어쨌든 런타임 중에 자체 버전으로 바꿀 수 있습니다). 그러나 다른 사람이 의존성을 얽매이지 않기에 충분히 유능하고 당신이 아마 좋은 이유 때문에 직접 그것을 얻을 수 없다는 것을 알기 때문에 오히려 의도를 신호하는 것입니다.
크기 제한이없고 문제 도메인 만 있음
내가 본 모든 Java 코드베이스에서 가장 큰 문제는 클래스 파일이 너무 많다는 것입니다. 우선 SOLID는 OOP에 대해 이미 알아야 할 사항에 대한 혼란스러운 반복입니다. 클래스는 특정 일련의 관련 문제를 처리해야합니다. 하나의 방법으로 하나의 문제가 아닙니다. 그것은 부팅 할 모든 무의미한 클래스 구문을 추가해야만 나쁜 오래된 체인화 func-spaghetti C 코드 만 사용합니다. 크기 나 방법 제한이 없습니다. 이미 긴 함수 나 클래스 또는 생성자에 무언가를 추가하는 것이 이치에 맞습니다. jQuery를 사용하십시오. 단일 함수의 전체 라이브러리 길이 도구 세트이며 아무런 문제가 없습니다. 여전히 jQuery가 필요한지 여부는 합리적인 논쟁이지만 디자인 측면에서
Java가 모두 알고 있다면, C 기반이 아닌 구문을 사용하여 무언가 문제가 발생합니다
Django에 대해 듣고있는 것을 좋아해서 Python을 망치기 시작했을 때 언어 디자인에서 구문을 분리하는 것을 시작했습니다. 결과적으로 Java와 C를 동일한 구문으로 다르게 수행하는 것이 아니라 언어 설계 부분의 합계로 이해하기가 쉬워졌습니다. 좋은 부작용은 디자인 측면에서 다른 언어를 더 많이 이해할수록 대비를 통해 가장 잘 알고있는 언어의 장단점을 더 잘 이해할 수 있다는 것입니다.
결론
이제 모든 것을 고려하여 모든 문제를 해결하십시오.
- 함수의 진입 점을 즉시 찾을 수있는 방법이 없습니다 (일반 텍스트 검색 이외의 경우, 2 개 또는 3 개의 시작 위치를 잊어 버린 후 호출 계층을 추가로 메소드에 대한 후속 검색으로 이어질 수 있음)
Chrome과 Firebug에는 실제로 통화 추적 기능이 있습니다. 그러나 구조에 대한 나의 요점과 간결하고 직접적인 것을 유지하십시오. 서로 상호 작용하는 잘 캡슐화 된 더 큰 구조로 앱을 더 많이 생각할수록 문제가 발생했을 때 누구의 잘못인지 쉽게 파악할 수 있습니다. 나는 이것이 Java의 경우에도 마찬가지라고 말하고 싶습니다. 우리는 전통적인 OOP 문제에 대해 완벽하게 서비스 할 수있는 클래스 유사 함수 생성자를 가지고 있습니다.
function ObjectConstructor(){
//No need for an init method.
//Just pass in params and do stuff inside for instantiation behavior
var privateAndPersistent = true;
//I like to take advantage of function hoisting for a nice concise interface listing
this.publicAndPointlessEncapsulationMurderingGetterSetter
= publicAndPointlessEncapsulationMurderingGetterSetter;
//Seriously though Java/C# folks, stop with the pointless getter/setters already
function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
if(arg === undefined){
return privateAndPersistent;
}
privateAndPersistent = arg;
}
}
ObjectConstructor.staticLikeNonInstanceProperty = true;
var instance = new ObjectConstructor();//Convention is to capitalize constructors
내 코드에서는 객체 리터럴 {}을 구조적 응용 프로그램 구성 요소로 사용 하지 않습니다. 내부 (비공개) 변수를 가질 수 없으므로 대신 데이터 구조로 사용하기 위해 예약하는 것을 선호하기 때문입니다. 이는 의도의 명확성을 유지하는 기대치를 설정하는 데 도움이됩니다. (컬리가 보이면 앱 아키텍처의 구성 요소가 아닌 데이터입니다).
- 매개 변수는 실제로 프로그램을 실행하고 함수가 호출 된 지점으로 이동하고 console.logs를 사용하여 모든 특성을 출력하는 것을 제외하고 해당 매개 변수에서 사용 가능한 특성 및 함수를 알 수있는 방법없이 함수에 전달됩니다. 유효한)
다시 현대 브라우저 도구를 참조하십시오. 또한 프로그램을 다시 실행하는 것이 왜 그렇게 번거로운가? 재로드는 클라이언트 측 웹 개발자가 일반적으로 몇 분마다 수행하는 것입니다. 이것은 앱 구조가 도움이 될 수있는 또 다른 요점이지만 계약을 시행 할 때 자체 유효성 검사를 실행해야하는 JS의 단점 중 하나입니다 (내 코드베이스가 수행하는 다른 일에 노출 된 엔드 포인트에서만 할 수있는 일). 제어하지 않음). IMO, 트레이드 오프는 그만한 가치가 있습니다.
- 익명 함수를 콜백으로 자주 사용하므로 혼동되는 코드 경로 스파게티가 생겨 빠르게 탐색 할 수 없습니다.
네, 사소한 일에는 좋지 않습니다. 하지마 당신의 기능을 아이 이름을 지정하십시오. 물건을 추적하는 것이 더 쉽습니다. 다음과 같이 간단한 사소한 기능을 정의, 평가 (할당해야 함) 및 할당 할 수 있습니다.
doSomethingWithCallback( (function callBack(){}) );
이제 통화를 추적 할 때 Chrome에 이름이 지정됩니다. 사소한 기능의 경우 호출 외부에서 정의합니다. 또한 변수에 지정된 익명 함수는 여전히 익명입니다.
- 그리고 JSLint는 런타임 전에 약간의 오류를 포착하지만 브라우저에서 직접 코드 아래에 빨간색 물결 모양의 선을 갖는 것만 큼 편리하지는 않습니다.
나는 물건을 만지지 마십시오. Crockford는 커뮤니티에 좋은 것들을 제공했지만 JSLint는 선을 문체 선호도에 넘기고 JavaScript의 특정 요소는 특별한 이유가 없기 때문에 나쁜 부분이라고 제안합니다. IMO. regEx 및 부정 클래스 뒤에 * 또는 +가 있다는 것을 분명히 무시하십시오. 와일드 카드의 성능이 저하되고 {}을 사용하여 반복을 쉽게 제한 할 수 있습니다. 또한 함수 생성자에 대해 언급 한 내용은 무시하십시오. 새로운 키워드가 귀찮 으면 공장 기능으로 쉽게 포장 할 수 있습니다. Crockford가 아닌 CSSLint는 나쁜 조언에있어 훨씬 더 나쁩니다. 항상 소금 한알로 말을 많이하는 사람들을 데려가십시오. 때때로 나는 그들이 권위를 확립하거나 새로운 재료를 생성하려고한다고 맹세합니다.
그리고 다시, 당신은 당신이 가지고있는이 런타임 문제로 배운 것을 배우지 않아야합니다. (많은 Java / C # 개발자들에게 보인 흔한 일입니다.) 런타임에서 오류가 2 년 후에도 계속 귀찮게된다면, 브라우저에 스팸이 다시로드되어 침입 할 때까지 기다리십시오. 컴파일 타임 / 런타임 분할이 아닙니다 (아직 눈에 띄는 것은 아닙니다-JS는 지금 JIT에서 실행됩니다). 런타임에 버그를 발견하는 것은 괜찮을뿐만 아니라, 저렴하고 쉽게 스팸을 다시로드하고 도착하는 모든 중지 지점에서 버그를 발견하는 데 큰 도움이됩니다.
그리고 Chrome 개발 도구를 사용하십시오. 웹킷에 직접 내장되어 있습니다. Chrome에서 마우스 오른쪽 버튼을 클릭하십시오. 요소를 점검하다. 탭을 탐색하십시오. 런타임 중에 콘솔에서 코드를 변경하는 기능과 함께 많은 디버그 성능이 가장 강력하지만 덜 분명한 옵션 중 하나입니다. 테스트에도 좋습니다.
관련 메모에서 오류는 친구입니다. 빈 캐치 문을 작성하지 마십시오. JS에서는 오류를 숨기거나 묻지 않습니다 (또는 최소한 YUI / cough 기침 해서는 안됩니다 ). 우리는 그들에게 참석합니다. 적은 것은 디버그 고통을 초래할 것입니다. 그리고 프로덕션에서 잠재적 오류를 숨기기 위해 catch 문을 작성하면 최소한 자동으로 오류를 기록하고 로그에 액세스하는 방법을 문서화하십시오.