Có hợp lý không khi mong đợi rằng một nhà phát triển cao cấp biết các mẫu thiết kế OOP là gì? [đóng cửa]

Tôi đang chuẩn bị câu hỏi cho các cuộc phỏng vấn việc làm cho một vị trí phát triển cao cấp. Công việc sẽ bao gồm thiết kế hướng đối tượng và phần mềm hiện có sử dụng các mẫu thiết kế, vì vậy tôi muốn yêu cầu các ứng viên giải thích một vài mẫu thiết kế mà họ biết, họ đã sử dụng, cách họ đã sử dụng chúng, tại sao họ lại sử dụng chúng sử dụng chúng và như vậy. Tuy nhiên, trong các cuộc phỏng vấn trước đây khi tôi hỏi các nhà phát triển cấp cao có ít nhất 5-10 năm kinh nghiệm về các mẫu thiết kế, hầu như chưa từng nghe về họ. Tôi nghĩ rằng hai trong số hai mươi nhà phát triển có thể đặt tên cho một mẫu thiết kế duy nhất (Singleton và MVC, tương ứng).

Vì vậy, câu hỏi của tôi là: nó có ý nghĩa để hỏi những câu hỏi này? Hay đây là một chủ đề tối nghĩa mà bạn không thể mong đợi những người tuyển dụng mới biết họ?

Nhà phát triển cấp cao có nên có kinh nghiệm trước với các mẫu thiết kế không, hoặc bạn sẽ nói rằng các mẫu thiết kế là một chủ đề đơn giản đến mức mọi nhà phát triển đàng hoàng có thể chọn chúng trong quá trình đào tạo? Nếu vậy, những câu hỏi bạn sẽ hỏi thay vì đánh giá khả năng thiết kế của họ?

Thêm Sau khi đọc câu trả lời cho đến nay, tôi nên đưa ra một vài giải thích:

• Công việc dành cho nhà phát triển .NET có kinh nghiệm về OOP / OOD
• Mã hiện có sử dụng tên lớp như IParameterGraphVisitorvà IStorageFactoryở nhiều nơi
• Làm thế nào để bạn hỏi mọi người về kinh nghiệm trong quá khứ của họ với các thiết kế OO do họ tạo ra, nếu họ không có từ vựng để giải thích các thiết kế của họ? Đó là những gì tôi muốn làm, và tất cả những gì tôi có thể nghĩ ra là "làm ơn hãy vẽ hệ thống phân cấp thiết kế / đối tượng của dự án cuối cùng của bạn lên bảng trắng".

Rất có thể họ làm biết họ. Họ chỉ có thể không biết chúng là "mẫu thiết kế"; tức là, họ có thể không quen thuộc với thuật ngữ học thuật cho những thứ đó. Những gì bạn xem là một 'cỗ máy nhà nước' có thể chỉ đơn giản là một cách tiếp cận thông thường đối với một vấn đề đối với một lập trình viên lớn tuổi hơn, có kinh nghiệm hơn. Tôi chưa bao giờ chú ý đến 'các mẫu thiết kế', ví dụ, nhưng khi tôi biết Máy trạng thái là gì, tôi đã phải cười vì tôi đã làm điều đó trong nhiều năm. Ai biết tôi là một học giả như vậy? Tôi luôn chỉ coi đó là kỹ năng mã hóa cơ bản, và không phải là 'mẫu thiết kế'.

Vấn đề là không cho rằng các nhà phát triển có kinh nghiệm của bạn biết các thuật ngữ trong sách giáo khoa cho mọi thứ; thay vào đó, hãy hỏi họ cách họ sẽ cấu trúc các lớp hoặc cách họ sẽ tiếp cận một nhiệm vụ.

