Làm thế nào phổ biến cho một nhóm để viết mọi thứ trong nhà? [đóng cửa]


53

Trong một cuộc phỏng vấn gần đây, tôi đã hỏi những người phỏng vấn "làm thế nào để bạn đánh giá các công nghệ và thư viện mới (như SignalR) và đưa chúng vào sử dụng?". Họ nói họ không, thay vào đó họ tự viết mọi thứ để họ không phải dựa vào ai khác.

Công ty không làm việc cho chính phủ hoặc các nhà thầu quốc phòng hoặc trong bất kỳ dự án quan trọng nào về an toàn hoặc bất cứ điều gì tương tự. Họ chỉ là công ty phát triển phần mềm cỡ trung bình, trung bình của bạn.

Câu hỏi của tôi là: làm thế nào phổ biến cho các đội để tự viết mọi thứ? Tôi có nên được quan tâm bởi các đội làm?

Chỉnh sửa - Hầu hết mọi phản hồi đều cho biết đây là điều cần được quan tâm. Một cuộc phỏng vấn thứ hai sẽ là thời điểm thích hợp để yêu cầu họ làm rõ / lặp lại vị trí của họ trong việc viết mọi thứ trong nhà?


58
Lá cờ đỏ khổng lồ. Bình tĩnh bước đi và không di chuyển bất ngờ.
tdammers

16
Tôi không nghĩ điều này là vô lý như mọi người nói ... Gần đây tôi đã lãng phí một lượng thời gian đáng kinh ngạc để sửa các thư viện bị bỏ rơi cho các phiên bản khung mới, các phiên bản mới của thư viện với những thay đổi nghiêm trọng không được ghi lại và thậm chí là những khoảng trống lớn trong các khung công tác quan trọng như jQuery khiến chúng không phù hợp với mục đích. Mọi người không đặt đủ nỗ lực vào việc quyết định xem các thành phần của phần thứ ba có thêm chi phí bảo trì lớn hay không và thường kết thúc với một địa ngục phụ thuộc spaghetti không thể nhầm lẫn.
Daniel Tuppeny

4
NuGet là tuyệt vời, nhưng làm cho nó rất dễ dàng để làm điều này. Tôi đã cài đặt một số thư viện trợ giúp tầm thường từ NuGet gần đây, và nó đã kéo vào Castle và tất cả các loại nhảm nhí khác. Chắc chắn rồi; một lệnh cấm hoàn toàn là lạ, nhưng nó không ngu ngốc hơn việc cho phép mọi nhà phát triển và con chó của mình ngẫu nhiên kéo đồ vào mà không cần suy nghĩ thực sự.
Daniel Tuppeny

13
Mọi điều? Có bao gồm trình duyệt, hệ điều hành và trình biên dịch riêng của họ không? Nếu không thì họ chỉ đang tự lừa dối mình.
Muhammad Alkarouri

4
Tất nhiên nó vô lý như mọi người nói. Thực tế là a) có thể chọn thư viện sai cho công việc và b) có những tình huống không có thư viện bên thứ ba nào đáp ứng nhu cầu của bạn tốt hơn so với thư viện nội bộ: không có nghĩa là chính sách không bao giờ sử dụng bên thứ ba thư viện là chính xác.
dùng16764

Câu trả lời:


76

Một thái độ không bao giờ sử dụng các thư viện của bên thứ ba là vô lý. Tự viết mọi thứ là một cách sử dụng thời gian của công ty bạn một cách khủng khiếp, trừ khi có một yêu cầu kinh doanh nghiêm ngặt là mọi dòng trong cơ sở mã được viết bởi một nhân viên của công ty - nhưng đó là một kịch bản bất thường, đặc biệt đối với một công ty thuộc khu vực tư nhân như bạn đã mô tả.

Một câu trả lời hợp lý và kỹ lưỡng hơn có thể là họ sẽ chỉ sử dụng các thư viện của bên thứ ba:

  • Đáp ứng nhu cầu của mã họ sẽ tự viết
  • Đã có sẵn theo giấy phép tương thích với mô hình kinh doanh của công ty
  • Bao gồm các bài kiểm tra
  • Đã qua đánh giá mã

Nếu các tiêu chí đó được đáp ứng (và theo kinh nghiệm của tôi, đánh giá mã rất linh hoạt, đặc biệt là khi có các bài kiểm tra tốt), bạn không còn "dựa vào ai khác" - bạn đang dựa vào hiện có, sẵn có và tốt nhất là mạnh mẽ mã.

