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

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à?

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.

Đ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.

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.

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!)

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ứ.

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ố.

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 đề.

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.

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ứ.

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

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