Hôm nọ, tôi đã phỏng vấn một nhà phát triển JavaScript đang ứng tuyển vào vị trí cấp cao. Một đồng nghiệp cũng có mặt tại cuộc phỏng vấn đã yêu cầu ứng viên viết một hàm thực hiện yêu cầu HTTP và nếu không thành công, hãy thử lại nhiều lần.
Anh ấy viết mã trực tiếp lên bảng, vì vậy chỉ cần vẽ một cái gì đó gần đúng là đủ. Nếu anh ấy chỉ đơn giản thể hiện rằng anh ấy hiểu rõ vấn đề là gì thì chúng tôi đã khá hài lòng. Nhưng thật không may, anh đã không thể tìm ra giải pháp thành công. Sau đó, chúng tôi phấn khích và quyết định thực hiện nhiệm vụ dễ dàng hơn một chút và yêu cầu anh ấy biến một chức năng có lệnh gọi lại thành một chức năng được xây dựng dựa trên lời hứa.
Nhưng than ôi. Đúng, rõ ràng là anh ấy đã từng gặp phải mã như vậy trước đây. Nói chung, anh ấy biết mọi thứ diễn ra như thế nào ở đó. Tất cả những gì chúng ta cần là một bản phác thảo giải pháp thể hiện sự hiểu biết về khái niệm này. Tuy nhiên, đoạn mã mà thí sinh viết lên bảng hoàn toàn vô nghĩa. Anh ấy có một ý tưởng rất mơ hồ về những lời hứa trong JavaScript và không thể giải thích thực sự tại sao chúng lại cần thiết. Đối với một cấp dưới thì điều này có thể được tha thứ, nhưng anh ta không còn phù hợp với vị trí của một cấp trên nữa. Làm thế nào nhà phát triển này có thể sửa lỗi trong một chuỗi lời hứa phức tạp và giải thích cho người khác chính xác những gì anh ta đã làm?
Các nhà phát triển coi mã làm sẵn là hiển nhiên
Trong quá trình phát triển, chúng tôi liên tục gặp phải các vật liệu có thể tái sản xuất. Chúng tôi chuyển các đoạn mã để không phải viết lại chúng mỗi lần. Theo đó, bằng cách tập trung toàn bộ sự chú ý vào các phần chính, chúng tôi xem đoạn mã hoàn chỉnh mà chúng tôi làm việc như một điều gì đó hiển nhiên - chúng tôi chỉ đơn giản cho rằng mọi thứ sẽ hoạt động như bình thường.
Và thường thì nó sẽ hoạt động, nhưng khi mọi thứ trở nên khó khăn, việc hiểu rõ về cơ học sẽ mang lại nhiều lợi ích hơn.
Vì vậy, ứng cử viên của chúng tôi cho vị trí nhà phát triển cấp cao coi các đối tượng hứa hẹn là hiển nhiên. Có lẽ anh ấy đã biết cách xử lý chúng khi chúng xuất hiện ở đâu đó trong mã của người khác, nhưng anh ấy không hiểu nguyên tắc chung và không thể tự mình lặp lại điều đó trong cuộc phỏng vấn. Có lẽ anh ấy đã thuộc lòng đoạn đó - nó không khó lắm:
return new Promise((resolve, reject) => {
functionWithCallback((err, result) => {
return err ? reject(err) : resolve(result);
});
});Tôi cũng đã làm điều đó - và có lẽ tất cả chúng ta đều đã làm điều đó vào một lúc nào đó. Họ chỉ đơn giản là ghi nhớ một đoạn mã để sau này có thể sử dụng nó trong công việc của mình, trong khi chỉ có ý tưởng chung về cách mọi thứ hoạt động ở đó. Nhưng nếu nhà phát triển thực sự hiểu khái niệm này, anh ta sẽ không cần phải nhớ bất cứ điều gì - anh ta chỉ cần biết cách thực hiện và dễ dàng tái tạo mọi thứ anh ta cần trong mã.
Hãy quay về cội nguồn
Vào năm 2012, khi sự thống trị của front-end framework vẫn chưa được thiết lập, jQuery đã thống trị thế giới và tôi đã đọc cuốn sách này. , được viết bởi John Resig, người tạo ra jQuery.
Cuốn sách hướng dẫn người đọc cách tạo jQuery của riêng họ từ đầu và cung cấp cái nhìn sâu sắc độc đáo về quá trình suy nghĩ dẫn đến việc tạo ra thư viện. Trong những năm gần đây, jQuery đã mất đi sự phổ biến trước đây nhưng tôi vẫn đánh giá cao cuốn sách này. Điều khiến tôi ấn tượng nhất về cô ấy là cảm giác dai dẳng rằng lẽ ra tôi có thể tự mình nghĩ ra tất cả những điều này. Các bước mà tác giả mô tả có vẻ rất logic, rõ ràng đến mức tôi thực sự bắt đầu nghĩ rằng mình có thể dễ dàng tạo jQuery nếu bắt tay vào thực hiện.
Tất nhiên, trên thực tế, tôi sẽ không thể làm được điều gì như thế này - tôi đã quyết định rằng nó khó đến mức không thể chịu nổi. Các giải pháp của riêng tôi có vẻ quá đơn giản và ngây thơ để thực hiện, và tôi sẽ từ bỏ. Tôi sẽ phân loại jQuery là những thứ hiển nhiên, trong hoạt động chính xác mà bạn chỉ cần tin tưởng một cách mù quáng. Sau đó, tôi sẽ khó lãng phí thời gian để tìm hiểu cơ chế của thư viện này mà chỉ sử dụng nó như một loại hộp đen.
Nhưng đọc cuốn sách này đã khiến tôi trở thành một con người khác. Tôi bắt đầu đọc mã nguồn và phát hiện ra rằng việc triển khai nhiều giải pháp trên thực tế rất minh bạch, thậm chí rõ ràng. Không, tất nhiên, việc tự mình nghĩ ra điều gì đó như thế này lại là một câu chuyện khác. Nhưng chính việc nghiên cứu mã của người khác và tái tạo các giải pháp hiện có sẽ giúp chúng tôi tìm ra thứ gì đó của riêng mình.
Cảm hứng bạn có được và những khuôn mẫu bạn bắt đầu nhận thấy sẽ thay đổi bạn với tư cách là một nhà phát triển. Bạn sẽ thấy rằng thư viện tuyệt vời mà bạn thường xuyên sử dụng và thư viện mà bạn quen coi như một tạo tác ma thuật hoàn toàn không có tác dụng với phép thuật mà chỉ đơn giản là giải quyết vấn đề một cách ngắn gọn và tháo vát.
Đôi khi bạn sẽ phải nghiền ngẫm mã, phân tích từng bước, nhưng đây là cách, di chuyển theo từng bước nhỏ, nhất quán, bạn có thể lặp lại đường dẫn đến giải pháp của tác giả. Điều này sẽ cho phép bạn đi sâu hơn vào quá trình mã hóa và giúp bạn tự tin hơn khi đưa ra các giải pháp của riêng mình.
Khi tôi mới bắt đầu làm việc với những lời hứa, đối với tôi nó giống như một phép thuật thuần túy. Sau đó, tôi phát hiện ra rằng chúng dựa trên cùng một lệnh gọi lại và thế giới lập trình của tôi bị đảo lộn. Vì vậy, mẫu, mục đích của nó là cứu chúng ta khỏi các cuộc gọi lại, lại được triển khai bằng cách sử dụng các cuộc gọi lại?!
Điều này giúp tôi nhìn vấn đề bằng con mắt khác và nhận ra rằng đây không phải là một đoạn mã khó hiểu nào đó trước mặt tôi, mức độ phức tạp đến mức tôi sẽ không bao giờ hiểu được trong đời. Đây chỉ là những mô hình có thể hiểu được mà không gặp vấn đề gì nếu có sự tò mò và tìm hiểu sâu. Đây là cách mọi người học cách viết mã và phát triển với tư cách là nhà phát triển.
Phát minh lại bánh xe này
Vì vậy, hãy tiếp tục và phát minh lại các bánh xe: viết mã ràng buộc dữ liệu của riêng bạn, tạo lời hứa trong nhà hoặc thậm chí tạo giải pháp quản lý trạng thái của riêng bạn.
Không có vấn đề gì khi không ai sử dụng tất cả những thứ này - nhưng bây giờ bạn đã biết cách thực hiện. Và nếu sau này bạn có cơ hội sử dụng những phát triển như vậy trong các dự án của riêng mình thì điều đó nói chung là tuyệt vời. Bạn sẽ có thể phát triển chúng và học được điều gì đó khác.
Vấn đề ở đây không phải là gửi mã của bạn đến sản xuất mà là để tìm hiểu điều gì đó mới. Viết cách triển khai giải pháp hiện có của riêng bạn là một cách tuyệt vời để học hỏi từ những lập trình viên giỏi nhất và từ đó trau dồi kỹ năng của bạn.
Nguồn: www.habr.com