ES6 cung cấp cho các nhà phát triển JavaScript nhiều cách hơn để làm mọi việc. Nhưng đó không phải lúc nào cũng là một điều tốt.


bởi Sam Williams

IidpNBFmiFlBVHE30vqFMcrtZPMTq16BtBpe

Gần đây tôi đã viết một bài báo về Mẹo và thủ thuật ES6 có hơn 17.000 lượt xem và 4.600 lượt vỗ tay. Một nhận xét từ Bob Munck đã nói rằng:

Bài báo này đưa ra một lập luận rất mạnh mẽ cho tránh JavaScript như bệnh dịch hạch trong bất kỳ cách sử dụng nào mà bạn muốn có độ tin cậy, khả năng bảo trì và khả năng sửa đổi lâu dài.

Ý kiến ​​​​của anh ấy dường như là nếu ngôn ngữ đang thay đổi nhiều như hiện tại, thì nó đang ký vào bản án tử hình của chính mình.

ES6, 7 và 8 đang thêm gì vào JavaScript

Các thông số kỹ thuật mới nhất bổ sung rất nhiều tính năng mới cho ngôn ngữ. Phá hủy, gán đối tượng ngắn gọn và các ký hiệu để đặt tên cho một số. Có một số điều tốt sắp xảy ra, nhưng bài viết này nhằm mục đích làm nổi bật các vấn đề.

Tại sao điều này là một vấn đề?

Bạn muốn tạo một hàm để nhận một đối tượng và thực hiện một số logic đối với nó. Đơn giản phải không? Nhưng bạn sẽ làm theo cách nào?

var data = { a: "print me" };
function method1(data) {    var a = data.a;    console.log(a);}
function method2(data) {    console.log(data.a);}
function method3({ a: info }) {    console.log(info);}
function method4({ a }) {    console.log(a);}

Tất cả các phương pháp này cung cấp cho bạn kết quả chính xác như nhau. Đây là một ví dụ rất tầm thường nhưng nó đúng với các hàm phức tạp hơn nhiều.

Làm thế nào để quyết định những gì để sử dụng?

Có 3 phương pháp chính để quyết định cách thực hiện việc này:

  • Đánh giá và so sánh các tùy chọn có sẵn.
  • Chỉ cần sử dụng bất cứ điều gì bạn muốn.
  • Có một chính sách về việc sử dụng ở đâu.

Mỗi cái đều có ưu và nhược điểm riêng.

VprwzhiI2Ve-XFhV-6YVbHMSEZhnIXk2wONE
Ảnh: pixabay.com

Đánh giá và so sánh các tùy chọn có sẵn

Điều này có vẻ như là một sự lựa chọn rõ ràng, nhưng nó có phải là lựa chọn tốt nhất không? Làm điều này mọi lúc có nghĩa là bạn phải đánh giá ưu điểm và nhược điểm của từng phương pháp MỖI LẦN bạn viết một hàm. Đó là rất nhiều sức mạnh tư duy có thể được sử dụng cho vấn đề mà bạn đang cố gắng giải quyết.

Bạn và những người bạn làm việc cùng cần biết những ưu điểm, nhược điểm và sắc thái của từng phương pháp. Điều này có vẻ không quá tệ, chỉ có 4, nhưng còn việc xử lý hành vi không đồng bộ thì sao? Bạn có sử dụng lệnh gọi lại, Lời hứa, Trình tạo hoặc Async/Await hoặc kết hợp chúng không?

Đọc thêm  Giá trị giả trong JavaScript

Điều này có nghĩa là mọi người mà bạn làm việc cùng cần phải hiểu từng chút ngôn ngữ. Tôi đoán theo số lượt xem bài viết về ES6 của mình thì nhiều người vẫn đang học một số cú pháp ngôn ngữ cơ bản hơn. Điều này có nghĩa là có rất ít người hiểu được sự phức tạp của hành vi không đồng bộ (điều mà bản thân tôi hiện đang cố gắng hiểu rõ).

Chỉ cần sử dụng bất cứ điều gì bạn muốn

Đây là cách tiếp cận phổ biến nhất, cho các cá nhân và trong các công ty. Điều này có thể rất tuyệt vì nó có nghĩa là bạn không lãng phí thời gian và công sức để tính toán lựa chọn tốt nhất.

Các vấn đề có thể phát sinh khi người khác đến đọc hoặc sửa mã của bạn. Bạn có thể là một đứa trẻ thích học JavaScript và biết tất cả các phương pháp mới nhất cho mọi thứ. Nhưng người tiếp theo đến đọc hoặc thay đổi tác phẩm của bạn có thể không biết bạn đã làm gì.

