it-swarm-vi.com

Làm thế nào để nói với sếp của bạn rằng phong cách lập trình của anh ta thực sự tồi tệ?

Tôi là một sinh viên và trong thời gian rảnh rỗi tôi đang làm việc cho một doanh nghiệp lớn với tư cách là Java nhà phát triển. Công việc rất tốt, nhưng vấn đề là, ông chủ của tôi viết mã rất lạ. Tôi không Tôi không muốn phàn nàn, nhưng theo tôi, một số vấn đề thực sự kỳ lạ. Ví dụ:

  • anh ta không biết bất kỳ booleans. Tất cả các điều kiện boolean là các chuỗi được gọi là "YesOrNo" và sau đó trong điều kiện anh ta sử dụng if (YesOrNo == "Yes")

  • có rất nhiều ký tự rất lạ trong tên phương thức và các biến như é õ ô hoặc è

  • tất cả các vòng lặp là các vòng lặp vô hạn theo kiểu for (;;). Sau đó, ở cuối vòng lặp, điều kiện được kiểm tra và nếu các điều kiện được thỏa mãn thì phá vỡ; được gọi là.

Tôi không biết liệu tôi có nên nói với anh ấy rằng tôi nghĩ đây không phải là một thực hành tốt, vì anh ấy là ông chủ của tôi và quyết định cách thức và phải làm gì. Mặt khác, một số ví dụ của anh ấy thực sự rất kỳ lạ.

Bất kỳ gợi ý làm thế nào để đối phó với? Và đây chỉ là tôi nghĩ rằng đó là phong cách xấu?

63
RoflcoptrException

Yêu cầu anh ta giải thích mã của mình cho bạn

Nói với anh ta rằng bạn chưa bao giờ thấy X được lập trình theo cách đó trước đây và hỏi anh ta tại sao anh ta viết mã theo cách đó. Chỉ cho anh ấy cách bạn viết mã và cho biết lý do tại sao bạn làm theo cách đó (thực tiễn tốt nhất, hiệu suất tốt hơn, ít cơ hội lỗi hơn, dễ dàng hơn cho các lập trình viên khác đọc/duy trì, v.v.).

Hãy chắc chắn chuẩn bị trước tất cả các đối số của bạn và tập trung vào lý do tại sao phương pháp của bạn là tốt nhất thay vì lý do tại sao phương pháp của anh ấy tệ nhất. Sau đó, xem liệu anh ta vẫn hỗ trợ phương pháp của mình hơn bạn.

Nếu anh ấy cởi mở để cải thiện, anh ấy có thể sẽ thay đổi cách mã hóa của mình. Nếu anh ấy vẫn thích sử dụng phong cách mã hóa của anh ấy hơn bạn, bạn không có khả năng thay đổi ý kiến ​​của anh ấy.

78
Rachel

Thúc đẩy việc sử dụng các công cụ kiểm tra phong cách và phân tích tĩnh tự động như linters và bug finders (bằng bất kỳ ngôn ngữ nào bạn sử dụng). Nếu mọi người trong công ty bắt đầu sử dụng chúng (ví dụ: họ được ủy quyền trước khi đăng ký), anh ta sẽ không được chọn ra.

Lý do tôi đề nghị điều này là:

1) Mọi người thường kiểm duyệt từ các công cụ tự động tốt hơn so với đồng nghiệp hoặc cấp dưới của họ.

2) Những công cụ này bao gồm rất nhiều vấn đề có thể được coi là phong cách kém.

3) Bạn có thể tinh chỉnh các quy tắc đằng sau hậu trường cho phong cách xấu của anh ấy ngoài những gì được tích hợp trong công cụ. Ví dụ, thực thi một kiểu biến nhất định.

4) Một số người nhận ra rằng mã của họ không tốt lắm và thực sự bắt đầu chú ý nhiều hơn ngay cả đối với những thứ không được bao phủ bởi các linters.

