Không thể nắm bắt các mẫu thiết kế lập trình

Tôi đã làm việc với javascript trong 4 năm qua. Tôi rất tự tin về các kỹ năng giải quyết vấn đề của mình và tôi có thể thấy rằng chất lượng mã của tôi đang được cải thiện. Tôi cố gắng cập nhật với cộng đồng và hiện tôi đang làm việc với ES2015 và React.js. Tuy nhiên, tôi cảm thấy như tôi không thể nắm bắt được các mẫu thiết kế lập trình. Tôi biết nơi để tìm tài nguyên về điều này và tôi đã đọc sách về nó. Tôi dựa vào các đồng nghiệp cấp cao của mình để đưa ra quyết định về cấu trúc dự án nhưng tôi không gặp vấn đề gì khi làm việc với nó.

Bất cứ khi nào tôi cần tự mình bắt đầu một cái gì đó, tôi sẽ tìm hai đường dẫn này: Nếu tôi đang sử dụng một thư viện / khung lớn như React.js, tôi có xu hướng sao chép những gì cộng đồng đang làm; Nếu tôi ở một cái gì đó nhỏ hơn, tôi sẽ sử dụng mô hình mô-đun. Tôi biết rằng một khi tôi hiểu rõ hơn về chủ đề này, tôi sẽ có thể đưa ra quyết định tốt hơn, nhưng bây giờ tôi đã hoàn toàn lạc lối.

Tôi có nên tìm kiếm giáo dục vượt trội về điều này? Tôi có cần một người cố vấn về chủ đề này? Có phải tôi chỉ ngu ngốc? Đây thực sự là khó hiểu?

Các mẫu thiết kế phần mềm là giải pháp nổi tiếng cho các vấn đề nổi tiếng. Cách bạn hiểu chúng là bằng cách tìm hiểu các mẫu, hiểu cách chúng hoạt động và biết khi nào thì phù hợp để áp dụng từng mẫu cho thiết kế phần mềm của bạn.

Cách bạn học các mẫu thiết kế phần mềm là bằng cách nghiên cứu chúng, từng cái một. Đó là một quá trình giáo dục liên tục. Nếu bạn muốn giảm dấu chân học tập, hãy nghiên cứu những mô hình liên quan trực tiếp đến các công nghệ mà bạn hiện đang sử dụng.

Một số điều quan trọng cần biết về mẫu thiết kế:

1. Một số mẫu thiết kế là kiến trúc trong tự nhiên. MVC và MVVM là ví dụ về các mẫu như vậy. Bạn sử dụng các mẫu như vậy khi bạn cần các lợi ích tổ chức và cấu trúc mà họ cung cấp.

2. Một số mẫu thiết kế là giải pháp cho sự thiếu sót trong ngôn ngữ lập trình. Bạn sẽ không cần những mẫu này nếu bạn sử dụng ngôn ngữ lập trình biểu cảm hơn, nhưng thường thì bạn không được đưa ra lựa chọn này. Phần lớn các mẫu GoF nằm trong danh mục này .

3. Chỉ sử dụng một mẫu phần mềm khi bạn đang cố gắng giải quyết vấn đề mà mẫu đó được thiết kế riêng để giải quyết. Nếu bạn đang viết một ứng dụng bằng cách ghép các mẫu phần mềm lại với nhau, bạn đã làm sai.

4. Không có mẫu phần mềm hiện có cho mọi vấn đề điện toán tồn tại. Trong trường hợp đó, lập trình sẽ chỉ là một bài tập phù hợp với mô hình.

5. Một số mẫu thực sự là chống mẫu. Sự phức tạp bổ sung mà các mẫu này giới thiệu lớn hơn những lợi ích mà chúng cung cấp. Bạn sẽ phải tự quyết định, trên cơ sở từng mẫu, những mẫu nào bạn sẽ tránh.

Cách tiếp cận học tập của mọi người có một chút khác biệt và tôi không biết cách tiếp cận chung của bạn là gì, nhưng tôi tin rằng việc bạn tự làm mất tinh thần bằng cách tự gán cho mình là "ngu ngốc".

