Cách người quản lý chọn ngôn ngữ lập trình

Đó không phải là một bí mật đối với bất kỳ ai mà các nhà quản lý có thể và thường sẽ áp đặt ngôn ngữ lập trình sẽ được sử dụng cho một dự án.

Là một lập trình viên, tôi chưa bao giờ có thể hiểu điều này.

Nhưng bây giờ tôi nghĩ rằng tôi đã làm: Tôi vừa có một tiết lộ khi Joel Spolsky nói trên podcast rằng họ nên sử dụng QuickBooks vì "mọi kế toán viên trên thế giới đều biết điều đó". Điều này gây ấn tượng với tôi là rất giống với "đã chọn Java vì mọi lập trình viên trên thế giới đều biết điều đó".

Bây giờ tôi đã thấy vấn đề tương tự từ một góc nhìn khác, tôi không biết nhiều về kế toán, nhưng tôi biết một số điều về lập trình, tôi tự hỏi làm thế nào một lập trình viên có thể giúp đảm bảo ngôn ngữ lập trình phù hợp được chọn cho một dự án ?

Sai lầm mà nhiều lập trình viên mắc phải là họ sẽ tranh luận về quan điểm (hoặc đơn giản là đồng ý hoặc không đồng ý với nó) chỉ dựa trên thành tích kỹ thuật. Với quản lý - và toàn bộ doanh nghiệp - bạn phải tranh luận về trường hợp kinh doanh và công trạng cho doanh nghiệp trước và công đức kỹ thuật thứ hai.

Điều này vượt ra ngoài sự lựa chọn ngôn ngữ lập trình và bao trùm hầu như mọi quyết định kỹ thuật.

Hãy để tôi cho bạn một ví dụ: PC. Joel lập luận (chính xác) rằng các nhà phát triển nên có những cỗ máy đỉnh cao vì thời gian của nhà phát triển rất tốn kém. Ở đây anh ấy hoàn toàn đúng. Nhưng làm thế nào để bạn tranh luận này? Đơn giản:

Ví dụ: Tôi thực hiện xây dựng mã khoảng 20 lần một ngày. Mỗi lần mất 3 phút. Nếu tôi có một PC nhanh, tôi có thể xây dựng nó trong 1,5 phút. Vì vậy, cứ thêm 1.000 đô la cứ sau hai năm tôi có thể kiếm thêm nửa giờ mỗi ngày, với một lập trình viên kiếm được 100 nghìn đô la (với chi phí ít nhất là 50%), tương đương với khoảng 10.000 đô la mỗi năm.

Nhưng tranh cãi ở đầu bên kia là HR quyết định một kích thước phù hợp với tất cả khi nói đến chính sách và PC, vì vậy một nhân viên trung tâm cuộc gọi kiếm được 25 nghìn đô la và một lập trình viên kiếm được bốn lần vì lý do nào đó có cùng một PC.

Nền tảng công nghệ và ngôn ngữ sẽ có rất nhiều yếu tố đi vào hỗn hợp quyết định:

• Mối quan hệ chiến lược với các nhà cung cấp cụ thể. Nếu công ty của bạn là Đối tác Vàng của Microsoft (hoặc bất cứ điều gì nó được gọi là bây giờ) thì chúc may mắn có được Java hoặc Python;
• Bộ phận CNTT tranh luận về một cấu hình cụ thể vì tiền cho PC ra khỏi ngân sách của họ;
• CNTT quyết định mọi người nên chạy Windows 2000 vì họ không có người chạy Linux;
• Những hệ thống nào khác mà công ty đã có (ví dụ: nếu họ sử dụng Java cho mọi thứ khác thì sẽ hợp lý khi sử dụng nó cho việc này mặc dù về bản thân nó có thể không phải là lựa chọn tốt nhất);
• Lo ngại rủi ro đối với các nền tảng hoặc ngôn ngữ khác nhau chỉ đơn giản là do thiếu kinh nghiệm;
• Quan tâm nhiều hơn đến việc tranh luận rủi ro với quản lý cấp trên hơn là làm cho các nhà phát triển hài lòng;
• Một số nhà quản lý đưa ra quyết định họ làm đơn giản vì tay họ bị trói;
• Các lý do ngân sách mặc dù điều này cũng có thể có lợi cho bạn vì nó giữ cho những chiếc cốc đắt tiền ra khỏi nhà bạn như PVCS, bất cứ thứ gì được sản xuất bởi Rational, v.v;
• Bộ phận pháp lý ác cảm với giấy phép nguồn mở;
• Không liên quan đến các nhân viên kỹ thuật trong lập kế hoạch và dự toán;
• Sự quen thuộc của người quản lý với một nền tảng cụ thể (những người kỹ thuật cũng có lỗi về điều này nhưng trong cả hai trường hợp, đó không hẳn là điều xấu - với nhiều công cụ có thể thực hiện công việc tốt hơn quỷ mà bạn biết).
• Kinh nghiệm của đội ngũ kỹ thuật. Nếu tất cả đều từ nền C #, tại sao họ sẽ sử dụng Java, Python hoặc Ruby?
• Nhiều lý do khác