Nếu mã là nguồn mở, thì trong trường hợp xấu nhất, thư viện bên thứ ba sẽ không được xác định. Nhưng, ai quan tâm? Các bài kiểm tra chứng minh rằng thư viện phù hợp với nhu cầu của bạn!

Hơn nữa, ác cảm với các thư viện bên thứ ba được thành lập gây cản trở nghiêm trọng đến năng suất của lập trình viên. Giả sử công ty đã viết các ứng dụng web và từ chối sử dụng (ví dụ) jQuery, vì vậy thay vào đó đã viết thư viện trình duyệt chéo thay thế của riêng họ để đơn giản hóa thao tác DOM. Với sự chắc chắn gần như chúng ta có thể giả định rằng việc thực hiện của họ:

  • Sẽ có một API nước ngoài cho các nhà phát triển đã quen thuộc với jQuery
  • Sẽ không được ghi chép tốt như jQuery
  • Sẽ không có kết quả Google có liên quan khi gặp sự cố khi sử dụng thư viện
  • Sẽ không được kiểm tra thực địa như jQuery

Tất cả những điểm đó là rào cản lớn đối với năng suất lập trình viên. Làm thế nào một doanh nghiệp có thể đủ khả năng để từ bỏ năng suất như vậy?


Bạn đã cập nhật câu hỏi của mình để hỏi liệu điều này có phù hợp để đưa ra trong một cuộc phỏng vấn thứ hai không. Nó là hoàn toàn.

Có thể bạn giải thích sai câu trả lời của người phỏng vấn trong cuộc phỏng vấn đầu tiên, hoặc có thể người phỏng vấn chỉ giải thích không chính xác vị trí của công ty và một người phỏng vấn mới có thể làm rõ điều đó.

Nếu bạn giải thích rằng bạn lo ngại về lập trường của họ đối với các thư viện bên ngoài, có ít nhất hai kết quả có thể xảy ra:

  • Họ sẵn sàng thay đổi và mối quan tâm của bạn về quy trình của họ khiến bạn trông đẹp hơn một số ứng cử viên khác.
  • Họ không sẵn sàng thay đổi và họ nghĩ bạn là "loại nhà phát triển mà chúng tôi không muốn thuê." Không quan trọng, đó không phải là nơi bạn muốn làm việc.

1
+1 nhưng tôi nghĩ bạn có nghĩa là khu vực tư nhân , không phải khu vực công cộng .
MarkJ

6
"Nếu mã là nguồn mở, thì trong trường hợp xấu nhất, thư viện bên thứ ba trở nên không rõ ràng. Nhưng ai quan tâm? Các thử nghiệm chứng minh rằng thư viện phù hợp với nhu cầu của bạn!" Bạn cũng có mã nguồn, điều này đặt bạn vào vị trí có những gì bạn đang sử dụng và có thể cập nhật nó để đáp ứng bất kỳ nhu cầu nào trong tương lai. (Vâng, làm quen với cơ sở mã "người ngoài hành tinh" cần có thời gian, nhưng việc tự lăn lộn cũng vậy.)
CVn

34

Điều đó dường như vô cùng không cạnh tranh. Tôi đã làm việc trong các cửa hàng quyết định bỏ qua các thư viện nguồn mở tiêu chuẩn như Hibernate và tự cuộn do một số tính năng thiếu "quan trọng". Cuối cùng, phần mềm rất tốn kém để xây dựng và bảo trì. Tất nhiên, chi phí của thư viện nội bộ đã bị đánh giá thấp. Và trong khi thư viện nội bộ được viết, các thư viện tiêu chuẩn đã phát triển nhanh chóng, thêm các tính năng mới không có sẵn trong thư viện nội bộ. Cuối cùng, công việc sẽ mất một giờ bằng thư viện tiêu chuẩn thay vì mất hai ngày. Và điều đó thật tệ cho sự nghiệp của các nhà phát triển, khi thế giới đi qua họ. Tôi sẽ tránh một cửa hàng như thế. Tôi muốn giao hàng và không đủ kiên nhẫn để viết lại khi tôi có thể sử dụng lại.


2
Vì các nhà phát triển không còn có các kỹ năng liên quan cho các công việc khác, tiền của công ty bị mất trong thời gian phát triển kéo dài đã được tiết kiệm bằng cách không phải thay thế các thành viên trong nhóm rời đi! #stratgey
Michael

@Michael: Những người duy nhất họ có thể giữ lại là những người có mặt trong quyết định ban đầu để tạo ra các khuôn khổ nội bộ. Những người thuê mới có xu hướng rời đi sau khoảng một năm.
kevin cline