Kỳ vọng của bạn là khá hợp lý cho một nhà phát triển OO cao cấp. Bất cứ ai gọi anh ta / cô ta mà không biết Mẫu thiết kế chỉ chứng minh rằng trải nghiệm không được tự động mang lại sau nhiều năm trôi qua :-( Chắc chắn có rất nhiều nhà phát triển ngoài đó đã dành nhiều năm hoặc thậm chí nhiều thập kỷ trên lĩnh vực này, mà không bao giờ nghe về thiết kế các mẫu - điều đó chỉ cho thấy họ không quan tâm đến việc học các ý tưởng mới, cải thiện bản thân và áp dụng các thực tiễn tốt nhất.

Nhà phát triển cấp cao có nên có kinh nghiệm trước với các mẫu thiết kế không, hoặc bạn sẽ nói rằng các mẫu thiết kế là một chủ đề đơn giản đến mức mọi nhà phát triển đàng hoàng có thể chọn chúng trong quá trình đào tạo?

Kinh nghiệm IMO tính rất nhiều. Về lý thuyết, một nhà phát triển đàng hoàng có thể đọc các Mẫu thiết kế trong một cuốn sách, hoặc thậm chí trên Wikipedia và hiểu khái niệm cơ bản trong 15 phút. Tuy nhiên, áp dụng các khái niệm đúng cách cần có kinh nghiệm khó kiếm được. Thật dễ dàng để bị mê đắm với các mẫu, cố gắng nhồi nhét chúng vào mọi đoạn mã có thể, hãy rót cho tôi. Cũng dễ dàng bác bỏ họ nói rằng "các mẫu không phải là viên đạn bạc, chỉ cần sử dụng thứ đơn giản nhất có thể hoạt động được". Tìm ra nền tảng trung gian giữa hai thái cực bằng cách tìm hiểu khi nào và làm thế nào để sử dụng các mẫu để giải quyết các vấn đề thực sự và khi nào không sử dụng chúng, phải mất nhiều năm kinh nghiệm .

thay vào đó bạn sẽ hỏi những câu hỏi nào để đánh giá khả năng thiết kế của họ?

Trong buổi hòa nhạc với những điều trên, tôi sẽ chỉ thêm những câu hỏi này vào danh sách của bạn:

• Những nhược điểm của các mẫu thiết kế (nói chung và của những mẫu mà chúng đề cập rõ ràng) là gì?
• Khi không sử dụng chúng, và tại sao?

Cập nhật

@GrandmasterB có một điểm tốt là một số nhà phát triển có thể đang sử dụng các mẫu thiết kế cụ thể mà không biết tên của họ. Theo một cách nào đó, ông nói đúng rằng đây là một câu hỏi về thuật ngữ / giao tiếp. Tuy nhiên, mặt khác của đồng tiền là nó thực sự là một câu hỏi về thuật ngữ / giao tiếp :-) Đó là, một trong những lợi ích chính của Mẫu thiết kế là cung cấp vốn từ vựng chung cho các nhà phát triển, cải thiện rất nhiều khả năng giao tiếp . (Cố gắng giải thích ý tưởng cơ bản của Adaptor mà không sử dụng từ đó, hoặc từ đồng nghĩa của nó là "Wrapper" et al!) Vì vậy, một ứng viên có thể hiểu biết và tài năng, nhưng không biết thuật ngữ được chấp nhận rộng rãi mà anh ta sẽ đưa ra một vấn đề giao tiếp. trong nhóm của bạn.

Một nhà phát triển cao cấp ? Chắc chắn rồi. Một đàn em nên. Tôi 15 tuổi, không có giáo dục chính thức về chủ đề này và thậm chí tôi hiểu họ. Không chỉ hợp lý khi mong đợi rằng họ biết họ, sẽ không thể chấp nhận được nếu họ không làm như vậy. Giả sử họ biết điều gì đó về lập trình hướng đối tượng, điều mà họ rất có thể làm.

Trong một cuộc phỏng vấn, bạn nên hỏi những gì quan trọng cho ứng viên cần biết để thực hiện công việc.

Nếu họ phải biết tên của các mẫu như chúng là từ Gang of Four thì đó là một yêu cầu hợp lệ.

Mặt khác, nếu bạn muốn họ hiển thị kiến ​​thức làm việc phù hợp về kiến ​​trúc chương trình, tôi nghĩ rằng tốt hơn hết là bạn nên đưa ra cho họ một vấn đề và hỏi họ cách cấu trúc mã. Nếu họ cung cấp cho bạn giải pháp mẫu thích hợp thì bạn có bằng chứng họ biết, bất kể tên được sử dụng.

Bất cứ khi nào tôi phỏng vấn cho các vị trí cấp cao, họ có xu hướng "thực tế" hơn so với hỏi đáp. Tôi muốn một minh chứng rõ ràng về kỹ năng và sự thoải mái trong lập trình. Tôi cũng muốn có một nền tảng vững chắc trong các khái niệm CS, có nghĩa là các kỹ năng tổng quát hơn về cách áp dụng các khái niệm như đóng gói, thuật toán, khớp nối / gắn kết, v.v. Kinh nghiệm và sự quen thuộc trong nhiều ngôn ngữ và mô hình.

Phụ thuộc vào lĩnh vực chuyên môn của họ. Tôi không mong đợi một nhà phát triển C nhúng sẽ biết nhiều về các mẫu thiết kế. Nếu chúng ta đang nói về một nhà phát triển Java hoặc .NET, họ nên làm quen với các mẫu thiết kế và đặc biệt là làm thế nào để không quá mải mê với chúng.