Điều này cũng khuyến khích sự khác biệt lớn về phong cách giữa các công ty và đồng nghiệp. Nó cũng có thể có nghĩa là sự khác biệt giữa bạn và bạn trong tương lai, khi bạn học một cú pháp mới. Điều này không tốt và làm cho việc đọc mã được viết bởi nhiều nhà phát triển trở nên khó khăn hơn nhiều.

34VI1AbwgDW-WSK49E5slOcsguRkTQ5yhrIx
Ảnh: pixabay.com

Chính sách

Cho dù đó là chính sách của công ty hay chính sách cá nhân, điều này giúp loại bỏ rất nhiều vấn đề với hai cách tiếp cận đầu tiên. Nó không yêu cầu suy nghĩ và thúc đẩy tính nhất quán trên cơ sở mã. Thật không may, nó vẫn còn một vài vấn đề.

Với các phiên bản mới của thông số kỹ thuật ECMAScript thường xuyên ra mắt, có một vấn đề nan giải. Công ty có nên thay đổi chính sách của mình để phù hợp với các bản phát hành mới nhất không? Hoặc viết một chính sách và không bao giờ thay đổi nó — bỏ lỡ các tính năng mới? Hay nó nên ở đâu đó ở giữa?

Nhân viên mới phải tìm hiểu chính sách và biết cách sử dụng nó. Có, bạn có thể có một cuốn sách nhỏ về các chính sách, nhưng có thể mất nhiều thời gian hơn để tìm thông số kỹ thuật hơn là viết dòng mã. Ngay cả khi họ tìm thấy chính sách về hành vi không đồng bộ, thì họ vẫn cần có thể sử dụng chính sách đó. Điều này cuối cùng có thể ngăn cản các nhà phát triển cơ sở mã hóa đơn giản vì họ không muốn phá vỡ chính sáchhạn chế ồ ạt sự phát triển của chúng.

ES6+ thực sự cung cấp những gì?

Sự khác biệt thực sự giữa các ví dụ tôi đưa ra ở trên là gì? Cú pháp mới có dễ đọc hơn hay chúng có cung cấp thêm chức năng nào không?

các đề xuất của họ phải {làm} với việc giảm số lần nhấn phím và thêm các thủ thuật “gọn gàng”.

Tôi thực sự không thể thấy nhiều, nếu có, lợi ích khi sử dụng cú pháp đối tượng ngắn gọn hoặc phá hủy ngoài việc lưu các lần nhấn phím. Có thể có những lợi ích về hiệu suất hoặc một số phép thuật đặc biệt mà tôi không biết hoặc không hiểu nhưng:

Đọc thêm  JavaScript 的 this 指向

Không có sự khác biệt hiệu suất nào quan trọng cả! — YDKJS

FYwgy4oQHlGhVRzaeoIsZS96Uh9xO-DY5MYF
ảnh: pixabay.com

Trích dẫn này là loại được đưa ra khỏi ngữ cảnh vì vậy tôi sẽ giải thích. Giả sử phương thức X chạy 1.000.000 thao tác/giây và phương thức Y chạy 500.000 thao tác/giây. Điều đó có nghĩa là X nhanh gấp đôi Y. Nhưng mà sự khác biệt về thời gian chạy chỉ là 1 micro giây. Điều này chậm hơn 100.000 lần so với những gì mắt người có thể cảm nhận được. Vì vậy, không có sự khác biệt hiệu suất nào cả!

Khoản tiết kiệm được bằng cách sử dụng các phương pháp khác nhau có thể sẽ nhỏ đến mức không thành vấn đề. Nếu bạn đang cố viết mã nhanh nhất có thể, tại sao bạn lại viết nó bằng JavaScript?

Những gì ES6 cũng cung cấp

Nhầm lẫn, phức tạp và tùy chọn.

GgQ1Bb9hQJ4YLtUmAEt8Cw6bS0mTzsQ5bkxR

Sau đó trong cuộc thảo luận với Bob, anh ấy đã nói điều này về JavaScript:

Bạn phải giải mã nó để hiểu những gì nó đang làm. Cú pháp và ngữ nghĩa của ngôn ngữ rất phức tạp, phức tạp, phức tạp. Các lập trình viên gỡ lỗi, bảo trì, nâng cao và sửa đổi mã của bạn vào ngày hôm sau hoặc một thập kỷ sau sẽ gặp khó khăn trong việc hiểu nó. Họ sẽ tự hỏi liệu điều bạn làm là cực kỳ thông minh hay cực kỳ ngu ngốc.