</ itwasaweakjoke>
Michael

+1 Nếu tính năng bị thiếu thực sự, thực sự, rất quan trọng: sửa đổi thư viện nguồn mở và đóng góp tính năng này vào nguồn chính. Cung cấp giá trị kinh doanh tuyệt vời, làm cho mọi người cảm thấy tốt và thật tuyệt vời cho CV của mọi người vì giờ đây họ đã đóng góp nguồn mở.
MarkJ

@MarkJ: nhưng nếu thay đổi bị từ chối, ai đó sẽ có một bản ngã thâm tím.
kevin cline

20

Cửa hàng có một căn bệnh gọi là Không phát minh ở đây . Đó là một lý do tốt để chấm dứt cuộc phỏng vấn tại chỗ và rời đi ngay lập tức. Điều này chỉ có thể được chữa khỏi bằng cách làm sạch nhà từ trên xuống rất khó xảy ra.

Để trả lời câu hỏi của bạn, thật đáng buồn, phổ biến hơn nhiều so với bạn nghĩ và đó chắc chắn là một lý do để được quan tâm.


15

Vâng, chắc chắn được quan tâm! Đó là sự kiêu ngạo và (xin lỗi để được khắc nghiệt) ngu ngốc. Bất kỳ lập trình viên nào có nửa bộ não sẽ sử dụng một thư viện như signalR thay vì tự viết nó. Hoàn toàn không có điểm nào trong việc lãng phí thời gian của bạn để giải quyết một vấn đề đã được giải quyết. Tôi có thể sẽ cố gắng tìm hiểu thêm thông tin trước - họ có thể đã hiểu lầm bạn (có thể khó khăn nếu cuộc phỏng vấn kết thúc!)


11

Tôi có một vài người bạn có cả hai (một thời gian ngắn) làm việc tại các nhà phần mềm không có hội chứng ở đây . Vì vậy, tâm lý là ra khỏi đó.

Một quan sát mà cả hai thực hiện là xung quanh văn hóa, cách tiếp cận được thúc đẩy trong các nhóm phát triển. Cả hai cuối cùng đã làm việc với những người khá tầm thường về quan điểm phát triển phần mềm và những người không thực sự được thúc đẩy để học những điều mới và thúc đẩy chất lượng. Bất kể bạn đang ở giai đoạn nào trong sự nghiệp, bạn luôn muốn được làm việc ở đâu đó nơi bạn có cơ hội học hỏi những điều mới từ các đồng nghiệp. Tuy nhiên, loại môi trường này dường như thường không được tìm thấy ở những nơi muốn tự cuộn mọi thứ.


+1 một trong những lý do chính khiến tôi chuyển từ chủ nhân trước đây!
Antony Scott

5

Nó không phổ biến ở nơi tôi sống và tôi biết rất nhiều công ty mặc dù là đồng nghiệp. Tôi sẽ đi xa để nói rằng đó là "không, cảm ơn" ngay lập tức từ tôi.

Tôi sẽ không lấy lại những điểm tốt đã làm, nhưng tôi sẽ thêm một điều.

Họ vừa làm cho việc tuyển dụng trở nên khó khăn hơn rất nhiều.

  • Tất cả các nhân viên mới có một đường cong học tập thậm chí còn dốc hơn chỉ là phần chính của phần mềm / miền
  • Các ứng cử viên tốt nhất sẽ bị loại vì họ sẽ không muốn các kỹ năng của họ trở nên không được sử dụng.
  • Mọi người sẽ không thể ở lại lâu khi họ nhận ra rằng việc sử dụng các công cụ yêu thích của họ tệ đến mức nào và doanh thu của nhân viên rất đắt

Bây giờ tất nhiên sẽ có những người thích thử thách, nhưng tôi nghĩ họ sẽ thuộc thiểu số.

Và tương tự, sẽ có một số công ty hoạt động trên "quy mô Internet", Amazon, Facebook, v.v., nơi họ có nhu cầu tùy chỉnh điên rồ, nhưng một lần nữa những công ty này lại chiếm thiểu số.


4

Tôi không nghĩ rằng một công ty phần mềm có thể tồn tại đến ngày hôm nay mà không cần dựa vào bên thứ ba và / hoặc phần mềm nguồn mở, và để duy trì tính cạnh tranh, tất nhiên họ cần phải chủ động theo dõi các công nghệ mới. Tuy nhiên, thường có những lý do chính đáng để có ít nhất một cái nhìn khá phòng thủ về nó.

