Tại sao việc sử dụng trừu tượng hóa (như LINQ) lại rất cấm kỵ? [đóng cửa]


60

Tôi là một nhà thầu độc lập và như vậy, tôi phỏng vấn 3-4 lần một năm cho hợp đồng biểu diễn mới. Bây giờ tôi đang ở giữa chu kỳ đó và bị từ chối vì một cơ hội mặc dù tôi cảm thấy cuộc phỏng vấn diễn ra tốt đẹp. Điều tương tự đã xảy ra với tôi một vài lần trong năm nay.

Bây giờ, tôi không phải là một chàng trai hoàn hảo và tôi không mong đợi sẽ phù hợp với mọi tổ chức. Điều đó nói rằng, mức trung bình của tôi thấp hơn bình thường nên tôi lịch sự hỏi người phỏng vấn cuối cùng của tôi cho một số phản hồi mang tính xây dựng, và anh ấy đã giao hàng!

Điều chính, theo người phỏng vấn, là tôi dường như nghiêng quá nhiều về việc sử dụng các khái niệm trừu tượng (như LINQ) thay vì hướng tới các thuật toán phát triển hữu cơ ở cấp độ thấp hơn.

Nhìn bề ngoài, điều này có ý nghĩa - trên thực tế, nó cũng khiến cho những lời từ chối khác trở nên có ý nghĩa vì tôi cũng nói về LINQ trong các cuộc phỏng vấn đó và dường như những người phỏng vấn không biết nhiều về LINQ (mặc dù họ là .NET các chàng trai).

Vì vậy, bây giờ tôi chỉ còn lại câu hỏi này: Nếu chúng ta được cho là "đứng trên vai những người khổng lồ" và sử dụng những thứ trừu tượng có sẵn cho chúng ta (như LINQ), thì tại sao một số người lại coi đó là điều cấm kỵ? Chẳng có nghĩa gì khi rút mã "ra khỏi kệ" nếu nó hoàn thành các mục tiêu tương tự mà không phải trả thêm chi phí?

Đối với tôi, dường như LINQ, ngay cả khi nó một sự trừu tượng hóa, chỉ đơn giản là một sự trừu tượng hóa của tất cả các thuật toán tương tự mà người ta sẽ viết để thực hiện chính xác cùng một kết thúc. Chỉ có một bài kiểm tra hiệu suất có thể cho bạn biết cách tiếp cận tùy chỉnh của bạn tốt hơn, nhưng nếu một cái gì đó như LINQ đáp ứng các yêu cầu, tại sao lại phải viết các lớp của riêng bạn ngay từ đầu?

Tôi không có ý tập trung vào LINQ ở đây. Tôi chắc chắn rằng thế giới JAVA có một cái gì đó tương đương, tôi chỉ muốn biết tại sao một số người trở nên khó chịu với ý tưởng sử dụng một sự trừu tượng mà chính họ không viết.

CẬP NHẬT

Như Euphoric đã chỉ ra, không có gì có thể so sánh với LINQ trong thế giới Java. Vì vậy, nếu bạn đang phát triển trên ngăn xếp .NET, tại sao không luôn thử và sử dụng nó? Có phải mọi người chỉ không hiểu đầy đủ những gì nó làm?


8
Tôi nghĩ bạn không biết "trừu tượng" là gì, bởi vì LINQ không liên quan gì đến nó.
Euphoric

8
"Tôi chắc chắn rằng thế giới JAVA có một cái gì đó tương đương" Thực ra, LINQ là một trong số ít những thứ mà .NET có và Java thì không.
Euphoric

42
@ Euphoric - Có phải LINQ không trừu tượng hóa công việc cấp thấp hơn của các nhiệm vụ như sắp xếp và lọc chẳng hạn? Tôi khá chắc chắn rằng sẽ có một số mã bổ sung phía sau objectCollection.Where(oc=>oc.price > 100)chẳng hạn. Điều đó sẽ không được sử dụng một sự trừu tượng? Có lẽ bạn có thể cho tôi biết những gì tôi đang thiếu ở đây. . .
Matt Cashatt

37
Luôn có cơ hội là họ không hiểu LINQ và không thấy giá trị khi học nó. Các khía cạnh chức năng của văn bản nó rất rất khác với lập trình mệnh lệnh. Là một nhà thầu tôi gần đây như năm 2009 đã thấy các nhà phát triển Java "cao cấp" không hiểu SQL đủ để viết các truy vấn nâng cao để họ dành hàng tuần để tối ưu hóa mã mang tất cả dữ liệu sang phía Java và lọc nó bằng mã Java thay vì phải có cơ sở dữ liệu làm điều đó. Sự thiếu hiểu biết đang lan tràn trong ngành công nghiệp phát triển phần mềm.

18
Nếu bạn hiểu LINQ nhưng người phỏng vấn của bạn thì không, bạn tốt hơn họ. Đặt điểm tham quan của bạn cao hơn.
Jay Bazuzi

Câu trả lời:


74

Tôi không nghĩ rằng việc sử dụng trừu tượng cho mỗi điều đó là phản cảm. Có hai cách giải thích khác. Một là trừu tượng tất cả đều bị rò rỉ lúc này hay lúc khác. Nếu bạn cho ấn tượng, đúng hay không, rằng bạn không hiểu các nguyên tắc cơ bản cơ bản, điều đó có thể phản ánh kém trong một cuộc phỏng vấn.

Giải thích khác có thể là hiệu ứng fanboy. Nếu bạn hào hứng nói về LINQ, và liên tục đưa nó vào một cuộc phỏng vấn với một công ty không sử dụng nó và không có kế hoạch hiện tại để làm điều đó, điều đó mang lại ấn tượng rằng bạn sẽ không hài lòng hoặc thậm chí không hài lòng khi làm việc với các công nghệ cũ. Nó cũng có thể mang lại ấn tượng rằng sự nhiệt tình của bạn đối với một sản phẩm đã khiến bạn mù quáng thay thế.