Bất kể trường hợp nào bạn cần hiểu lý do (và tôi đảm bảo với bạn sẽ có một số lý do) và tranh luận về những điều khoản đó. Một số lập trình viên khá ngây thơ trong bộ phận này và dường như nghĩ rằng những quyết định như vậy được đưa ra từ sự thiếu hiểu biết hoặc thậm chí là minh oan khi gần như luôn luôn có nhiều yếu tố được chơi.

Từ những gì tôi có vẻ trong công ty của mình: Khi các nhà quản lý chọn ngôn ngữ lập trình, họ thường làm điều đó rất bảo thủ - quan tâm đến loại kỹ năng lập trình nào hiện có trong nhóm (và nếu có thể dễ dàng thuê thêm một cách dễ dàng ), cho dù đó là một ngôn ngữ được thiết lập tốt, cố gắng chọn thứ gì đó phù hợp với cơ sở hạ tầng hiện tại và không gây ra những nỗ lực lớn để làm cho nó phù hợp với những gì đã có. Khi các lập trình viên chọn ngôn ngữ lập trình, mọi thứ thường có xu hướng hơi khác một chút - họ thường thích có một thử thách mới và muốn có được xu hướng nóng mới nhất và chọn một thứ mà họ có thể học những điều mới.

Lý tưởng nhất là tất cả bắt nguồn từ việc thảo luận về những ưu và nhược điểm giữa người quản lý và nhóm phát triển và tìm ra giải pháp phù hợp nhất với vấn đề. Điều này thường liên quan đến rất nhiều cuộc nói chuyện và thuyết phục :-)

Trả lời muộn, nhưng vì chưa có câu trả lời được chấp nhận, tôi sẽ thử. Tôi coi đó là hai câu hỏi và sẽ cố gắng trả lời riêng:

Làm thế nào để các nhà quản lý chọn ngôn ngữ lập trình?

Phụ thuộc nhiều vào quy mô của tổ chức và kinh nghiệm của người quản lý, nhưng nhìn chung sẽ liên quan đến việc đánh giá tình hình hiện tại và các kịch bản và yêu cầu trong tương lai. Điều này thường được thực hiện thông qua PESTLE hoặc phân tích tương tự, và chỉ để đưa ra một vài mẫu trong mỗi loại:

• Chính trị
  • "Không ai bị sa thải vì mua IBM" - sự lựa chọn an toàn.
  • CEO nghe nói rằng Java rất tuyệt - cường điệu.
  • Kiến trúc sư trưởng yêu thích .NET - dự án thú cưng.
  • Ngôn ngữ được kiểm soát bởi một đối thủ cạnh tranh thù địch - tại sao Google không dựa vào C #.
• Kinh tế
  • Chi phí cấp phép.
  • Chi phí đào tạo nhà phát triển.
  • Mã chi phí di chuyển cơ sở.
• Xã hội
  • Mua vào từ đội.
  • Kỹ năng sẵn có trong nhà (nhu cầu đào tạo, liên tục).
  • Kỹ năng sẵn có trên thị trường.
  • Đe dọa đến hiện trạng trong nhóm nhà phát triển.
  • Có sẵn của cộng đồng thực hành đủ lớn.
• Công nghệ
  • Nâng cao năng suất.
  • Cải thiện chất lượng.
  • Khả năng tương tác với cơ sở mã hiện có.
  • Tuân thủ các tiêu chuẩn.
  • Trưởng thành.
• Hợp pháp
  • Điều khoản cấp phép.
  • Kiểm soát công nghệ (Ai sở hữu và kiểm soát công nghệ? Chiến lược cấp phép trong tương lai có khả năng là gì?)
  • Tuân thủ pháp luật và quy định.
