Chúng tôi có một cơ sở mã JavaScript khá lớn và khoảng một tháng trước, chúng tôi đã muốn dùng thử CoffeeScript. Một trong những nhà phát triển của chúng tôi đã bắt đầu với việc di chuyển một trong các mô-đun của chúng tôi từ JS sang CS bằng cách sử dụng http://js2coffee.org/ . Công cụ này khá tiện dụng và mất khoảng hai hoặc ba giờ để chuyển một dòng JavaScript 1000 thứ. Một số quan sát chúng tôi nhận thấy ở điểm đó:
Mã CoffeeScript kết quả là khá dễ đọc.
Chúng tôi đã biên dịch nó trở lại JavaScript và khá dễ dàng để điều hướng và gỡ lỗi. Trong khi chúng tôi chuyển mô-đun đó, một nhà phát triển khác trong nhóm của chúng tôi đã tìm thấy một lỗi trong đó. Hai nhà phát triển đã sửa lỗi đó trong mã JavaScript cũ của chúng tôi và mã JavaScript mới xuất phát từ trình biên dịch CS. Họ làm việc độc lập và họ mất khoảng thời gian như nhau (15-20 phút).
Do thực tế đó là một cổng, mã kết quả không sử dụng các tính năng dành riêng cho Cà phê phù hợp hoặc mong muốn. Nếu chúng ta viết bằng CoffeeScript từ đầu thì mã sẽ thành ngữ hơn. Vì điều đó sau đó chúng tôi đã quyết định rằng chúng tôi sẽ không chuyển mã hiện có.
Nói chung khả năng đọc của hàm ngắn hơn và đối tượng nhỏ hơn tăng lên một số mở rộng. Tuy nhiên, đối với các phương pháp dài hơn đó không phải là trường hợp. Khoản tiết kiệm lớn nhất đến từ ->và rõ ràng return, nhưng khác với mã của chúng tôi đã rút ngắn hơn hoặc đơn giản hơn đáng kể. Một số phần cú pháp có vẻ khá khó hiểu, đặc biệt là các đối tượng bằng chữ. CS bỏ qua các dấu ngoặc nhọn xung quanh các định nghĩa thành viên và kết hợp với "mọi thứ là một biểu thức" và ẩn returnkhiến cho một số đoạn mã khá khó đọc.
Đây là JavaScript:
var rabbitGenerator = {
makeRabbit: function(rabbitName, growCarrots) {
if (growCarrots) {
carrots.growMore(10);
} else {
carrots.ensureSupply();
}
return {
name: rabbitName,
height: 0,
actions: {
jump: function (height) {
this.height += height;
},
eatCarrot: function () {
// etc
}
}
};
},
// more members
}
Và đây là mã CoffeeScript tương ứng trông như thế nào:
rabbitGenerator =
makeRabbit: (rabbitName, growCarrots) ->
if growCarrots
carrots.growMore 10
else
carrots.ensureSupply()
name: rabbitName // (*)
height: 0
actions:
jump: (height) ->
@height += height
eatCarrot: ->
Vì hiện tại khá khó để nhận ra rằng câu lệnh return bắt đầu tại (*)dòng. Trong dự án của chúng tôi, chúng tôi chủ yếu dựa vào nghĩa đen của đối tượng: chúng tôi chuyển chúng dưới dạng tham số hàm và trả về chúng từ các hàm khác. Trong nhiều trường hợp, các đối tượng này có xu hướng khá phức tạp: với các thành viên thuộc các loại khác nhau và một số cấp độ lồng nhau. Trong trường hợp của chúng tôi, cảm giác chung là mã CoffeeScript thực sự khó đọc hơn mã JavaScript đơn giản.
Mặc dù việc gỡ lỗi CoffeeScript hóa ra dễ dàng hơn chúng tôi dự kiến, trải nghiệm chỉnh sửa đã xuống cấp khá nhiều. Chúng tôi không thể tìm thấy một trình soạn thảo / IDE tốt cho ngôn ngữ này. Chúng tôi chưa chuẩn hóa trình soạn thảo / IDE cho mã phía máy khách cho dự án của chúng tôi và trên thực tế tất cả chúng tôi đều sử dụng các công cụ khác nhau. Trên thực tế, mọi người trong một nhóm đều đồng ý rằng khi họ chuyển sang CoffeeScript, họ nhận được sự hỗ trợ khá kém từ công cụ của họ. Các plugin IDE và trình soạn thảo có hình dạng rất sớm và trong một số trường hợp, chúng thậm chí không thể cung cấp cho chúng tôi một cú pháp tô sáng hoặc hỗ trợ thụt lề thích hợp. Không nói về đoạn mã hoặc tái cấu trúc. Chúng tôi sử dụng WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ và SublimeText2.
Nói về các công cụ tôi nên đề cập rằng chính trình biên dịch CoffeScript đi kèm như một gói Node JS. Chúng tôi là một cửa hàng Java / .NET chính vì vậy mọi người đang phát triển trên các hộp Windows. Cho đến gần đây, hỗ trợ Windows gần như không tồn tại trong Node. Chúng tôi không thể làm cho trình biên dịch CoffeeScript chạy trên Windows vì vậy trong thời gian này, chúng tôi đã quyết định gắn bó với <script type="text/coffeescript">các thẻ và trình biên dịch dựa trên trình duyệt.
Trình biên dịch khá nhanh và không làm tăng thời gian khởi động nhiều. Nhược điểm là JavaScript kết quả bị lỗi evalvà hơi khó để đặt các điểm dừng trong nó trong các công cụ dành cho nhà phát triển của trình duyệt (đặc biệt là trong IE8). Nếu chúng tôi gặp khó khăn với việc gỡ lỗi, chúng tôi sẽ biên dịch trước mã CoffeeScript bằng cùng một công cụ di chuyển mà tôi đã liệt kê ở trên nhưng điều đó vẫn không thuận tiện lắm.
Những lời hứa khác của CoffeeScript như varchèn tự động hoặc quản lý bán trong suốt thisvới toán tử mũi tên béo ( =>) hóa ra không mang lại nhiều lợi ích như chúng tôi mong muốn. Chúng tôi đã sử dụng JSLint như một phần của quy trình xây dựng của mình và chúng tôi viết mã trong ES3 x ES5-Stricttập hợp con của ngôn ngữ. Dù sao, việc Cà phê sản xuất cùng loại mã "sạch" là một điều tốt . Tôi cũng mong muốn mọi khung công tác phía máy chủ cũng tạo ra đánh dấu HTML5 và CSS3 hợp lệ!
Điều đó nói rằng tôi sẽ không nói rằng CoffeeScript tiết kiệm rất nhiều thời gian bằng cách đặt vartừ khóa cho tôi. Các lỗi bị mất vardễ dàng bị bắt bởi JSLint và có thể dễ dàng sửa chữa. Hơn nữa, một khi bạn đã sửa nó một thời gian, bạn sẽ bắt đầu viết JavaScript tốt tự động. Vì vậy, tôi sẽ không nói Cà phê thực sự là có ích trong vấn đề này.
Chúng tôi đã đánh giá CoffeeScript trong khoảng một tuần. Tất cả các thành viên trong nhóm đã viết mã trong đó và chúng tôi chia sẻ kinh nghiệm của chúng tôi với nhau. Chúng tôi đã viết một số mã mới với nó và chuyển một số mã hiện có khi chúng tôi thấy phù hợp. Cảm xúc của chúng tôi về ngôn ngữ đã được trộn lẫn.
Nói chung tôi sẽ nói rằng nó không thúc đẩy sự phát triển của chúng tôi nhưng nó cũng không làm chúng tôi chậm lại. Một số mức tăng tốc độ do gõ ít hơn và bề mặt lỗi ít hơn đã được bù đắp bằng sự chậm lại ở các khu vực khác, chủ yếu là hỗ trợ công cụ. Sau một tuần, chúng tôi đã quyết định rằng chúng tôi sẽ không bắt buộc sử dụng CoffeeScript nhưng chúng tôi cũng sẽ không cấm . Đưa ra một sự lựa chọn miễn phí, trong thực tế không ai sử dụng nó, ít nhất là cho đến bây giờ. Thỉnh thoảng tôi nghĩ đến việc tạo mẫu một số tính năng mới trong đó và sau đó chuyển đổi mã thành JavaScript trước khi tích hợp với phần còn lại của dự án để bắt đầu nhanh hơn nhưng tôi chưa thử cách tiếp cận đó.