Nếu bạn thực sự nghĩ rằng bạn sẽ được hạnh phúc trong một cửa hàng phi LINQ, hãy thử hỏi về những gì họ làm sử dụng, và chỉnh câu trả lời của bạn cho phù hợp. Cho họ thấy rằng trong khi bạn thích LINQ, bạn có khả năng sử dụng bất kỳ công cụ nào trong tay.


4
@MatthewPatrickCashatt Bạn không thể chỉnh sửa và tiếp tục trình gỡ lỗi bên trong các phương thức có chứa các câu lệnh linq. Nó không đủ để biến mà tôi không sử dụng nó; nhưng đó là lý do chính khiến tôi do dự trong một thời gian.
Dan Neely

3
+1, đặc biệt là cho đoạn thứ hai. Nó hoàn toàn áp dụng cho tôi, vì tôi sẽ hoàn toàn không hài lòng khi làm việc với mã C # mà không thể sử dụng LINQ.
Arseni Mourzenko

5
Ngoài ra còn có một thực tế là thường xuyên có một hiệu suất thành công ngoài sự trừu tượng bị rò rỉ. Bạn đang trao đổi dễ sử dụng cho độ chính xác và việc mất độ chính xác thường xuyên bao gồm các chi tiết sẽ giúp mọi việc nhanh hơn. Và bạn càng bị xóa khỏi nguồn, bạn càng mất nhiều chi tiết và xác suất lớn hơn là những chi tiết đó quan trọng đối với hiệu suất.
jmoreno

6
+1 nhưng nó cũng có thể hoạt động theo cách khác. Nếu ai đó nói với tôi rằng họ đã không thuê tôi vì tôi sử dụng Yacc để xây dựng các trình phân tích cú pháp thay vì tự lăn, thì đó không phải là nơi tôi muốn làm việc.
Spencer Rathbun

5
@MatthewPatrickCashatt: câu trả lời này (và nhận xét của tôi về nó) không cụ thể đối với LINQ, nhưng các tuyên bố chung. Nhưng đối với LINQ, đây là một đoạn trích từ C # 4.0 / 5.0 trong một Nutshell, nói về các vấn đề về hiệu suất với LINQ. Quay lại với tính tổng quát: trong nhiều trường hợp, hiệu suất đạt được sẽ rất xứng đáng, 5% +/- không liên quan. Nhưng đôi khi nó sẽ lớn hơn và đôi khi thậm chí .1% là không thể chấp nhận được. Nếu bạn không nghĩ có thể có vấn đề hoặc hiệu suất đó chỉ dành cho các công ty như google ....
jmoreno

29

Một số lập trình viên .NET, đặc biệt là những người đến từ nền tảng VB / ASP hoặc C ++ cổ điển, không thích những thứ mới như LINQ, MVC và Entity Framework.

Dựa trên những gì tôi đã quan sát, các VB cũ trong nhóm này có thể vẫn đang sử dụng một lớp truy cập dữ liệu và mã khác được viết ban đầu từ hơn 10 năm trước. Họ cũng sẽ sử dụng các từ thông dụng cũ như "n-tier" và những thứ tương tự và không thực sự hiểu bất cứ điều gì về .NET Framework 2.0 và họ không muốn tìm hiểu bất cứ điều gì về nó.

Người dùng của C ++ có xu hướng là những lập trình viên có định hướng học thuật, yêu thích mã hóa các thuật toán tuyệt vời, ngay cả khi điều đó có nghĩa là phát minh lại bánh xe. Họ ghét phụ thuộc vào bất cứ điều gì họ không tự tay viết mã. Một vài trong số những người này cũng thích thú làm cho người được phỏng vấn cảm thấy thấp kém, đặc biệt là những người có nền tảng truyền thống ít hơn.

Bạn có khả năng chạy vào các tổ chức như thế này khi bạn phỏng vấn. Nhưng, bạn cũng sẽ gặp một số người đang sử dụng các phương pháp mới hơn. Đừng để một vài cuộc phỏng vấn xấu ném bạn đi.


2
Cảm ơn jfrankcarr. Tôi nghi ngờ rằng đây có thể là trường hợp - có câu hỏi về việc mở và đóng datareaders!
Matt Cashatt

2
+1 để gọi MVC là "công cụ mới." Khiến tôi bật cười thành tiếng. đã có từ những năm 70. Bạn có thể có nghĩa là MVVM, về cơ bản là MVP (một biến thể MVC) sử dụng các liên kết.

14
@ GlenH7 Tôi nghĩ khá rõ ràng từ ngữ cảnh rằng ý anh ấy là sản phẩm "ASP.NET MVC", không phải là khái niệm cơ bản của Model-View-Controller.
Carson63000

4
@ GlenH7 - Tôi đã nói hoàn toàn trong bối cảnh của dòng sản phẩm .NET và Visual Studio và buzzwords sản phẩm của Microsoft.
jfrankcarr

6
Chúa ơi, có thực sự các cửa hàng nghĩ về Linq là "mới" không? Nó đã được hơn 4 năm rồi. Tôi có thể hiểu rằng không bắt kịp người chờ đợi nhiệm vụ hoặc sử dụng dynamic/ ExpandoObject/ v.v. hoặc không quan tâm đến Azure và tất cả các công cụ đám mây khác ... Tôi thậm chí có thể hiểu việc tiếp tục sử dụng chế độ xem WebForms của trường học cũ công cụ trong MVC hoặc Web Forms, hoặc viết mã WPF / WinRT mà không cần MVVM ... nhưng Linq? Nếu bạn chưa tìm ra điều đó, đã đến lúc bỏ công việc của bạn như một nhà phát triển .NET.
Aaronaught