Cá nhân, từ những quan sát của tôi về cái mà nhiều người gọi là các kỹ sư phần mềm "thành công", các nhà thiết kế, v.v ... đều có một chủ đề chung cho việc học của họ: "kinh nghiệm". Tôi tin rằng đây là "nền giáo dục ưu việt" của bạn và bạn sẽ học hỏi nhanh hơn từ nó hơn là mua hàng tấn sách trên amazon và đọc qua chúng (một thói quen xấu của tôi).

Vì vậy, ví dụ, lấy một mẫu GOF như mẫu lệnh và triển khai nó theo lựa chọn ngôn ngữ của bạn. Hiểu những lợi ích mà nó mang lại cho bạn và những hạn chế. Các cuốn sách khác nhau về các mẫu thiết kế sẽ giải thích điều này cho bạn, nhưng tôi cảm thấy tốt hơn khi áp dụng kiến ​​thức đó vào thực tế và học hỏi từ nó. Đừng giảm giá tài liệu đọc, họ có một mục đích, nhưng thế giới CNTT hầu như không phải là một bài tập trong sách giáo khoa. Điều đó đang được nói, đó là quan điểm và quan điểm của tôi về thế giới CNTT và một phần, đại diện cho những cuộc đấu tranh của chính tôi khi bắt đầu sự nghiệp của tôi trong công nghệ phần mềm. Ngoài ra, một vấn đề lớn mà tôi thấy, ngay cả với các nhà phát triển phần mềm rất có kinh nghiệm là thiếu kiên nhẫn và quên tận hưởng những gì họ đang làm. Vì vậy, hãy dành thời gian của bạn với những gì bạn học và nhớ để thực sự tận hưởng những gì bạn đang làm, nếu không tại sao phải đầu tư thời gian vào nó?

Ngoài ra, hãy tận dụng kinh nghiệm thực tế của người khác. Có rất nhiều giải pháp nguồn mở, cả xấu lẫn tốt và bạn có thể học hỏi từ chúng. Nhìn vào cách họ đã áp dụng các mô hình và suy nghĩ về cách bạn sẽ giải quyết nó khác nhau.

Vì vậy, lời khuyên chung của tôi là nếu bạn cảm thấy cách tiếp cận của mình sai, hãy thay đổi nó. Nhìn vào những người xung quanh bạn mà bạn cảm thấy đang học những tài liệu mà bạn cảm thấy bạn không nắm bắt được và nhìn vào những gì họ đang làm hoặc thậm chí hỏi họ.

Câu trả lời ngắn gọn là bạn không cần chúng. Bạn có thể viết mã mà không cần chúng. Như Matthew đã nói trong các bình luận, điều này đặc biệt đúng trong JavaScript khi ngôn ngữ khá linh hoạt và các dự án có xu hướng nhỏ hơn. Nhưng nếu bạn đã lập trình được 4 năm, tôi cảm thấy khó tin rằng bạn đã không vấp phải những điều cảm thấy lặp đi lặp lại hoặc khó xử. Đó là những lĩnh vực mà bạn đang khám phá lại hoặc thiếu các mẫu thiết kế.

Ví dụ: Hệ thống sự kiện của JavaScript thường không phù hợp với nhiệm vụ hiện tại. Bạn có bao giờ thấy mình muốn có thể kết hợp hoặc biến đổi các luồng sự kiện không? Hoặc chuỗi sự kiện đó là giá trị hạng nhất theo cách riêng của họ? Bạn cần các mẫu Người hòa giải và / hoặc Người quan sát. Cần ràng buộc dữ liệu 2 chiều? Cùng một câu chuyện.

Nguyên mẫu phân cấp giòn gotcha xuống? Mô hình nhà máy Mixin / Trait / Subgroup để giải cứu.

Tìm một người cố vấn, một người có kinh nghiệm rất tốt để học hỏi. Hỏi anh ta xem mã của anh ta, gửi một số đánh giá mã và cố gắng cộng tác với anh ta. Đây là cách tốt nhất để tăng cường kỹ năng mã hóa của bạn.

thêm:

• Hợp tác với một số dự án OSS đơn giản mà bạn thích

• Khi có hai cách giải quyết cùng một vấn đề, hãy luôn chọn cách đơn giản hơn

• Xây dựng một số kinh nghiệm bổ sung với các dự án phụ, nơi bạn có thể tự do thực hiện tất cả các loại lỗi lạ và bạn sẽ tìm hiểu mẫu thiết kế "một cách khó khăn" (tm)