Giả sử bạn đang tìm kiếm thâm niên trong OOP, câu trả lời chắc chắn là có. Các mẫu thiết kế là từ vựng của ngôn ngữ OOP.

Hơn nữa, ngày nay thật vô lý khi một lập trình viên OOP đàng hoàng với 10 năm kinh nghiệm không thể đặt tên cho một mẫu thiết kế, là các mẫu thiết kế được áp dụng rộng rãi trong các API, thư viện và khung phát triển tiêu chuẩn.

Đã nhiều năm nay tôi đã hỏi câu hỏi này trong các cuộc phỏng vấn và nó là một showstopper khi ứng viên không cung cấp câu trả lời thỏa mãn về chủ đề này.

Có, nhưng có lẽ bạn nên khơi gợi sự hiểu biết của họ bằng cách đặt câu hỏi về thiết kế thay vì yêu cầu mọi người liệt kê các mẫu thiết kế mà họ đã nghe nói. Tôi khá thoải mái với các mẫu được mô tả trong PoEAA, GoF và thậm chí một số mẫu lập trình chức năng và tôi vẫn không nghĩ rằng bạn sẽ tìm hiểu nhiều hơn về cách tiếp cận của tôi để giải quyết vấn đề bằng cách yêu cầu tôi đặt tên cho một số mẫu.

Đưa ra một câu hỏi như "thiết kế cho tôi một trình soạn thảo văn bản" với các phần tiếp theo như "Bạn sẽ hỗ trợ các đối tượng nhúng như hình ảnh như thế nào? In đậm và in nghiêng? Hoàn tác?" Cuối cùng, bạn có thể nghe đủ để nhận ra mẫu lệnh, mẫu tổng hợp, mẫu vật lưu niệm và một vài thứ khác thậm chí chỉ có một cuộc trò chuyện ngắn.

Các mẫu thiết kế đã được phát hiện và sau đó được mô tả để chúng ta có một ngôn ngữ chung để truyền đạt các quyết định thiết kế.

Thật không may, tôi đã làm việc cho một người mà mọi việc sử dụng một mẫu thiết kế phải được giải thích và biện minh, không phải vì sự siêng năng, mà vì đơn giản là anh ta không biết họ. Điều đó không vui chút nào. Nhưng hầu hết các nhà phát triển nghiêm túc, do vô tình hoặc thiết kế, đã học được tên của các mẫu OO được sử dụng phổ biến nhất, nếu không có gì khác, và hầu hết các nhà phát triển ứng dụng doanh nghiệp đều coi trọng muối của họ ít nhất là biết về các mẫu PoEAA phổ biến nhất.

Hợp lý. Chắc chắn Cần thiết. Không

Tôi hỏi các ứng viên tiềm năng nếu họ biết các mẫu thiết kế. Nó chỉ là một trong một số tiêu chí để được cân nhắc tổng thể. Đừng bỏ qua bức tranh tổng thể.

Vâng, nhiều nhà phát triển vô tình sử dụng một số mẫu thiết kế, không còn nghi ngờ gì nữa.

Đó không phải là lý do tại sao tôi đặt câu hỏi.

Điều quan trọng cần biết là tôi có thể giao tiếp nhanh chóng và hiệu quả với một nhà phát triển khác. Tôi không muốn dành 20 phút cho bảng trắng giải thích một máy trạng thái chỉ để thấy rằng họ "đã sử dụng nó trước đây, nhưng không bao giờ biết nên gọi nó là gì". Điều này không hiệu quả.

Họ cũng giúp đỡ trong quá trình tái cấu trúc. Liếc qua mã người ta có thể thực hiện một cách ngẫu nhiên một số dạng của mẫu nhà máy, nhưng mẫu nhà máy của GoF đã chịu được thử thách của thời gian. Đó là lý do tại sao nó là mô hình nhà máy, không Yet Another fp (reinventing the wheel là không thích hợp, Joel trên phần mềm có rất nhiều trên những nhược điểm của làm như vậy).

Một nhóm sử dụng và nhận ra tầm quan trọng của các mẫu thiết kế làm tăng khả năng giao tiếp và năng suất. Nếu nhóm của bạn, với tư cách là một đơn vị, không sử dụng dp thì họ sẽ mất liên quan.

Phát biểu từ kinh nghiệm của bản thân, tôi đã bỏ qua các thiết kế vỗ về khá lâu. Tôi biết rằng chúng tồn tại, tôi chỉ không bao giờ đọc về chúng. Cuối cùng khi tôi cắn viên đạn, tôi nhận ra rằng tôi đã sử dụng mẫu thiết kế suốt và tôi chỉ không nhận ra hoặc tôi không biết rằng các giải pháp thiết kế của tôi thực sự có một tên chung.

