2012-01-17 2 views
2

Coffeescript 코딩 스타일을 개선하고 싶습니다. 스칼라에서 프로그램을 작성할 때 한 두 시간 만에 모듈을 작성하고 실행할 수 있으며 신속하게 식별하여 수정할 수있는 몇 가지 사소한 버그가 있습니다.Coffeescript에서 생산성을 유지하는 방법?

Coffeescript에서 나는 똑같은 시간을 보냈지 만 정적 유형 검사기에 걸렸을 작은 버그가 엄청나게 많아지고 결국 컴파일하고 브라우저를 다시로드해야합니다. 일부 코드, 몇 가지 중단 점 추가 등이 있습니다. 이는 격렬한 경험이며 상당히 오래 걸립니다.

인터페이스가 부족하고 많은 OO 기능이 없어 기능을 추상화하고 캡슐화하는 것이 훨씬 어렵습니다.

OO에서 일반적으로 제공하는 캡슐화/추상화를 대체하는 디자인 패턴이 있습니까? 아니면 Coffeescript-y 방식으로 생각하는 방법에 대한 뇌관/가이드 (또는 프로토 타입 접근법을 사용하여 문제를 해결하는 방법)가 있습니까?

Coffeescript (또는 Javascript - 아마도 동적 유형의 언어까지)에서 생산성을 높이기 위해 무엇을 했습니까?

+0

대답은 아니지만 coffeescript로 생산하려면 실제로 자바에 익숙해야합니다. 그렇지 않다면 디버깅 경험은 실제로 고통 스러울 수 있습니다. –

+0

저는 Javascript와 Coffeescript에 모두 익숙합니다. 응용 프로그램 동작을 기반으로 버그를 식별 할 수 있으며 Javascript의 이상한 부분을 대부분 이해합니다. 정적 인 형식의 언어에서는 볼 수없는 실수/버그가 계속 발생합니다. 나는 특정 코딩 스타일을 채택하는 것이 도움이 될지 여부를 모르지만 (이는 유형을 명확하게 만들고 간단한 오타 및 유형 오류를 만들기가 더 어려워 짐) - 그러나 지금은 다른 사람이 이미 갖고있는 것이 아니라고 생각할 수 없습니다. 해결되었습니다. – laurencer

+0

동적 언어로 작업 할 때 자동화 된 테스트가 중요합니다. 좋은 테스트 슈트를 갖는 것은 어플리케이션에 잠재적으로 변경을 가할 때 에러를 잡는 데 매우 유용합니다. – Andrew

답변

7

자바 또는 스칼라와 같이 정적 유형의 클래스 중심 언어를 사용하는 경우 JavaScript/CoffeeScript를 배우는 것이 어려울 것입니다. 컴파일러는 거의 도움이되지 않습니다. 즉, 몇 초 만에 작은 실수를 발견하는 데 몇 분이 걸립니다.

이것이 주요 병목 현상이라면, 나는 더 많은 테스트 중심 코딩 방법론을 채택 할 것을 제안합니다. QUnit과 같은 라이브러리를 사용하여 개발하는 각 기능에 대해 작은 테스트를 작성하십시오. 이 스타일을 올바르게 사용하면 동적 언어의 유연성을 손상시키지 않고 정적 컴파일러와 동일한 이점을 얻을 수 있습니다.

+1

+1은 테스트 중심 방법론을 제안합니다. –

+0

슬프게도 많은 사람들이 자바 스크립트를 테스트하지는 않습니다. 왜냐하면 역사적으로 도구가 그리 좋지 않았기 때문입니다. 이제는 JavaScript를 쉽고 재미있게 테스트하는 QUnit 및 [Mocha] (http://visionmedia.github.io/mocha/)와 같은 훌륭한 도구가 있습니다. – Andrew

1

커피 스크립트로 직접 이동하지 마십시오. 프로토 타입과 Javascript OO에서 핵심 개념을 배웁니다. IMMO 동시에 배울 수 있지만 바닐라 자바 ​​스크립트를 처음으로 사용하면 더 많은 혜택을 얻을 수 있습니다. 제 개인적인 경험에 비추어 볼 때, 커피 스크립트의 구문 설탕은 클래스에 대한 함정이 될 수 있습니다. 프로토 타입 상속을 이해하지 못한다면 버그에 쉽게 걸릴 수 있습니다.

커피 스크립트 디버깅은 도구의 측면에서 여전히 완전히 해결되지 않은 문제입니다. 내가 할 수있는 유일한 방법은 테스트를 작성하는 것입니다 (방금 시작했을 때의 고통) 또는 생성 된 코드를 봅니다. 최소한의 애매한 버그는 최소한).