Điều này rất đúng với tôi. Tôi thấy mình đang xem lại đoạn mã mình đã viết, bối rối không biết mình đã làm gì và tại sao lại làm như vậy. Mặc dù bạn có thể viết mã phức tạp và khó hiểu bằng bất kỳ ngôn ngữ nào, nhưng JavaScript mang đến cho bạn nhiều cơ hội để vượt qua chính mình.

Tôi đã làm điều này với bản thân mình trong bài viết ES6. Trong 4.000 người đọc toàn bộ bài báo, chỉ có 5 người tìm ra lỗi của tôi trước khi tôi sửa nó. Cái nào trong số này là chính xác?

let person = {     name: "John",     age: 36,     job: { company: "Tesco", role: "Store Assistant"}}
function methodA({ name: driverName, age, job.company: company}){ ... }
function methodB({ name: driverName, age, job: { company }){ ... }

Tôi đã sử dụng sai và hầu hết mọi người không nhận thấy. Chỉ một số ít đã dùng thử mới tìm được lỗi.

rHzev1lGqapGQbzpEBx3HxLckNRfdTJOabk2

Hai phương pháp này thực sự cung cấp điều gì để biện minh cho sự nhầm lẫn và phức tạp thêm? Nhiều người có thể đọc, viết và hiểu một chức năng như thế này:

function methodC(person){    var driverName = person.name,        age = person.age,        company = person.job.company;    ...}

Có, tôi đã phải viết thêm 32 ký tự, nhưng vì hầu hết lập trình là suy nghĩ chứ không phải gõ, liệu chúng ta có đang tiết kiệm thời gian gõ chỉ để dành nhiều thời gian hơn cho việc suy nghĩ không?

Đọc thêm  Ép buộc và chuyển đổi loại trong JavaScript – Giải thích bằng các ví dụ về mã

Đó không chỉ là thời gian bổ sung mà tác giả dành để suy nghĩ về nó, mà còn là mọi người đọc đoạn mã đó sau thời điểm đó (thường là tác giả một lần nữa). Mã phức tạp có “thuế tư duy” mỗi khi nó được đọc và chúng ta, với tư cách là con người, chỉ có một nguồn cung cấp năng lực tư duy hạn chế mỗi ngày.

Không phải tất cả đều xấu

Mặc dù bài viết này dường như đề cập đến ES6, nhưng có một số điều giúp tăng khả năng đọc và khả năng bảo trì. Các lời hứa, hàm async và async/await đều giúp trừu tượng hóa sự phức tạp của hành vi không đồng bộ, làm cho mã logic hơn và dễ đọc hơn. Đây là những gì tôi tin rằng nên được tập trung vào, không phải thủ thuật tiết kiệm tổ hợp phím.

Ảnh hưởng lâu dài

Mặc dù điều này có thể sẽ không tạo ra bất kỳ sự khác biệt nào đối với bạn với tư cách là nhà phát triển, nhưng các công ty có nhiều nhà phát triển có thể cảm thấy tác động. Trước tiên, phải hiểu cú pháp đang làm gì trước khi hiểu mã đang làm gì dẫn đến mã không đáng tin cậy và không thể bảo trì.

Điều này có thể dẫn đến việc JavaScript không được ưu tiên cho bất kỳ thứ gì lớn, phức tạp, quan trọng hoặc đang phát triển. Đây sẽ là một thị trường khổng lồ để JavaScript bỏ lỡ.

Tóm lược

  • ES6 thậm chí còn cung cấp cho chúng tôi nhiều cách hơn để thực hiện cùng một tác vụ.
  • Bạn có thể tính toán những gì là tốt nhất, làm những gì bạn muốn hoặc có chính sách về nó.
  • ES6 cung cấp cho chúng tôi các thủ thuật mới để tiết kiệm một số lần nhấn phím.
  • Những thủ thuật mới này làm tăng độ phức tạp và khả năng xảy ra lỗi đồng thời làm giảm khả năng đọc.
  • Có một số bit tốt của ES6, tăng khả năng đọc.
  • Liệu độ phức tạp tăng lên và khả năng đọc giảm đi có thể khiến các công ty ít có khả năng sử dụng nó hơn trong các giải pháp phức tạp, quan trọng hoặc liên tục phát triển không?

Bạn nghĩ sao? Hãy cho tôi biết ở phần bình luận. Nếu bạn thích nó, hãy vỗ tay và theo dõi tôi để biết thêm các bài viết về JavaScript.

IlmT2dhqkBmqwHaLmF17l7Qm4pAqBmOnz-9c



Zik.vn – Biên dịch & Biên soạn Lại

spot_img

Create a website from scratch

Just drag and drop elements in a page to get started with Newspaper Theme.

Buy Now ⟶

Bài viết liên quang

DMCA.com Protection Status