• Môi trường
  • Cơ sở hạ tầng hiện có trong công ty.
  • Kỹ năng hiện có trong công ty.
  • Tích hợp với các đối tác bên ngoài.
  • Mức độ hỗ trợ công nghệ của môi trường rộng lớn hơn.

Sau đó, một loạt các ngôn ngữ phù hợp với tiêu chí có thể được đánh giá thêm bằng cách sử dụng SWOT , phân tích lợi ích chi phí hoặc tương tự.

Toàn bộ quá trình có thể khá phức tạp, nhưng vì điểm mấu chốt là hầu hết các công ty hoặc nhóm dự án sẽ đi đến lựa chọn an toàn nhất với hoàn cảnh hiện tại của họ vẫn có thể cung cấp các khả năng họ cần. Thông thường, nó có thể có nghĩa là gắn bó với nền tảng hiện tại lâu hơn.

Làm thế nào một lập trình viên có thể giúp đảm bảo ngôn ngữ lập trình phù hợp được chọn cho một dự án

Như đã từng, hy vọng, đã chứng minh một lập trình viên điển hình thường sẽ chỉ bằng 1/6 tổng số đầu vào trong quá trình ra quyết định. Và như một quy luật, cô ấy hoặc anh ấy sẽ chủ yếu quan tâm đến khả năng ngôn ngữ một mình!

Chà, cách tốt nhất để tác động đến quyết định dường như có một bức tranh rộng lớn hơn về quá trình lựa chọn, làm cho các đồng minh trong và ngoài nhóm, tạo ra một bản tóm tắt tốt về mặt công nghệ của mọi thứ và cố gắng không tập trung vào khả năng ngôn ngữ một mình.

Và, tất nhiên, người ta cần vào vị trí khi Giám đốc Dự án hoặc Phát triển (hoặc bất kỳ ai chịu trách nhiệm) thấy được lợi ích của việc trải qua toàn bộ quá trình đánh giá và sẵn sàng xem xét các rủi ro và sự không chắc chắn của việc chuyển sang khác ngôn ngữ ở nơi đầu tiên. Để điều này xảy ra, nó cần phải được chứng minh rằng:

1. Nền tảng hiện tại không còn đủ.
2. Một nền tảng mới hứa hẹn những lợi ích vượt xa những rắc rối.

Tuy nhiên, liệu bạn có hỏi "Cách tốt nhất để có thể sử dụng ngôn ngữ tôi thích là gì", câu trả lời có lẽ là "tham gia một công ty đã sử dụng ngôn ngữ hoặc bắt đầu ngôn ngữ của bạn".

Người quản lý A đi đến một khóa tu mùa hè, nơi anh ta gặp người quản lý B.

A: Vậy bạn sử dụng ngôn ngữ nào trong công ty của bạn? B: Ồ, chúng tôi sử dụng CA Visual Object, nó làm cho máy bay không người lái có năng suất cao hơn nhiều so với COBOL.

Và đây là cách quyết định được đưa ra. Kết thúc câu chuyện có thật.

Mọi nền tảng đều có mặt tốt và mặt xấu. .NET rất tuyệt và mạnh mẽ nhưng bạn gặp khá nhiều khó khăn với các máy chủ Windows. Ruby rất tuyệt nhưng chậm. Thật khó để tìm các nhà phát triển cho Haskell.

Vấn đề là, ngôn ngữ không ảnh hưởng đến việc dự án sẽ được thực hiện nhanh như thế nào và mã đẹp như thế nào mà còn là những thứ mà các nhà quản lý quan tâm. Vì vậy, nếu bạn muốn ảnh hưởng đến họ, bây giờ bạn nên ưu tiên họ và tìm ra nhiều mặt tốt trong quan điểm của họ nhất có thể.

Bằng cách tách mối quan tâm. Doanh nghiệp nên chịu trách nhiệm về các quyết định kinh doanh và công nghệ phụ trách các quyết định công nghệ. Tôi thích thuật ngữ "Chấp nhận trách nhiệm". Nếu tôi chấp nhận trách nhiệm, tôi cũng yêu cầu tôi đưa ra những lựa chọn liên quan đến vấn đề của mình. Kinh doanh mang lại cho tôi và các đồng nghiệp công nghệ của tôi các nhu cầu kinh doanh và chúng tôi trả lời bằng một hoặc hai phương án về cách chúng tôi có thể chấp nhận trách nhiệm giao hàng. Nó không bao giờ giống như "chúng ta sẽ làm điều đó trong Python hoặc C #". Hơn;