Tôi sẽ có xu hướng đưa ra một loạt các vấn đề trong đó một mẫu thiết kế cụ thể phù hợp với giải pháp và thấy nhà phát triển đưa ra một cái gì đó tương tự như mẫu. Nếu họ làm, tuyệt vời. Tôi thậm chí còn có xu hướng thuê một nhà phát triển sử dụng các mẫu thiết kế mà tôi không biết vì tôi thấy rất nhiều nhà phát triển có kiến ​​thức về mẫu thiết kế đang cố gắng phù hợp với một giải pháp cho một mẫu khi nó không phù hợp thay vì nhận ra một mẫu cụ thể xảy ra để giải quyết vấn đề tốt

Tôi nghĩ rằng một câu hỏi tốt hơn sẽ là: Đặt tên cho một mẫu và mô tả về mẫu đó, ví dụ như Mô hình nhà máy từ cuốn sách Gang of Four, ứng viên sẽ có thể đưa ra một kịch bản trong đó mô hình sẽ là một cách tiếp cận hợp lý.

Có những nhà phát triển với 5-10 năm kinh nghiệm và có những nhà phát triển cao cấp. Chúng không giống nhau chút nào. Có nếu bạn đang tuyển dụng ở cấp cao và bạn mong mọi người biết và sử dụng các mẫu thiết kế thì tôi sẽ không thuê một người cao cấp không quen thuộc với họ. Điều đó sẽ giống như việc thuê một chuyên gia cơ sở dữ liệu không hiểu về việc tham gia trái. Đó là những thứ khá cơ bản cho một nhà phát triển cấp cao thực sự. Tôi có lẽ sẽ thuê một người đàn em mặc dù.

Đúng vậy, họ thực sự nên làm quen với thuật ngữ này và thậm chí có thể đặt tên cho một vài trong số các mẫu - nhưng đừng nhầm lẫn giữa việc nhầm lẫn kiến ​​thức lý thuyết với kinh nghiệm.

Có nhiều người trước khi phỏng vấn sẽ xem xét các mẫu thiết kế và có thể mô tả chúng bằng một mô tả ngắn gọn - nhưng đó chỉ là lý thuyết. Đó là một nhà phát triển cao cấp thực sự, người có thể phát hiện ra khi nào nên sử dụng một hoặc không có kiến ​​thức về một mẫu chính thức sẽ giải quyết vấn đề theo cách thiết kế mẫu cổ điển.

Cách tốt nhất để kiểm tra là để họ thiết kế một cái gì đó trước mặt bạn và đặt câu hỏi thăm dò .. một nhà phát triển cao cấp là người có thể suy nghĩ tự nhiên ở mức độ trừu tượng. Đây là những người "tạo ra" các mẫu thiết kế.

Giống như lớp Peopleware nói về việc thuê một người tung hứng mà không yêu cầu họ tung hứng - chỉ vì họ nói rằng họ không có nghĩa gì nhiều .. hãy thử chúng.

Như đã nêu, tôi cũng tin rằng sẽ ổn nếu họ không nhớ buzzwords. Nhưng vì đây là một vị trí cấp cao nên họ nên biết khi nào nên áp dụng một mô hình để giải quyết vấn đề một cách tối ưu thay vì sử dụng các giải pháp tồi tệ nhất. Do đó, cung cấp cho họ một vấn đề cần được giải quyết bằng cách sử dụng một mẫu (ví dụ: cách tạo một đối tượng mà không mã hóa lớp của nó, cách truy cập các phần tử của đối tượng mà không có chi tiết về việc triển khai của nó, v.v.) và xem cách họ sẽ tấn công nó

Chắc chắn họ phải biết các mẫu, nhưng không nhất thiết phải là từ thông dụng.

Ví dụ MVC có nhiều lựa chọn thay thế rất giống nhau như PAC, 3 tầng. Vài năm trước, một từ thông dụng phổ biến khác cho MVC là "Model 2". Tôi thực sự biết các nhà phát triển rất giỏi, những người biết mô hình đó một cách hoàn hảo, nhưng không biết rằng từ thông dụng hiện tại cho nó là MVC.