Khá nhiều công ty được kính trọng (chẳng hạn như chủ nhân của tôi) buộc phải kiểm tra trước khi nhận phòng. Quan điểm là phong cách xấu là nợ kỹ thuật. Bạn luôn có thể sử dụng "Chà, nếu X và Y và Z đang làm điều đó, có lẽ đó là một ý tưởng hay".

39
Uri

Tôi nghĩ bạn chắc chắn không nên nói thẳng với anh ấy bất cứ điều gì như vậy . Những tuyên bố như vậy có thể dễ dàng gây ra phản ứng phòng thủ trong anh ta, điều này gần như chắc chắn sẽ đóng cửa mọi khả năng để anh ta học hỏi, và thậm chí có thể gây ra vấn đề cho bạn.

Thay vào đó, hãy tìm kiếm (và thậm chí cố gắng tạo) cơ hội để tình cờ thảo luận về các vấn đề về phong cách và thành ngữ mã hóa và đề cập đến anh ấy "cách thực hành tốt nhất" mà bạn biết. Tất nhiên, trước tiên bạn phải đảm bảo rằng những gì bạn đề xuất thực sự là một thực tiễn tốt nhất được biết đến rộng rãi và được chấp nhận.

Ngoài ra, hãy cố gắng thảo luận các vấn đề tương tự với các thành viên khác trong nhóm. Điều quan trọng là hiểu "sự đồng thuận" (không nói hoặc không nói) trong nhóm về phong cách và chất lượng mã hóa . (Nếu mọi người khác viết mã sạch và chất lượng cao, bạn có trường hợp rất khác so với phần còn lại của nhóm bao gồm các lập trình viên thực sự tự hào viết chương trình FORTRAN bằng bất kỳ ngôn ngữ nào. và phong cách mã hóa của sếp, giúp bạn nhắm đến những nỗ lực của mình tốt hơn.

Một cách khác là yêu cầu anh ấy đặt hàng Java hiệu quả cho bạn, bởi vì bạn cảm thấy bạn cần nó để trở thành một lập trình viên tốt hơn. (Trong trường hợp bạn chưa đọc nó, thực tế bạn cần nó.) Sau đó, bạn có thể nói chuyện với anh ấy về các giải pháp và thực hành tuyệt vời trong cuốn sách này.

Nếu anh ấy cởi mở để cải thiện bản thân, anh ấy sẽ nhận các đề xuất của bạn (và cuốn sách). Nếu không, bạn có thể rút lui mà không mất mặt và làm căng thẳng mối quan hệ của mình.

24
Péter Török

Nếu sếp của bạn là một người tuyệt vời, chỉ cần hỏi anh ta: "Anh bạn, WTF?"

21
gruszczy

Trong mọi trường hợp mà bạn nghĩ rằng "của tôi tốt hơn" đừng bao giờ nói với ai đó bạn nghĩ điều đó, hãy cho họ thấy.

Tôi nhắc lại, HIỂN THỊ, đừng nói.

Ya biết rằng nói về hành động, to hơn, lời nói ... đó là sự thật.

8
Jack Marchetti

Chính xác thì ông chủ của bạn giữ vị trí nào? Có phải anh ấy là một nhà phát triển, lãnh đạo công nghệ? Có bao nhiêu nhà phát triển khác trong công ty? Công ty có các tiêu chuẩn mã hóa và đánh giá mã?

Sẽ không có khả năng khiến sếp của bạn thay đổi thói quen xấu (IMHO) nhưng bạn có thể sử dụng một nhóm ngang hàng hoặc các tiêu chuẩn của công ty để gây ảnh hưởng đến anh ta. Nếu mã của anh ấy hiện tuân theo các tiêu chuẩn và các đồng nghiệp đều giống nhau thì các tùy chọn của bạn bị giới hạn.

6
Qwerky

Đây là khuyến nghị của tôi:

  • Nêu rõ trường hợp của bạn.
  • Nếu người quản lý của bạn không tiếp thu * theo quan điểm của bạn và bạn cảm thấy rằng mình đúng, hãy tìm những đồng cỏ xanh hơn và đừng đưa ra bất kỳ lời bào chữa nào.

Tôi khuyên bạn nên tìm kiếm đồng cỏ xanh hơn vì ba lý do:

  1. Về lâu dài, nó có hại cho sự nghiệp của một lập trình viên để duy trì các thực hành xấu. Sự tồn tại của những thực hành xấu đã sinh ra những thói quen xấu.
  2. Một cửa hàng lập trình không chấp nhận các quan điểm thay thế cản trở trí tưởng tượng.
  3. Khi bạn biết rằng bạn đang duy trì các thực hành xấu và nhóm của bạn không chấp nhận các quan điểm khác, tinh thần của bạn chắc chắn sẽ chìm xuống và điều này sẽ khiến cuộc sống của bạn trở nên khốn khổ. Vì vậy, hãy để lại càng sớm càng tốt.

* Phân biệt quan trọng: Mong đợi ai đó tiếp nhận quan điểm của bạn không giống như mong đợi ai đó sẽ mang lại cho bạn quan điểm. Tôi luôn đánh giá cao những người xem xét quan điểm của tôi, trong khi tôi rất ít tôn trọng những người mềm yếu và mang lại cho quan điểm của tôi mà không có lý do chính đáng hoặc bằng chứng để làm như vậy.

6
Jim G.

Hành động nói to hơn lời nói :

Một cách tiếp cận khác:

  • Bạn cần dẫn bằng ví dụ.
  • Hãy chắc chắn rằng các dự án bạn làm là tốt nhất bạn có thể làm.
  • Bạn cần Excel về hiệu suất, ít lỗi hơn, v.v.
  • Một khi bạn có thể chứng minh rằng cách tiếp cận và phong cách của bạn tốt hơn sếp của bạn, trừ khi anh ấy rất kiêu ngạo thì tôi nghĩ rằng tự nhiên người đó sẽ làm theo bất cứ điều gì tốt nhất.
6
Darknight

Tôi sẽ chỉ cho anh ấy Con trỏ với liều lượng nhỏ, khi bạn thấy anh ấy làm điều gì đó "xấu"

"Hmm, kiểm tra cách tiếp cận này cho {Chỉ vào màn hình của anh ấy}, tôi thích làm theo cách này vì blah blah blah."

Làm điều này Không quá một lần mỗi ngày. Anh ấy không nhận đề nghị của bạn không bao giờ đề cập đến nó một lần nữa (trong một vài tuần). Một số ít sẽ dính. Và anh sẽ dần dần tốt hơn.

4
Morons

Yêu cầu sếp của bạn so sánh với cách khác mà bạn đã được dạy. Anh ta có thể có một lý do chính đáng. Bạn sẽ không biết cho đến khi bạn hỏi. Có thể có một số tiêu chuẩn mã hóa cũ mà cô ấy đang cố gắng duy trì hoặc cô ấy có thể không quan tâm. Đừng đưa ra bất kỳ dấu hiệu nào bạn nghĩ rằng ông chủ tự động sai. Oh, và làm điều đó một cách riêng tư. Điều này là cho mục đích giáo dục của bạn.

4
JeffO

Nó phụ thuộc. Nếu mã bạn đang xem xét là mã hoàn toàn mới thì hãy yêu cầu đánh giá mã vì nó sẽ giúp "tăng tốc cho bạn" và nó sẽ cho thấy bạn quan tâm đến việc học. Sếp có thể thấy điều này hữu ích vì nó sẽ chứng minh cho anh ta thấy rằng bạn đang muốn làm điều đúng đắn. Nếu đây là mã cũ mà bạn tình cờ vấp ngã và buộc phải duy trì nó, hãy biến nó thành một điểm để thực hiện tái cấu trúc chậm. Một khai báo kiểu ở đây và ở đó trong khi vẫn hoàn thành nhiệm vụ trong tầm tay. Bây giờ vấn đề ở đây là Chuỗi YesOrNo có thể đảm nhận các giá trị khác như Maybe có thể dẫn đến mã bị hỏng nếu bạn không cẩn thận.

4
Woot4Moo

Điều đầu tiên tôi sẽ làm là tìm hiểu cách anh ấy phản ứng với các nhà phê bình. Nếu tôi trở thành ông chủ - tôi sẽ không làm gì sai cả, phải không? - Tôi muốn được nói ngay vào mặt tôi, tất cả cùng một lúc nhưng theo một cách tôn trọng. Tùy thuộc vào tính khí và văn hóa, sếp của bạn có thể khác nhau.

Nhưng hầu hết trong số họ cần một số sự tôn trọng. Một cách hay để thể hiện, rằng bạn tôn trọng anh ấy, những gì đã được đề xuất trước đây: Bạn giải thích ý của bạn, nhưng để lại quyết định cho anh ấy: "Đây là lý do của tôi, nhưng có lẽ tôi đã giám sát điều gì đó. Sau lời giải thích của tôi:"

if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null

"làm gì bạn đề nghị?"

Và bạn có thể hỏi một siêu câu hỏi trước đây: "Ông X, nếu tôi đã tìm thấy một cái gì đó trong mã của bạn, thường được báo cáo là một thực tiễn có thể ứng biến - tôi nên báo cáo nó cho bạn như thế nào? Tất cả cùng một lúc, hay tôi nên tránh đề cập đến nó bằng mọi giá? Âm thầm cải thiện mã? "

Nó sẽ phụ thuộc vào mối quan hệ của tôi mà tôi sẽ chọn từ ngữ nào, và cách tiếp cận nào.

4
user unknown

Sếp của bạn không biết cách lập trình, và anh ta không nên làm điều đó. Kinh nghiệm của tôi nói với tôi rằng giả sử rằng ai đó được gọi là ông chủ cũng có nhiều kinh nghiệm hoặc tốt hơn bạn là một ngụy biện. Anh ta có thể tốt hơn trong những thứ khác, nhưng quan điểm của quản lý và phân cấp là giao phó mọi thứ cho người thích hợp nhất. Sếp là người có cơ hội khởi nghiệp, hoặc cuối cùng vào vị trí quản lý vì kỹ năng quản lý, không nhất thiết phải là kỹ năng lập trình.

Tôi đã từng có một ông chủ giả vờ rằng tôi đã cài đặt một máy tính trong khi kết nối với một máy phát điện chạy xăng, bởi vì anh ta tuyên bố tin tặc có thể xâm nhập qua mạng điện trong khi máy vẫn không được bảo vệ. Tôi bỏ việc ngay lập tức. Tôi đã học được một bài học quý giá hồi đó: ông chủ không phải lúc nào cũng đúng, và đôi khi bỏ việc là phản ứng có giá trị duy nhất.

Vì vậy, để quay trở lại trường hợp của bạn, bạn có thể gặp trường hợp chỉ tìm kiếm việc làm khác (vâng, khủng hoảng, yadda yadda ... tôi biết) có thể là cách chữa trị tốt nhất. Đừng lãng phí thời gian quý báu của bạn.

4
Stefano Borini

Cố gắng chỉ cho anh ta những đoạn mã mẫu ngắn từ các trang web/địa điểm/cuốn sách có uy tín, vv để thực hiện những điều tương tự.

4
chiurox

Tôi sống trong ngành công nghiệp nơi tôi không thể tìm thấy sai lầm của sếp. Vì vậy, tốt hơn, tôi sẽ tạo ra các trường hợp lỗi xuất hiện trong mã và cho anh ta thấy lỗi, hơn là tôi sẽ đề xuất cho anh ta các thay đổi bắt buộc và về lý do có thể xảy ra [trong trường hợp của bạn, bạn chắc chắn về lý do ..: - D] của lỗi. Bất kỳ nhà phát triển nào, dù tốt hay xấu, sẽ không chấp nhận lỗi cho đến khi anh ta nhìn thấy lỗi.

3
Chris

Tôi đã từng có một vấn đề lớn với phong cách ông chủ.

Có hai vấn đề với điều đó. Trước hết, tôi không nghĩ mình từng nói điều đó với khuôn mặt của anh ấy, nhưng tôi tưởng tượng anh ấy biết. Anh ấy ở lại chuyên nghiệp, tôi thì không, IOW.

Thứ hai, có những lý do cho những gì anh ấy đã làm, và tôi chỉ mất thời gian để hiểu mức độ quá mức và khó chịu của những "giải pháp" đúng đắn này của tôi.

Trong ba điểm trong câu hỏi, diacritics không lạ đối với mọi người và trong khi tôi không sử dụng vòng lặp đó, tôi cảm thấy khó chịu bởi gia đình C làm ... trong khi cú pháp và cách nó (không) phù hợp với phong cách thụt đầu dòng của tôi, vì vậy tôi có thể thấy nó đến từ đâu.

Ngay cả điều boolean cũng có thể có một lời giải thích về các thói quen được mang từ một ngôn ngữ khác (tất nhiên đó không phải là biện minh).

3
Steve314

Tôi đoán điều này có thể làm việc -

  1. Yêu cầu người quản lý của bạn xem lại mã của bạn mà không có bất kỳ lỗi nào mà anh ta mắc phải.
  2. Sau đó xem nếu người quản lý của bạn hỏi bạn tại sao không làm theo cách của anh ấy
  3. Nếu anh ấy hỏi câu hỏi này, bạn có thể hỏi anh ấy tại sao đó sẽ là một cách tốt hơn.

Bằng cách này, bạn có thể biết lý do tại sao anh ấy nghĩ rằng cách của mình là chính xác.

3
k25

Tôi đã từng đến đó trước đây. Tôi đã rời khỏi Uni và sau khoảng một năm làm việc cho một chàng trai, tôi nhận ra rằng tôi biết nhiều hơn anh ta về lập trình, nhưng đó là công việc của anh ta, và anh ta đã gọi các mũi tiêm - và chỉ không muốn xúc phạm anh ta dù sao! Tôi quyết định rằng cách tốt nhất xung quanh nó, là thảo luận về lợi ích của việc có các quy ước mã hóa phổ biến trong toàn công ty mà tất cả chúng ta cũng nên gắn bó, và xem cách anh ấy phản ứng. Đáng ngạc nhiên, anh ấy nghĩ rằng đó là một ý tưởng tuyệt vời, và yêu cầu tôi lập ra một danh sách các tiêu chuẩn, sau đó cả hai chúng tôi cùng nhau xem xét và hoàn thiện, v.v.

Điều quan trọng ở đây là, bạn chỉ là một người dễ sai lầm như anh ấy, và chỉ vì một số cách của anh ấy là kỳ quặc/sai, một số trong số họ sẽ tốt hơn của bạn.

Từ kinh nghiệm cá nhân của tôi tuy nhiên nó không hoạt động. Mặc dù đã dành 2 ngày để nghiên cứu và biên soạn một tài liệu tuyệt vời về các tiêu chuẩn và quy ước mã hóa - anh ta đã được thiết lập theo cách của mình, nhưng không thực sự thấy được lợi ích trong các quy ước mã hóa, hoặc viết mã ít gây căng thẳng cho máy chủ, điều đó đã tạo ra công việc của chúng tôi nhanh hơn và dễ dàng hơn, và cắt giảm chi phí.

Cuối cùng, tôi rời đi để tìm một nơi nào đó phát triển nghiêm trọng hơn một chút. Đó không phải là tất cả xấu, như nghiên cứu tôi đã làm về các quy ước mã hóa thực sự giúp ích cho đến ngày nay.

3
user16731