"Chúng tôi có thể chấp nhận hai trách nhiệm khác nhau ở đây: Nếu chúng tôi đi theo cách này, chúng tôi có thể cung cấp nhanh chóng và chúng tôi đáp ứng những nhu cầu kinh doanh này thực sự tốt và những điều này khó hơn một chút. Chúng tôi cũng có thể làm theo cách này và điều đó mang lại cho những doanh nghiệp này yêu cầu . Thay thế A yêu cầu những tài nguyên này và B thay thế có nghĩa là chúng ta cũng cần phải làm điều này và điều này ... "

Sau đó, doanh nghiệp chọn, nhưng lưu ý rằng kinh doanh chọn dựa trên tác động đến những thứ kinh doanh, không phải những thứ kỹ thuật. Và họ không được lựa chọn trong số các lựa chọn thay thế nơi công nghệ không sẵn sàng chấp nhận trách nhiệm của bộ phận công nghệ.

Trở thành người quản lý. (cười)

Nghiêm túc, bạn chỉ cần thảo luận vấn đề với người ra quyết định trong câu hỏi, và đưa ra lập luận của bạn. Nếu họ chọn gắn bó với một quyết định thực sự sai lầm, thì năng lực chung của họ có lẽ không quá hấp dẫn và có thể đáng để tìm kiếm một cái gì đó khác để làm.

Tôi nghĩ rằng sự khác biệt giữa những gì bạn đang nói và những gì Joel đang nói là lập trình là một năng lực cốt lõi trong khi kế toán thì không. Điểm có thể sử dụng Quickbooks là, bởi vì bạn không phải là kế toán viên và kế toán viên có thể giúp bạn với nó. Tuy nhiên, nếu lập trình là năng lực cốt lõi của bạn, và có lẽ đó là nếu bạn là một lập trình viên, thì các quy tắc của trò chơi có một chút khác biệt.

Nó phụ thuộc rất nhiều vào tính cách của người quản lý:

Có những cái đi cho buzzwords. Chỉ cần tìm ra những từ thông dụng mà họ thích và sử dụng nó khi bạn nói chuyện với anh ấy bằng ngôn ngữ bạn muốn sử dụng.

Những người khác sẽ chỉ tin tưởng vào những điều họ biết (ví dụ như VB 6.0). Làm cho ngôn ngữ của bạn trở nên dễ hiểu đối với họ ('bạn biết đấy, nó giống như trong VB cũ tốt' - ngay cả khi bạn đang nói về Haskell ...)

Nhưng trong thực tế, hầu hết các nhà quản lý không ngu ngốc như chúng ta nghĩ, và họ có thể suy luận được. Điều quan trọng ở đây là bạn hiểu quan điểm của họ: Họ thường không quan tâm đến các chi tiết kỹ thuật cụ thể, họ quan tâm đến kết quả. Vì vậy, đừng nói với họ rằng .net hoặc Java hoặc Delphi hoặc bất cứ điều gì có tính năng tuyệt vời megacool này. Nói với họ rằng (nhập ngôn ngữ của bạn ở đây) là một lựa chọn tốt vì tính năng A giúp thời gian phát triển ngắn hơn trong một dự án như thế này hoặc tính năng B tạo ra ít lỗi hơn và do đó rút ngắn thời gian cần thiết để thử nghiệm. Chỉ cần chắc chắn rằng cuộc tranh luận của bạn là âm thanh, đừng nói dối anh ta.

Nói cách khác: đối xử với anh ta như một người không liên quan (có lẽ anh ta là vậy).

Hãy nghĩ về ngôn ngữ bạn đang được yêu cầu sử dụng rất rất khó. Hãy chắc chắn rằng bạn biết đó không phải là ngôn ngữ tốt cho công việc, sau đó hỏi người quản lý nếu bạn có thể đưa ra gợi ý về một ngôn ngữ khác tốt hơn để sử dụng cho công việc. Cung cấp bất kỳ thông tin nào bạn có thể chứng minh rằng ngôn ngữ sẽ không tốt cho công việc và xem những gì anh ấy nói. Nó không đau. :)