Rất đơn giản: nếu bạn đang sử dụng chúng thì bạn cần phải hỏi ứng viên của mình. Nếu họ biết mẫu, thì nên thêm một vài điểm cộng; nhưng không biết rằng không nhất thiết phải làm phiền họ, đặc biệt là nếu họ thể hiện các kỹ năng tốt. Các nhà phát triển đã và đang trong các dự án bảo trì dường như không biết nhiều về các mẫu thiết kế so với những người đã thiết kế chúng. nó cũng phụ thuộc vào việc họ đã được dạy mô hình desing ở trường đại học. Theo kinh nghiệm của tôi, không chắc là họ sẽ làm thế. Hầu hết các trường đại học và các khóa học tư nhân dạy cho bạn OOP nhưng không phải là OOD. Cơ hội mà họ sẽ nghiên cứu DP thậm chí còn ít hơn.

Cá nhân tôi đã không học DP cho đến khi dự án của tôi cũng yêu cầu tôi. Ngay cả sau đó tôi thấy rằng tôi đã sử dụng một vài trong số các mẫu, ít nhất là theo cách tương tự nếu không theo cách chính xác được mô tả trong cuốn sách. Tôi đã rất ngạc nhiên khi biết rằng chúng đã được mã hóa. Vì vậy, hãy tìm kiếm các kỹ năng thiết kế tốt nếu họ không biết DP. Nếu họ biết DP thì có khả năng họ giỏi thiết kế nhưng vẫn kiểm tra họ. Họ có thể vừa nói một số từ buzz về DP hoặc tìm hiểu từ một số người trong cuộc và chỉ nghiên cứu một vài mẫu mà không áp dụng chúng.

Thật hợp lý khi bạn mong đợi những người đi xin việc với bạn biết (hoặc học) những điều cần thiết trong vị trí công việc của bạn, bất kể họ có đạt tiêu chuẩn ngành hay không. Nếu không, bạn lên án chính mình đến tầm thường. Nhưng hãy cẩn thận với việc biến một số kiến ​​thức (hoặc kỹ năng) thành một yêu cầu công việc, nếu nó không thực sự cần thiết.

Giả sử bạn có hai ứng cử viên có nền tảng gần giống nhau và một người có thể cho bạn biết về các mẫu thiết kế, còn người kia thì không. Điều đó sẽ cho bạn biết về cách họ sẽ thực hiện trong công việc?

Bạn nói phần mềm hiện có sử dụng các mẫu thiết kế. Đó có phải là một lợi thế? Nếu vậy thì thế nào? Mục tiêu của bạn là phần mềm mới được viết phù hợp với các mẫu hiện có hay các mẫu mới được giới thiệu? Tại sao?

Tôi có thể nghĩ về một nhà phát triển cao cấp không biết về các mẫu thiết kế trong tình huống sau:

1. Chỉ có một cuốn sách về các mẫu thiết kế. Đó là cuốn sách khiến chúng trở nên phổ biến ngay từ đầu. Nếu người đó chưa đọc cuốn sách này, có thể họ không biết về các mẫu thiết kế, hoặc có thể đã nghe về chúng, nhưng không biết chính xác chúng dùng để làm gì
2. Thay vào đó, họ sẽ phải biết một cái gì đó như uml ....
3. Tìm kiếm thông tin tốt về các mẫu thiết kế từ internet là không dễ dàng. Bạn rất may mắn nếu bạn truy cập đúng trang web có kiến ​​thức mẫu thiết kế tốt. Chỉ đơn giản là đến với phần mềm sau năm 1995 có thể khiến một người không biết về thiết kế mẫu sách, bởi vì cuốn sách đã cũ.

Tại sao bất kỳ nhà phát triển nào trong môi trường không phải OO đều biết về các mẫu thiết kế OO? Tôi đã làm việc trong các cửa hàng chỉ làm Cobol, chỉ PL / SQL, chỉ tiến bộ 4GL, v.v. hoa văn.

Có thể trích dẫn một cách vô thức từ một danh mục mẫu cũng không giúp bạn trở thành một nhà phát triển giỏi (thực tế, theo kinh nghiệm của tôi, nó tạo ra một số đoạn mã tồi tệ nhất tôi từng thấy). Tuy nhiên, đó là những gì bạn mong đợi là dấu hiệu của một "nhà phát triển cao cấp". Tôi đã làm việc trong ngành được 15 năm, nhưng đừng yêu cầu tôi vẽ sơ đồ mẫu. Tôi chưa bao giờ cho nó nhiều thời gian, tôi không cần. Tôi đã có đủ kinh nghiệm để tìm ra những gì hoạt động mà không đặt tên cụ thể cho nó và nếu tôi cần định nghĩa chính thức, tôi biết nơi để tìm nó (và vâng, tôi có sách tham khảo trong thư viện cá nhân của mình). Đó là dấu ấn của nhà phát triển có kinh nghiệm, không phải kiến ​​thức học được từ việc nhồi nhét một số sách học.