16

Microsoft có một lịch sử lâu dài với các công nghệ mới nóng hổi và sau đó quên đi chúng 5, 10 hoặc 20 năm sau. LINQ có thể trông giống như một số khác với một số người. Họ sẽ lưu ý rằng Microsoft không thể phản đối SQL, nhưng LINQ có thể đang theo Silverlight . Vì vậy, bạn có thể thấy hoang tưởng do kinh nghiệm khó khăn, hoặc chỉ những người bị bỏ lại phía sau bởi công nghệ hiện đại và những người phẫn nộ.


12
Thành thật mà nói, trong khi tôi nhìn thấy điểm cơ bản, tôi không nghĩ Linq sẽ sớm ra đi. Linq2Query, vâng, họ đã từ chối nó để ủng hộ EF mạnh mẽ hơn nhiều. Nhưng chính Linq là nền tảng cho rất nhiều sự mới mẻ sáng bóng khác trong 3 phiên bản .NET mới nhất mà nếu họ không tán thành thì họ sẽ hoàn tác một nửa công nghệ lớp bền bỉ mới của họ như Azure và EF, để nói rằng không có gì làm tê liệt thực tế mỗi ORM ngoài đó và rất nhiều xử lý danh sách trong bộ nhớ bên cạnh.
KeithS

6
chờ đợi ... "kinh hoàng để di chuyển khỏi công nghệ cũ, lỗi thời, bởi vì nó hoạt động" ... WTF. Chúng ta đã đến điểm mà những thứ làm việc được thử, thử nghiệm, dễ hiểu và có thể duy trì, và trưởng thành là KHÔNG tốt.
gbjbaanb

7
@ gbjbaanb - Không. Nhưng - như một giai thoại - bạn muốn bác sĩ chẩn đoán đau ngực bằng chụp X quang ngực vì phương pháp đó là 'đã thử, đã thử, có thể hiểu được' hoặc bạn muốn một fMRI mới hơn, nhưng có độ phân giải cao hơn , tiên lượng tốt hơn và nhiều thông tin hơn? Không ai đang nói để quay lưng lại với các nguyên tắc cổ điển ở đây; hoàn toàn ngược lại. Bạn thấy đấy, LINQ (làm ví dụ) được xây dựng dựa trên những nguyên tắc đó. Tôi nghĩ, như những người khác đã đề cập, chính việc học các bộ phận tạo nên LINQ và việc sử dụng hợp lý đã gây ra những khoảnh khắc 'WTF' như của bạn.
Matt Cashatt

2
@MatthewPatrickCashatt: tùy thuộc, nếu bác sĩ chưa được đào tạo để đọc kết quả fMRI, tôi sẽ chụp X-quang thay vì chẩn đoán. Nếu tôi bị bệnh ở vùng nước ngầm, tôi muốn có một bác sĩ có thể chẩn đoán không có gì hơn là ống nghe hơn là không thể đối phó mà không có công cụ mới nhất.
gbjbaanb

2
@MatthewPatrickCashatt Tôi thấy quan điểm của bạn, nhưng một yếu tố cân bằng là bạn không muốn theo mọi xu hướng chỉ vì nó mới hơn. Tôi sẽ vui vẻ theo một công nghệ mới phù hợp với một trong hai loại. 1. Nó làm tôi phấn khích và tôi sẵn sàng dành thời gian rảnh cho nó. 2. Nó chứng tỏ bản thân thực sự tốt hơn và có vẻ như nó sẽ tồn tại đủ lâu để khiến nó đáng để đầu tư. Xu hướng không phù hợp với một trong hai loại là một canh bạc tốt nhất.
TimothyAWiseman

15

Chẳng có nghĩa gì khi rút mã "ra khỏi kệ" nếu nó hoàn thành các mục tiêu tương tự mà không phải trả thêm chi phí?

Luôn có một chi phí phụ.

Các đường cong học tập cho các công cụ kệ luôn luôn có. Nỗi đau của việc nhận được cập nhật (và phụ thuộc) luôn luôn có. Không có khả năng vít xung quanh với ruột luôn luôn có.

Đối với LINQ, lần đầu tiên chỉ thực sự áp dụng. Nhiều người cho rằng mã trông 'lạ' là khó đọc và khó gỡ lỗi hơn. Cú pháp giống như sql là khá nhiều tính cách cá nhân mỗi buổi biểu diễn chuyên nghiệp tôi đã làm việc kể từ khi nó ra mắt. LINQ to SQL (và các nguồn dữ liệu khác) có một số vấn đề và các tùy chọn tối ưu hóa hạn chế.

Đây là những lập luận chung chống lại các công cụ của bên thứ 3 và LINQ cụ thể. Tất cả những gì đã nói, LINQ là một công cụ hữu ích chết tiệt và nên được ưa thích trong hầu hết các tình huống. Khóc không được phát minh ở đây, và trừu tượng không nên được ưa chuộng mạnh mẽ của sự hỗn loạn nhận thức .

Họ không biết / không thể học LINQ, nhưng họ "rõ ràng" là những nhà phát triển giỏi, vì vậy LINQ không đáng giá. Đó là một cái bẫy phổ biến.


1
Điểm tốt. Đồng ý về các chi phí mà bạn đề cập và đó là một sự làm rõ tốt. Tuy nhiên, rộng hơn, việc phát triển các lớp học tại nhà mà không có nhân viên mới nào thể quen thuộc vì chúng không tồn tại bên ngoài tổ chức cũng có những thách thức tương tự ngoài chi phí phát triển chính.
Matt Cashatt