Chọn ngôn ngữ lập trình thường là một quyết định kinh doanh. Khách hàng / Người dùng không quan tâm. Đây là trích dẫn ngắn (từ http://www.ericsink.com/bos/Geek_Rule.html ):

Ngôn ngữ lập trình được chọn chủ yếu vì lý do kinh doanh. Tôi dành phần lớn thời gian để làm việc với các ngôn ngữ mà tôi không thực sự thích vì các ngôn ngữ mà tôi muốn làm việc mang theo những bất lợi trong kinh doanh vượt xa các giá trị kỹ thuật của chúng. Đó là bản chất của trò chơi. Tôi có thể chấp nhận tình huống (lựa chọn của tôi) hoặc tìm một chủ nhân mới. Rên rỉ về cách tôi không thể sử dụng Java hoặc Python hoặc bất cứ điều gì tại nơi làm việc không phải là một tùy chọn.

Trước hết, lập trình là một hình thức nghệ thuật khác. Một hình thức nghệ thuật rất logic. Nếu người quản lý của bạn quan tâm đến các dự án phần mềm đặc biệt của anh ta, đó là một số phần mở rộng, tác phẩm tuyệt tác, thì hãy hỏi người quản lý quan tâm đó như sau:

Mất bao nhiêu năng lượng và thời gian để Rembrandt tốn thêm tiền để không vẽ bằng cọ yêu thích của mình, nhưng một cây cọ mà sau khi xem xét cẩn thận của đội ngũ quản lý, đã được trao cho anh ta, 400 năm trước và trước khi các tác phẩm của anh trở nên nổi tiếng. Bức tranh của anh ấy sẽ ít nhiều đáng để bạn nghĩ?

Tương tự, nếu bạn đang nói với một lập trình viên nên sử dụng ngôn ngữ nào, thì hãy nhất quán và cũng nói với họa sĩ những kích thước cọ nên được sử dụng! HOẶC, thay vào đó, chỉ để lại sự lựa chọn này cho những người cần làm việc với nó mỗi ngày và (giống như hầu hết các kiệt tác) đêm!

Đây là những khái niệm khác nhau.

Khi kế toán, bạn chia sẻ kết quả của mình: về thuế, luật pháp, nhà đầu tư, v.v ... Họ cần một công cụ để xem kết quả lao động của bạn và công cụ này phải được biết rõ.

Khi lập trình, bạn sử dụng bất kỳ công cụ nào bạn muốn - miễn là nó xuất ra một .exetệp mà bạn có thể chạy trên Windows. Đây chính xác giống như một tài liệu có thể đọc Sách nhanh trong trường hợp kế toán.

Vì vậy, nếu bạn phát triển một máy nướng bánh mì, bạn có thể giữ tài liệu nội bộ của mình bằng tiếng Trung Quốc nhưng bạn nên cung cấp hướng dẫn sử dụng tiếng Anh.

Có một điều nữa: nếu quy tắc của công ty bạn cho rằng kết quả mã của bạn không phải là sản phẩm, mà là mã nguồn cho nó, thì chắc chắn họ có thể quyết định nó sẽ trông như thế nào (bằng cách chọn ngôn ngữ họ muốn).

Những gì họ chọn phụ thuộc vào mục tiêu của họ: nếu họ muốn lập trình viên dễ dàng thay thế, họ chọn Java; nếu họ gửi nó đến bộ phận khác thì đó sẽ là yêu cầu của bộ phận đó, v.v.

Theo kinh nghiệm của tôi, nó luôn phụ thuộc vào:

1. Chúng ta có tài nguyên để sử dụng ngôn ngữ không?
2. Chúng ta có tài nguyên để duy trì ngôn ngữ không?
3. Nếu chúng ta không có tài nguyên để sử dụng và duy trì ngôn ngữ thì việc lấy những tài nguyên đó có khó khăn / tốn kém đến mức nào không?
4. "Tương lai" của ngôn ngữ là gì (Nó sẽ xuất hiện và sử dụng trong một thời gian?)

Trừ khi dự án cần một cái gì đó mà chỉ một ngôn ngữ / nền tảng / công nghệ / khung cụ thể cung cấp cho nó phù hợp với những gì chúng ta đã biết và sử dụng. Cả việc thuê người mới và đào tạo lập trình viên hiện tại đều khá tốn kém đối với hầu hết các công ty. Khi tuyển dụng, chúng tôi luôn xem xét ngôn ngữ và đảm bảo các ứng viên biết họ sẽ sử dụng ngôn ngữ nào.

Hy vọng rằng bạn có một lập trình viên cũng là một người quản lý và có thể đại diện cho các lập trình viên trong các loại quyết định này. Nếu không thì đó là một tình huống nguy hiểm và bạn nên nói chuyện với người quản lý của mình nếu bạn biết quyết định như vậy đang được đưa ra.