Ví dụ: nếu bạn bán phần mềm và yêu cầu cung cấp hỗ trợ 24/7 và cũng chịu trách nhiệm về mặt pháp lý để phần mềm của bạn hoạt động chính xác, thì bạn cần có ý tưởng rất chính xác về những gì sẽ xảy ra nếu có vấn đề với bạn phần mềm trong một nhà máy trong đó 1 giờ ngừng sản xuất có thể tốn vài triệu đô la, và sau đó một lỗi nghiêm trọng xảy ra trong thư viện nguồn mở mà bạn đang sử dụng. Tin tôi đi, bạn sẽ thực hiện các đánh giá rất kỹ lưỡng về phần mềm đang đề cập.

Tuy nhiên, từ những gì bạn đã viết thì kịch bản này dường như không phải là cốt lõi của vấn đề.


4

Nếu bạn là một công ty dựa trên công nghệ có quy mô nhất định, có vẻ như bạn sẽ phát triển ngày càng nhiều công nghệ của riêng mình, ví dụ: google phát triển rất nhiều nếu không phải hầu hết các phần mềm của họ trong khi mở nguồn phần lớn trong việc theo đuổi để làm cho nó một tiêu chuẩn công nghiệp.

Đối với các công ty nhỏ hơn, có vẻ như sẽ lãng phí thời gian khi họ cố gắng vận chuyển một sản phẩm cụ thể với logic kinh doanh của riêng mình và theo kinh nghiệm của tôi, tôi đã không thấy rằng các công ty vừa và nhỏ làm như vậy.

Nó trở nên phức tạp hơn khi bạn nói về cơ sở mã chuyên dụng, ví dụ: thuật toán mã hóa - một số người có hiểu biết cơ bản về cách họ làm việc, nhưng các phần phức tạp của việc thực hiện một giải pháp có vẻ như tự bắn vào chân bạn trừ khi bạn thuê một nhà mật mã học chuyên về những thứ đó.

Một số công ty cho phép tự do tạo ra các dự án nguồn mở của riêng bạn, có vẻ phù hợp hơn.

Cá nhân tôi sẽ không đi đến một nơi có văn hóa như vậy.


1

Những gì bạn có là một cơ hội thực sự tốt để đi vào cuộc phỏng vấn thứ hai và hỏi họ một số câu hỏi khó. Tôi không biết công ty làm gì nên rất khó để nói tại sao điều này có vẻ là một lựa chọn kỳ lạ. Bạn có thể sử dụng nhận xét của @Daniel Pryden liên quan đến việc sử dụng thư viện của bên thứ ba của Google.

Bất kỳ phần mềm nào bạn sử dụng, cho dù là nội bộ hoặc từ bên thứ ba đều có những ưu điểm và nhược điểm. Không sử dụng một công cụ vì nó không phải là công cụ, ngay cả khi đó là công cụ tốt nhất cho công việc cho thấy một tư duy khép kín nhất định và điều đó sẽ không bao giờ khuyến khích sự đổi mới và sáng tạo.

Có lẽ mặc dù, có lẽ, bạn là người giới thiệu sự thay đổi đó. Chúc may mắn với tất cả mọi thứ.


-3

Tất nhiên bạn nên bỏ đi. Tôi chưa thấy nó được đề cập ở đây, nhưng lý do lớn nhất để vượt qua công việc là vì bạn sẽ không đạt được nhiều kỹ năng chuyển nhượng.

Hãy tưởng tượng tại cuộc phỏng vấn tiếp theo của bạn khi họ hỏi bạn đã làm việc với công nghệ nào và bạn chỉ có thể đề cập đến xương trần C ++ .. Nghe có vẻ như trình độ sau đại học


"Tôi chưa thấy nó được đề cập ở đây" - bạn có nhìn vào các câu trả lời khác không, ví dụ như ở câu hỏi này ?
gnat

3
Sẽ không đạt được nhiều trong các kỹ năng? Đó là sự tráo trở. Điều đó chỉ đúng nếu bạn xem lập trình như chơi với các khối Lego, xếp các thành phần lại với nhau. Nếu bạn phải 'phát minh lại' một thư viện, bạn sẽ học được rất nhiều điều về một chủ đề cụ thể.
GrandmasterB

@GrandmasterB Bạn đúng, cho phép tôi làm rõ - Rất nhiều nơi hỏi bạn đã làm việc với công cụ nào. Cơ hội bị bỏ qua của bạn cao hơn nhiều nếu các ứng cử viên khác có thể bắt đầu chạy trong khi bạn phải học lại từ đầu.
Martin Konecny

-9

Các công ty lớn tự viết mọi thứ.