2
@MatthewPatrickCashatt - Ồ hoàn toàn. Do đó, mã được trồng tại nhà hầu như luôn luôn phải nỗ lực nhiều hơn cho cùng một chiến thắng, nhưng không nhất thiết phải như vậy. Giống như nhiều thứ khác, chi phí / phần thưởng nên được ước tính và ưu tiên thực hành tốt nhất , không được theo dõi một cách mù quáng.
Telastyn

@Telastyn Mã được trồng tại nhà cũng rất tốt vì bạn biết nó làm gì và có thể sửa nó trong một thông báo khoảnh khắc. Ngoài ra, bạn có thể tối ưu hóa cho các trường hợp cụ thể dựa trên việc sử dụng của riêng bạn chứ không phải trung bình của mọi người.
Hawken

13

Một điều khác bạn nên xem xét là sự nhiệt tình của bạn đối với một công nghệ mới tuyệt vời có thể chỉ đơn giản là khiến mọi người cảm thấy không thoải mái và không muốn bạn ở bên. Bạn không "trao quyền" cho họ, bởi vì chính bạn là người biết công nghệ này chứ không phải họ. Ngay cả khi chính họ không nhận ra điều đó, họ có thể đang tìm kiếm những ứng cử viên củng cố những gì họ đã đầu tư rất nhiều thời gian vào đó.

Bạn muốn thể hiện một thái độ nói rằng: "Dù bạn đang làm gì, tôi muốn giúp bạn đạt được nó", thay vì đưa ra một ẩn ý có nội dung: "Bạn có thể đang làm mọi thứ theo cách xấu, và có tôi ở bên sẽ chứng minh nó. "


+1 - cũng như nói với họ những gì bạn biết, hỏi họ những gì họ đang làm và những gì họ chuyên.
Kirk Broadhurst

12

Tôi đảm nhận điều này (và TBH tôi đoán vì không ai trong chúng tôi có thể nói những người phỏng vấn đó đang nghĩ gì) là bạn thường đến một cuộc phỏng vấn để giải thích lý do tại sao họ nên thuê bạn để phù hợp với nhóm của họ, cách làm việc của họ .

Bạn có thể là nhà phát triển hoàn hảo, một vị thần mã khởi đầu rock, nhưng điều đó hoàn toàn không có nghĩa gì nếu bạn muốn làm gì (nhấn mạnh bởi bạn nói quá mức và quá nhiệt tình về một số gubbins công nghệ tuyệt vời) chỉ đơn giản nói với họ về bạn, và bạn sẽ không phù hợp với những gì họ muốn. Nếu họ có hệ thống truy cập dữ liệu kiểu cũ, không thể nâng cấp vì bất kỳ lý do gì, họ không cần ai đó quên cách duy trì hệ thống. Nếu họ đang phát triển công cụ mới và bạn thực sự muốn đưa công nghệ mới tuyệt vời đó đi khắp mọi nơi, thì rõ ràng họ sẽ gặp vấn đề lớn với việc bảo trì mã và / hoặc đào tạo nhân viên trong tương lai.

Là một người làm việc tự do, đây không chỉ là vấn đề mà nếu họ thuê permie. Với một permie, đào tạo và phát triển các cách làm việc mới không phải là điều xấu, trong phạm vi của các quy tắc và thực hành hiện tại - bạn sẽ ở đó trong một thời gian dài để làm cho mọi thứ tốt hơn. Với một người làm việc tự do, họ thực sự không đưa ra một trò chơi khăm bạn muốn, bạn chỉ ở đó để thực hiện công việc của họ theo cách họ muốn, và đó không phải là công việc của bạn để làm bất cứ điều gì khác. (không đồng ý - trở thành nhân viên cố định)

Có lẽ nó chẳng liên quan gì đến bản thân LINQ, tôi đã từ chối một ứng cử viên bật lên và giải thích mọi thứ sẽ được viết tốt hơn như thế nào trong Haskell. Chúng tôi không làm Haskell. Điều tương tự cũng áp dụng cho bất kỳ công nghệ nào không được sử dụng bởi công ty, thường thì đó không phải là vấn đề nếu bạn đề cập đến nó như một điều gì đó tốt. Vấn đề xảy ra khi bạn quá nhiệt tình và quan tâm đến nó.


2
Tôi đồng ý với điều này, nhưng tôi đã nhận thấy rất nhiều người sử dụng thái độ này để loại bỏ những ý tưởng hay mà họ không hiểu (ví dụ: thử nghiệm, mẫu thiết kế, ORM). Vì vậy, trong khi tôi đồng ý rằng việc phù hợp với đội là một điều tốt, điều quan trọng là phải nhận ra rằng bạn có thể tốt hơn những người còn lại trong nhóm và nên tìm những người có cùng chí hướng, nơi đó không phải là điều xấu để biết điều tốt trừu tượng.
Wayne Molina

1
@WayneM chắc chắn, nhưng OP là một người làm việc tự do, vì vậy thực sự không có vấn đề gì nếu anh ta là một vị thần mã hóa, trừ khi họ chuẩn bị thuê anh ta vĩnh viễn để duy trì mã mà các thành viên còn lại không hiểu (hmm) anh ta cần phải làm những gì họ muốn, không phải những gì anh ta muốn.
gbjbaanb