+0

다시 - 자바 스크립트와 프로토 타입 상속을 이해합니다 (그리고 저는 Coffeescript의 초보자가 아닙니다). 프로토 타이핑 언어로 문제에 접근하는 방법에 대한 툴 벨트가 없다 (고전적인 oo로 솔루션을 빠르게 구상 할 수있는 반면). 비슷하게 컴파일러 나 IDE가 일반적으로 잡는 간단한 실수를 저지르고 있습니다. 또는 형식 시그니처로 인해 명확 할 것입니다. 예를 들어, 형식을 함수 시그니처 (또는 표준을 문서화하는 방법)로 인코딩하는 표준/좋은 방법이 있습니까? – laurencer

1

나도 이상했다. 제 경우에는 C/C++ 배경에서 왔습니다.

나를 클릭하면 작업 환경을 약간 수정하면 반복 시간을 크게 줄일 수 있다는 것입니다. 작은 덩어리로 코드를 작성하고 코드를 매우 자주 테스트 할 수 있도록 충분히 줄이는 것이 아이디어입니다.

컴파일 시간 검사가 부족한 경우 : 익숙해 질 것입니다. 중요한 공백과 마찬가지로, 컴파일 타임 타입 검사의 부족은 몇 주 후에 사라집니다. 얼마나 정확하게 말하기는 어렵지만, 적어도 그것이 나를 위해 일어났다 고 말할 수 있습니다.

인터페이스가 부족한 경우 : 이것은 까다로운 부분입니다. 더 큰 시스템에서 좀 더 많은 도움을 받아서 전체 인터페이스를 구현하도록 상기시키는 것이 좋을 것입니다. 실제로 많은 시간을 낭비하고 있다는 것을 알고 있다면, 자신의 런타임 검사를 작성하여 적절한 곳에 삽입 할 수 있습니다. 예 : 중앙 관리자에게 객체를 등록하면 객체가 제출되는 역할에 적합한 지 확인하는 것이 좋습니다.

일반적으로 적절한 반성 능력이 있다는 것을 명심하는 것이 좋습니다.

캡슐화가 부족한 경우 : coffeescript가 프로토 타입 스키마에 아주 멋진 클래스 래퍼를 구현한다고 가정 할 때 개인 변수가 없다고 가정하고 있습니까? 당신이 필요성을 느낀다면 실제로 클라이언트의 세부 정보를 숨길 수있는 여러 가지 방법이 있습니다. 보통 내 발을 미래에 발사하지 말라. 열쇠는 보통 클로저에서 물건을 다람질하는 것입니다.

더보기 Object.__defineGetter__/Object.defineProperty? 게터와 세터는 이러한 상황에서 많은 도움이 될 수 있습니다.

것은 내가 변화에 대한 스크립트를 컴파일하는 커피의 파일 감시자 내장 사용되었다 : 반복 시간 단축에

. 포커스를 잃어 버린 모든 열린 파일을 저장하는 TextMate의 능력과 함께, 이것은 테스트가 텍스트 메이트에서 크롬/파이어 폭스로 바뀌고 새로 고침의 문제 였음을 의미합니다. 아주 빠릅니다.

node.js 프로젝트에서 필자는 뷰를 컴파일하고 즉석에서 제공하므로 파일 감시자도 불필요합니다. 그것들은 릴리즈시에 캐시되지만, 디버그 모드에서는 항상 디스크에서 다시로드되고, 재 컴파일되고, 에러가 발생하면 대신 제공합니다. 이제 몇 분마다 브라우저로 전환하고 새로 고침을하고 내 테스트가 실행되거나 컴파일러 오류가 표시됩니다.

관련 문제