Có một số lợi thế khi tự viết nó:

  1. Bạn được đảm bảo sở hữu phần mềm cho mình
  2. Bạn có thể tính toán chính xác số lượng công việc đã tạo ra nó
  3. Lặp lại các bước của bạn trở nên có thể ngay cả khi lần sau libs không có sẵn
  4. Nó cắt giảm sự phình to yêu cầu của bạn
  5. Bạn không lặp lại những gì người khác đã làm
  6. Bạn được đảm bảo có đủ người để duy trì nó
  7. Bạn có thể sửa đổi mọi phần của phần mềm
  8. Kích thước phần mềm bị giới hạn bởi số lượng tài nguyên bạn có

Đây là cách mỗi điểm bị phá vỡ nếu bạn sử dụng thư viện của ai đó:

  1. Một người khác sở hữu lib
  2. Bạn không biết bao nhiêu nỗ lực đã tạo ra lib
  3. Phiên bản sản phẩm tiếp theo của bạn không thể tạo trên nền tảng mới vì các lib tương tự không còn khả dụng
  4. Khả năng thực hiện yêu cầu phụ thuộc vào việc lib thực hiện nó từ nhiều năm trước
  5. Một số người khác cũng sử dụng cùng một lib, nhận được các giới hạn và tính năng tương tự
  6. Vì bạn không tạo libs, bạn không có đủ người để duy trì tất cả phần mềm trong sản phẩm của mình
  7. Libs là nhị phân, không thể thay đổi. Ngay cả khi nguồn có sẵn, bạn không có đủ người để sửa đổi số lượng lớn mã đó.
  8. Duy trì mã bạn đã tạo + các lib là nỗ lực lớn hơn bạn ước tính ban đầu

7
Không phải phần mở rộng hợp lý của các đối số này cũng sẽ viết trình biên dịch của riêng bạn (có thể cho ngôn ngữ của riêng bạn), chạy phần mềm này trên hệ điều hành của riêng bạn và có thể cũng xây dựng CTNH của riêng bạn?
timday

4
1: Có và tôi có thể trả một khoản phí để sử dụng nó (mà không tốn tiền để xây dựng nó theo cách chênh lệch chi phí). 2: Nếu tôi không xây dựng nó, tôi không quan tâm. 3: Trong nền tảng kinh doanh chậm thay đổi. Ở lại cắt cạnh hiếm khi là một yêu cầu. Nhưng phần mềm tốt di chuyển dễ dàng. 4: Không đúng. Bạn chỉ cần chuyển bloat từ bên ngoài vào nội bộ. 5: Không có ý nghĩa. 6: Không đúng. 7: Đúng nhưng có nghĩa là bạn cần chuyển hướng các lập trình viên quý giá của mình (phần đắt nhất của dự án) khỏi công việc thực tế sang sửa lỗi trên một cái gì đó có thể được duy trì ở nơi khác. 8: Đó là một điều xấu.
Martin York

5
Nhiều công ty lớn sử dụng rộng rãi mã nguồn mở dưới nhiều hình thức khác nhau (bao gồm cả lib), thường cải thiện / đóng góp cho các dự án có liên quan. Các điểm chủ yếu là không liên quan hoặc không chính xác.
Matt

7
@ tp1: Tôi làm việc cho Google và tôi có thể đảm bảo với bạn rằng Google rất sử dụng các thư viện của bên thứ ba khi họ đáp ứng nhu cầu của chúng tôi. Nhiều lần Google có nhu cầu duy nhất hoặc ở quy mô khác với nhiều công ty phần mềm khác, vì vậy vì lý do này hay lý do khác, Google sẽ thường phát triển mọi thứ trong nhà. Nhưng Google cũng sử dụng một số lượng lớn các thư viện nguồn mở và / hoặc rất nhiều thư viện nội bộ nguồn mở, vì vậy không phải mọi thứ đều ở trong nhà. Hầu hết các điểm của bạn không còn áp dụng cho phần mềm nguồn mở, vì có nguồn bạn đảm bảo rằng bạn luôn có thể gỡ lỗi và sửa nó nếu cần.
Daniel Pryden

5
"Không, giá trị đến từ việc thực hiện chính xác các yêu cầu. Nếu nó được xây dựng trước khi các yêu cầu được biết đến, nó không thể thực hiện chính xác các yêu cầu chính xác đó." Manh mối: Nếu bạn nghĩ rằng lập luận này có bất kỳ giá trị nào, thì bạn đã không hiểu được sự phân tách mối quan tâm.
dùng16764
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.