1
@WayneM cũng vậy, rất nhiều người sẽ sử dụng một cái gì đó tương tự như những gì bạn vừa nói để thúc đẩy ý tưởng của họ hơn người khác (tin chắc rằng người mà họ nói chuyện chỉ đơn giản là không hiểu). Cuối cùng, cả hai bên đều thiên vị, nhưng OP là về việc được thuê, không chiến thắng trong cuộc chiến DIY / trừu tượng lớn. Mọi người sẽ có ý kiến ​​riêng của họ, nhưng ai đó phải vượt qua nó; Tôi đoán nó sẽ không phải là chủ nhân trong trường hợp này. :(
Hawken

10

Có một mối quan tâm hợp lệ mà tôi đã nghe từ những người không sử dụng Linq và đó là điều tôi rất tâm đắc: "Chỉ vì bạn không thể thấy việc triển khai không có nghĩa là nó không tốn kém".

Lấy đoạn trích sau:

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

LINQ khởi xướng ở đây đang co rúm lại. Tại sao? Bởi vì chỉ vì mã này trông đẹp và thanh lịch không có nghĩa là nó không hiệu quả khủng khiếp. Count (), với một vị từ, đánh giá mọi phần tử của cha mẹ của nó, và tính tổng số lần vị ngữ trả về đúng. Vì vậy, không chỉ N ^ 2 này (khi inputList và otherInputList có giá trị gần bằng nhau N), đây là trường hợp xấu nhất tuyệt đối N ^ 2; MỌI phần tử của otherInputList được truyền tải cho MỌI phần tử đầu vào. Thay vào đó, bước đầu tiên là sử dụng Any () thay vì Count, vì đó thực sự là những gì bạn muốn biết và nó sẽ thoát ngay khi câu trả lời được biết là "có". Thiết lập Hashset lưu trữ các giá trị riêng biệt cũng otherInputListObject.OtherPropertycó thể giúp bạn; truy cập trở thành O (1) thay vì O (N),phức tạp trường hợp xấu nhất thay vì phức tạp trường hợp tốt nhất bậc hai .

Do đó, chúng tôi thấy rằng các phương thức thanh lịch tốt đẹp này có chi phí nghiêm trọng đằng sau chúng và nếu bạn không biết những chi phí đó là gì, bạn có thể dễ dàng mã hóa thuật toán tính tương hợp O (GD của tôi) vào trình phục vụ tệp trung tâm hiệu suất cao của nhà tuyển dụng tiềm năng của bạn hoặc trang cổng đích chính vào lần tiếp theo họ có thể cần một tinh chỉnh. Bắn bạn sau khi bạn làm điều đó không hoàn tác những gì bạn đã làm, nhưng không thuê bạn nếu họ nghĩ bạn sẽ làm điều đó sẽ ngăn chặn điều đó. Vì vậy, để tránh điều này, bạn phải chứng minh họ sai; thảo luận về những gì các phương pháp đó làm (có nghĩa là bạn phải biết chính mình) và mức độ phức tạp của chúng, và làm thế nào để đi đến câu trả lời trong một thời gian hiệu quả (NlogN hoặc tốt hơn).

Một mối quan tâm khác là đối số "Khi công cụ duy nhất của bạn là một cái búa" cũ. Đặt mình vào vị trí của người phỏng vấn phỏng vấn fanboy Linq này. Ứng cử viên thích Linq, muốn sử dụng nó, nghĩ rằng đó là điều tốt nhất từng có. Thậm chí có vẻ như ứng cử viên không thể viết mã mà không có nó, vì mọi vấn đề lập trình được đưa ra đã được giải quyết với Linq. Điều gì xảy ra khi nó không thể được sử dụng? Vẫn còn rất nhiều mã .NET 2.0, nếu được nâng cấp sẽ yêu cầu nâng cấp đau đớn cho máy chủ, máy trạm của người dùng, v.v., tất cả để bạn có thể sử dụng các phương thức mở rộng ưa thích của mình. Là người phỏng vấn, tôi sẽ cố gắng để bạn chứng minh rằng bạn có thể mã hóa một loại sắp xếp hiệu quả hoặc sử dụng các phương pháp sắp xếp 2.0 nếu bạn phải, bất kể tôi có thể đồng ý với bạn bao nhiêu rằng các thư viện Linq và các phương thức mở rộng tương tự đều đẹp ngọt. Một người phỏng vấn không nhìn thấy điểm có thể thậm chí không bận tâm đến việc cố gắng khiến bạn thể hiện năng khiếu cho bất cứ điều gì khác; họ sẽ cho rằng bạn không có nó và tiếp tục.


Tại sao bạn không viết câu hỏi của bạn var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));? Tôi có thể đã làm hỏng điều đó, nhưng quan điểm của tôi là LINQ có cách thực hiện truy vấn tốt hơn mà bạn đề cập ở trên (.Join () là một cách khác). Tôi nhận ra rằng có nhiều cách để sử dụng LINQ có thể không thành thạo như các cách khác, nhưng điều đó không có nghĩa là bạn phải dựa vào những triển khai tồi đó.
Matt Cashatt

4
@MatthewPatrickCashatt Tôi không nghĩ rằng quan điểm của anh ấy rất nhiều khi cho rằng LINQ luôn không hiệu quả - trong khi bạn luôn có thể đánh bại một truy vấn LINQ nhất định, một số cách sử dụng cho hiệu suất tốt hơn mỗi giờ của nhà phát triển so với nhiều cách tiếp cận không phải LINQ. Thay vào đó, nó có thể là tương đối dễ dàng để viết một truy vấn LINQ rằng không hiệu quả và không nhận ra nó, bởi vì sự thiếu hiệu quả không phải là trắng trợn.
Jon Hanna

3
@JonHanna: Có lẽ nhiều hơn, giá trị của sự trừu tượng sẽ giảm đi rất nhiều nếu người ta phải kiểm tra xem mã nào đang "thực sự làm" để xác định kịch bản không phổ biến nào có thể khiến hiệu suất trở nên tồi tệ hơn nhiều so với dự kiến. Nếu thay đổi từ cấu trúc dữ liệu này sang cấu trúc dữ liệu khác sẽ khiến mã chạy chậm hơn 10.000 lần, khả năng thực hiện thay đổi đó mà không thay đổi bất kỳ mã nào khác có thể không phải lúc nào cũng là một điều tốt.
supercat

1
@supercat: có và không. Chỉ vì kiến ​​thức về cách thực hiện một cái gì đó trong việc triển khai của bên thứ ba là rất quan trọng để hiểu được ý nghĩa hiệu suất và tránh sự thiếu hiệu quả, không có nghĩa là các thư viện đóng gói các công cụ này có giá trị thấp hơn. Đó là hai mặt của cùng một đồng tiền; biết bản chất của việc thực hiện và bạn có thể sử dụng nó với một vài lần nhấn phím thay vì một giờ tự lăn. Nhưng, bạn phải biết cả hai mặt, và fanboy Linq khuôn mẫu, người nghĩ rằng nó hoàn hảo, không có gì sai, sử dụng nó cho mọi thứ có thể không.
KeithS

@KeithS: Một điều tôi nghĩ là vô cùng thiếu trong cả Java và .net là một phương tiện tiêu chuẩn để hỏi các đối tượng hoặc bộ sưu tập nhiều thứ khác nhau về bản thân họ. Ví dụ: mã nhận được bộ sưu tập có thể đếm được có thể có lợi từ việc biết liệu số lượng vật phẩm và / hoặc chuỗi các mặt hàng hiện tại có thể thay đổi hay không, cho dù số lượng vật phẩm được biết là hữu hạn hay vô hạn (hoặc không biết theo cách nào), và liệu bộ sưu tập vốn có biết có bao nhiêu mặt hàng trong đó hay không. Các công nghệ như LINQ thường phải đưa ra các giả định về những điều như vậy có thể đúng hoặc không chính xác, và ...
supercat

10

Cái này hơi dài, nhưng nó có thể hữu ích cho ai đó nên tôi sẽ để nó.

Tôi thực sự đã gặp một cái gì đó tương tự, trải qua hơn 20 cuộc phỏng vấn vào tháng trước (một sự pha trộn giữa điện thoại và mặt đối mặt). Chắc chắn có điều gì đó bất ngờ xảy ra mà tôi không thể đặt ngón tay lên.

Một trong những điều tôi nhận thấy là những điều thường là trung tâm của các chu kỳ phỏng vấn trong năm hoặc sáu năm qua đã được quyết định không được thảo luận hoặc đưa ra ngắn hạn. Những thứ như các nguyên tắc cơ bản của phân tích / thiết kế OOP, các mẫu (cả thiết kế và kiến ​​trúc), một số tính năng .net tiên tiến / trừu tượng hơn (bao gồm lambdas hoặc LINQ cụ thể, tổng quát, liên kết / liên kết dữ liệu và tương tự), và thậm chí thường là chủ đề nóng của phương pháp luận ưa thích (dường như không ai quan tâm nhiều đến agile vs thác hay hương vị của agile) và các công cụ hoặc lựa chọn ORM hoặc phương tiện hợp tác ưa thích hoặc quản lý kiểm soát nguồn. Trong một số trường hợp không được đề cập ở tất cả, trong hầu hết các trường hợp dường như không quan tâm.

Những gì đã nhận được trọng tâm, trong nhiều cuộc phỏng vấn và các công ty không liên quan khác nhau trong các ngành công nghiệp không liên quan, đã dọc theo những dòng này:

  • Một bản sửa lỗi kỳ lạ về những quy ước đã lỗi thời / lỗi thời và những hạn chế "trở lại thời kỳ đồ đá". Giống như phát triển một ứng dụng web nguyên thủy trong VS2003 với một danh sách các hạn chế vô lý tiếp tục cấm sử dụng phạm vi tính năng rõ ràng trong thời đại đó .net ... như thể đó là thước đo thực sự về khả năng của nhà phát triển hiện đại ... khả năng ghi nhớ mô hình và những hạn chế của 9 năm trước càng bị tê liệt bởi những ràng buộc không thực tế / tùy tiện. Một nơi khác đã rất chú trọng đến chủ đề của các bộ sưu tập tùy chỉnh, các bộ sưu tập tiền chung. Một nơi khác đã lấy mẫu mã của mô hình lớp mà tôi đã vẽ nguệch ngoạc vì tôi không sử dụng các hàm tạo xếp tầng (họ dường như không biết về sự hỗ trợ cho việc khởi tạo thuộc tính khi khai báo, đủ cho nhu cầu).

  • Tập trung cao độ vào các chi tiết triển khai cụ thể trong cài đặt cấu hình và / hoặc cấu hình vi mô, ngay cả trong trường hợp các công nghệ tập trung vào bất khả tri về nền tảng hoặc giao thức (ví dụ: toàn bộ vấn đề là KHÔNG được sửa chữa trong việc triển khai cụ thể hoặc sử dụng cụ thể mà thay vào đó về tái sử dụng / tái sử dụng / mở rộng / tích hợp khi cần thiết).

  • Sẵn sàng chỉ định / giám sát / đánh giá mã / và nếu không thì sẽ giải quyết công việc đến và từ một nhóm ngoài khơi và các kỹ năng không mã hóa liên quan đến việc đó.

  • Sử dụng các phiên bản cụ thể của sản phẩm / nền tảng / mô-đun / vv Ở mức độ đôi khi vô lý; "Vậy ... bạn đã sử dụng các phiên bản 1, 2 và 4? Nhưng không phải 3, eh? Hmmm ... {chú thích hồ sơ của bạn với" không v3 !!!} ". Mức độ sử dụng dường như không quan trọng; chỉ có điều bạn chưa hoặc chưa sử dụng thứ gì cả , và điều cụ thể mà họ đang yêu cầu cũng ... không có sự thay thế nào được tính, ngay cả một sản phẩm cạnh tranh được sử dụng rộng rãi và đầy đủ tính năng.

  • Một sự tập trung lớn hơn nhiều vào "bạn sẽ phù hợp với nhóm của chúng tôi đến mức nào" hơn "bạn có thực sự là một nhà phát triển phần mềm" hay "bạn có kỹ năng và kinh nghiệm để tăng giá trị cho công ty và giúp chúng tôi cung cấp chất lượng không sản phẩm "hoặc thậm chí" bạn là một tên ngốc nguy hiểm sẽ đến và phá hỏng cửa hàng ". Trong một số trường hợp, sơ yếu lý lịch của tôi chỉ được thực hiện và thậm chí cái gọi là "màn hình công nghệ" hay phỏng vấn kỹ thuật là một đánh giá tính cách hơn nhiều so với đánh giá kỹ năng. Ngay cả đối với các vị trí hợp đồng tương đối ngắn hạn, nơi bạn sẽ ở đó và trở lại trước khi hai mùa thay đổi.

  • Các công ty thời gian này dường như ít tập trung vào giải quyết các vấn đề kỹ thuật cụ thể, bắt đầu các dự án phát triển lĩnh vực xanh hoặc 2.0 lớn mới, hoặc đưa một sản phẩm cụ thể ra thị trường để tận dụng xu hướng hoặc cơ hội mới nổi, hoặc các cú hích lớn thông thường . Một chủ đề lặp đi lặp lại mà tôi nhận thấy ít nhất 15 nơi là một nhóm nhỏ 3-5 nhà phát triển, chủ yếu là những người sống sót sau vụ sụp đổ thị trường vào năm 08, đã có thể nghiền nát một sản phẩm trong suốt 3 năm qua. và tìm thấy một số thành công hoặc toàn bộ công ty của họ đang bùng nổ và họ đang thuê những người mới để đáp ứng nhu cầu tính năng ngày càng tăng hoặc giải quyết / khắc phục các lỗi thiết kế mà họ xây dựng trong các hệ thống này hoặc để tiếp nhận các nền tảng đã nói ở trên lên đội ngũ nòng cốt đã xây dựng nó để thực hiện "các dự án khác".

Nhưng ... nếu có một điều tôi biết về doanh nghiệp này thì đó là theo chu kỳ. Lần tới khi tôi tìm kiếm một buổi biểu diễn mới, tôi sẽ không ngạc nhiên nếu trò chơi đã thay đổi một lần nữa. Bạn chỉ cần duy trì sự linh hoạt về tinh thần, lắng nghe tích cực, tránh đưa ra những tuyên bố tuyệt đối nếu chúng không cần thiết nhưng cũng đừng là một con chồn, và đừng trở thành một chiều (bạn là một thằng ngốc hoặc một người nhiệt tình, không mong muốn) hoặc là quá tốt (nó có thể đe dọa và khiến bạn phải trả giá một buổi biểu diễn).

Chỉ cần điều chỉnh cách tiếp cận của bạn và cố gắng đưa ra phản hồi đo lường hơn vào lần tới ... đề cập đến một vài cách khác nhau mà bạn có thể tiếp cận vấn đề ... nhưng ngay cả khi đó là kiến ​​thức vẹt cho bạn hành động như thể bạn đang thực sự nghĩ về nó và lý do nó ra tại chỗ. Nó có vẻ khiêm tốn hơn và ít đáng sợ hơn hoặc tắt theo cách đó.

Tất nhiên, Luật Murphy là nó là gì, cuộc phỏng vấn hôm sau sau khi bạn ngừng là "đam mê anh chàng công nghệ yêu thích hiện tại của tôi" và thông qua một / râu-vuốt ve lập trường cân bằng hơn là buổi biểu diễn mà bạn sẽ đã nhận đã bạn được sự điên cuồng anh chàng sốt sắng. ;)


6

Tôi nghĩ rằng bạn đang rút ra một kết luận sai, bởi vì bộ mẫu của bạn quá hạn chế. Mặc dù tôi đã thấy một phần lớn các cửa hàng CNTT có ác cảm mạnh mẽ với bất cứ thứ gì "không được phát minh ở đó" 1 , nhưng không ai trong số họ sẽ loại bỏ các ứng viên dựa trên sở thích của họ trong ngăn xếp công nghệ: họ tin chắc rằng họ có thể dạy đúng ứng viên thư viện trồng tại nhà của họ.

Tôi thực sự nghi ngờ rằng công ty đã cấm sử dụng LINQ hoàn toàn. Nhiều khả năng, họ muốn bạn cho họ thấy các kỹ năng của bạn ở mức độ sâu hơn.

Ví dụ, một cách để tìm hiểu xem bạn có biết các bảng băm của mình hay không là yêu cầu bạn thực hiện một bảng nguyên thủy trên bảng trắng. Bài tập đơn giản này tiết lộ một lượng dữ liệu đáng ngạc nhiên về kiến ​​thức của bạn cho người đánh giá: anh ta sẽ học ngay nếu bạn biết về mã băm / bằng và những gì bạn biết về va chạm băm. Đồng thời, thật khó để tưởng tượng ai đó trong tâm trí của họ đang thực hiện lại một bảng băm, bởi vì Microsoft đã làm rất tốt công việc đó. Điều tương tự cũng xảy ra với nhiều thuật toán, chẳng hạn như sắp xếp và tìm kiếm: người phỏng vấn thường muốn biết liệu nền tảng của bạn có đủ để hiểu các tương tác cấp thấp hay không, thay vì kiểm tra xem bạn có kiến ​​thức làm việc về các thư viện .NET hay không.

Một điều gần như chắc chắn là họ sẽ khăng khăng yêu cầu bạn sử dụng các triển khai thư viện hơn là của riêng bạn một khi bạn được thuê để làm việc cho công ty của họ. Nhưng trong cuộc phỏng vấn, họ sẽ đẩy bạn về phía mã cấp thấp để hiểu rõ hơn về khả năng thực sự của bạn.


1 cửa hàng đã đi xa như việc xây dựng công cụ xây dựng khá nguyên thủy của riêng mình!


2
Tất cả các điểm của bạn đều được thực hiện tốt, nhưng tôi nên cung cấp cho bạn một số màu sắc xung quanh cuộc phỏng vấn cuối cùng: người phỏng vấn nhấn mạnh rằng LINQ đã bị "phản đối". Tôi đã hỏi, "không phải ý bạn là MS sẽ không còn đầu tư vào Linq-to-SQL nữa mà Linq-to-Entities sẽ xuất hiện" và câu trả lời của anh ấy là ý anh ấy nói: LINQ đang bị "phản đối" vì vậy, không tôi không nghĩ rằng anh ta biết quá nhiều về LINQ hoặc sẽ khăng khăng sử dụng nó.
Matt Cashatt

1
@MatthewPatrickCashatt Nếu ai đó nhầm lẫn LINQ cho LINQ2Query về mặt công nghệ bị phản đối, tôi đã tạo ra một lý do ngớ ngẩn để rời khỏi cuộc phỏng vấn sớm và không bao giờ gọi công ty đó trở lại. Nếu đó thực sự là trường hợp, bạn nên vui vì họ không thuê bạn :)
dasblinkenlight

1
Chắc chắn 100% đó là trường hợp. Trên thực tế, tôi không thể cưỡng lại việc gửi cho anh ấy một số liên kết để đưa anh ấy đi đúng hướng, không phải là một trò hề vì tôi không nhận được hợp đồng biểu diễn, nhưng vì tôi thực sự cảm thấy xấu hổ cho anh ấy và hy vọng rằng tôi có thể giúp anh ta không mắc lỗi tương tự hai lần;).
Matt Cashatt

4
Sau đó, điều này dường như ít liên quan đến ngăn xếp công nghệ và nhiều hơn để làm với thực tế là bạn đã sửa chữa anh ta. Mọi người không muốn được sửa chữa. Đó chỉ là bản chất của con người. Khi mọi người đưa ra quyết định như thuê người, 99% sẽ đi theo trực giác của họ. Họ đi bằng việc bạn có khiến họ cảm thấy những cảm xúc tích cực hay tiêu cực hay không. Sửa chữa anh ta có thể đã khiến anh ta cảm thấy những cảm xúc tiêu cực. Và sau đó anh ta liên kết sự tiêu cực đó với tình hình.
viên

1
Tôi không biết làm thế nào hashtables hoạt động trong nội bộ. Tuy nhiên, các bài kiểm tra kỹ thuật sâu sắc như vậy sẽ loại bỏ những người được đào tạo thực tế có đầu óc là những ứng cử viên tốt. Yêu cầu mọi người phải có kiến ​​thức cấp thấp, họ sẽ không bao giờ sử dụng dường như không cần thiết đối với tôi. Nguyên tắc thiết kế đã trở nên quan trọng hơn nhiều!
Tjaart

4

Tôi nghĩ rằng bạn đang thực hiện một số khái quát điên rồ ở đó "Tôi thấy một con bò đen ở Scotland, vì vậy tất cả những con bò Scotland đều màu đen".

Nếu tôi phỏng vấn bạn, tôi sẽ thất vọng nếu bạn không thể trả lời các câu hỏi linq của tôi.

Linq là một mánh khóe, rất nhiều người coi đó là voodoo, điều đó không công bằng vì nó thực sự rất đơn giản và thông minh hơn cho nó.


3

Để chơi người ủng hộ của quỷ, lý do là nhiều nhà phát triển không quan tâm đến những điều mới và nghĩ rằng mọi thứ phải được giải quyết bằng các công cụ trong nhà (thường là kém hơn). Không có gì sai khi sử dụng trừu tượng. Địa ngục, thường không có lý do chính đáng để không sử dụng những trừu tượng đó.

Có vẻ như bạn vừa phỏng vấn một nhà phát triển nghèo, không cập nhật mọi thứ và tiếp cận mọi thứ. Đây là những loại nhà phát triển không biết gì về các công cụ nguồn mở hữu ích như NUnit hoặc NHibernate hoặc các bộ chứa IoC khác nhau; những người cố gắng giải quyết mọi vấn đề với một kho lưu trữ khổng lồ trong cơ sở dữ liệu; những người hoàn toàn không biết gì về MVC mặc dù đã ra mắt được vài năm rồi.


Bạn có thể ném LINQ vào một nhóm từ thông dụng có chứa Nhibernate, v.v ... Tôi sẽ không làm điều đó. Trên thực tế, tôi nghĩ rằng buzzwords minh họa cho việc chúng ta không thể giải thích sự trừu tượng thành các biểu thức thích hợp.
AndreasScheinert

Bạn đang nói về "giữ cho đến nay" tôi nghĩ rằng wOuld nghịch đảo sẽ phù hợp hơn rất nhiều. Nhiều khái niệm hữu ích đã được phát hiện và sử dụng trong quá khứ, ví dụ như DSL. Tùy thuộc vào chúng tôi để cải thiện giao tiếp và nắm bắt các khái niệm như chúng tôi không cần phải phát minh ra các từ buzz mới cho các khái niệm cũ.
AndreasScheinert
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.