Tại thời điểm nào thì những lời chỉ trích mang tính xây dựng của mã của bạn trở nên vô ích?


39

Gần đây tôi đã bắt đầu như một nhà phát triển cơ sở. Ngoài việc là một trong những người ít kinh nghiệm nhất trong đội, tôi còn là một phụ nữ, đi kèm với tất cả các loại thử thách của chính nó khi làm việc trong môi trường do nam giới thống trị. Gần đây tôi đã gặp vấn đề bởi vì tôi cảm thấy như tôi đang nhận quá nhiều lời chỉ trích mang tính không chính đáng về công việc của mình. Hãy để tôi cho bạn một ví dụ về những gì đã xảy ra gần đây.

Trưởng nhóm quá bận rộn để thúc đẩy một số chi nhánh tôi đã thực hiện, vì vậy anh ấy đã không đến với họ cho đến cuối tuần. Tôi đã kiểm tra thư của mình, không thực sự có ý nghĩa để thực hiện bất kỳ công việc nào và thấy rằng hai nhánh của tôi đã bị từ chối trên cơ sở tên biến, làm cho thông báo lỗi trở nên mô tả hơn và chuyển một số giá trị sang tệp cấu hình.

Tôi không cảm thấy việc từ chối chi nhánh của mình trên cơ sở này là hữu ích. Rất nhiều người đã làm việc vào cuối tuần, và tôi chưa bao giờ nói rằng tôi sẽ làm việc. Thực tế, một số người có thể đã bị chặn vì tôi không có thời gian để thực hiện các thay đổi và gửi lại. Chúng tôi đang làm việc trên một dự án rất nhạy cảm với thời gian và dường như với tôi rằng việc từ chối hoàn toàn mã dựa trên những điều minh bạch đối với khách hàng là không hữu ích. Tôi có thể sai, nhưng có vẻ như những điều này nên được xử lý theo kiểu cam kết khi tôi có thời gian.

Bây giờ, tôi có thể thấy rằng trong một số môi trường, đây sẽ là chuẩn mực. Tuy nhiên, những lời chỉ trích dường như không được phân bổ đều, đó là điều dẫn đến vấn đề tiếp theo của tôi. Cơ sở của hầu hết các vấn đề này là do thực tế là tôi đã ở trong một cơ sở mã mà người khác đã viết và đang cố gắng xâm lấn tối thiểu. Tôi đã bắt chước các tên biến được sử dụng ở nơi khác trong tệp. Khi tôi nói điều này, tôi đã nói thẳng: "Đừng bắt chước người khác, chỉ cần làm những gì đúng." Đây có lẽ là điều ít hữu ích nhất mà tôi có thể được nói. Nếu mã đã được kiểm tra là không thể chấp nhận, làm thế nào tôi có thể nói điều gì đúng và điều gì sai? Nếu nền tảng của sự nhầm lẫn đến từ mã cơ bản, tôi không nghĩ nó '

Tôi cảm thấy thực sự độc thân và thất vọng trong tình huống này. Tôi đã nhận được nhiều hơn về việc tuân theo các tiêu chuẩn được mong đợi và tôi cảm thấy thất vọng vì, ví dụ, khi tôi cấu trúc lại một đoạn mã để THÊM kiểm tra lỗi đã bị thiếu trước đây, tôi chỉ nói rằng tôi đã không làm làm cho các lỗi đủ dài (và chi nhánh đã bị từ chối trên cơ sở này). Điều gì xảy ra nếu tôi chưa bao giờ thêm nó để bắt đầu? Làm thế nào mà nó vào được mã để bắt đầu nếu nó quá sai? Đây là lý do tại sao tôi cảm thấy rất độc thân: Tôi liên tục gặp phải mã có vấn đề hiện tại này, rằng tôi hoặc bắt chước hoặc tái cấu trúc. Khi tôi bắt chước nó, nó "sai", và nếu tôi tái cấu trúc nó, tôi bị mắng vì không làm đủ (và nếu tôi đi hết con đường, giới thiệu các lỗi, v.v.). Một lần nữa, nếu đây là một vấn đề như vậy, tôi không hiểu làm thế nào bất kỳ mã nào vào được cơ sở mã,

Dù sao, làm thế nào để tôi đối phó với điều này? Xin nhớ rằng tôi đã nói ở trên rằng tôi là phụ nữ và tôi chắc chắn những người này thường không phải lo lắng về việc trang trí khi họ xem xét mã của những người khác, nhưng thật lòng điều đó không phù hợp với tôi và nó khiến tôi làm việc kém hiệu quả hơn. Tôi lo lắng rằng nếu tôi nói chuyện với người quản lý của mình về điều đó, anh ấy sẽ nghĩ rằng tôi không thể xử lý môi trường, v.v.


18
Tôi là một chàng trai, thiếu niên (tại công ty này), và tôi đã cảm thấy một tiêu chuẩn kép tương tự. Các codebase thường trông giống như tào lao, nhưng tôi dự kiến ​​sẽ tuân theo một tiêu chuẩn cao hơn nhiều. Chà, hóa ra là tào lao đã vào đó do "cuộc tuần hành tử thần" đã được thực hiện trong quá khứ. Ngoài ra, rõ ràng tôi trông trẻ hơn tôi 5 tuổi. Khi các đồng nghiệp của tôi phát hiện ra tuổi thật của tôi, tôi trở nên thông minh hơn rất nhiều chỉ sau một đêm. Con người là những con khỉ không hoàn hảo. Nó giúp nếu bạn chia sẻ bữa ăn trưa với họ và cười vào những câu chuyện cười của họ, nhưng đừng lạm dụng nó. Các chàng trai giải thích MỌI THỨ như một lời tán tỉnh.
Công việc

4
@Job: Chà, nếu cơ sở mã là tào lao thì nó sẽ tốt hơn, do đó các cam kết của bạn phải có tiêu chuẩn cao hơn. Nếu không, nó thậm chí còn trở nên nhảm nhí hơn, phải không? :)
Macke

@Marcus, bạn đúng, nhưng điều thực sự hữu ích là nếu các quy tắc được nêu rõ ràng, và các quy tắc tương tự được áp dụng cho tất cả mọi người. Ngoài ra, có một điều gì đó để nói về việc pha trộn vào cùng các tiêu chuẩn mã, như người hỏi đã đề cập. Tôi đã thấy một anh chàng đàn em bị buông tay như một vật tế thần. Ban quản lý phàn nàn rằng các kỹ sư sản xuất quá nhiều lỗi. Các kỹ sư không thể làm một công việc tốt vì ban quản lý cho họ thời hạn cố định. Vì vậy, khi có sự cố xảy ra, luôn có một anh chàng đàn em có nhiều vụ lừa đảo nhất để đổ lỗi và buông tay. vi.wikipedia.org/wiki/Dedovshchina
Công việc

3
Một điều nổi bật với tôi là "Họ đã quen với các chàng trai nên họ không sử dụng decorum." Tôi muốn nói rằng bạn cần phải làm điều đó trừ khi rõ ràng đó là vấn đề phân biệt đối xử. Bạn sẽ đi đến một công trường xây dựng và mong đợi được đối xử khác biệt so với phần còn lại của các nhà soạn thảo? Vất vả lên. Nếu bạn làm việc trong một môi trường thống trị của nam giới, bạn cần có khả năng đối phó và điều chỉnh theo các chuẩn mực xã hội khác nhau giống như họ phải làm. Đừng quá "nhạy cảm".
Giàn

1
Tôi biết điều này là vài năm quá muộn, nhưng tôi nghĩ đây là một chủ đề quan trọng cho độc giả tương lai. Đừng loại trừ khả năng nhóm trưởng của bạn chỉ đơn giản là biết rõ hơn; anh ta có lẽ cao cấp hơn và đã phát triển một trực giác cho những mối quan tâm theo kiểu có vấn đề - Tôi thách thức bất cứ ai trong tình huống này coi đây là cơ hội để học hỏi và phát triển. Trân trọng yêu cầu làm rõ về các vấn đề bạn không hiểu và cẩn thận đừng hiểu sai tính cách khô khan của đồng nghiệp là độc hại.
weberc2

Câu trả lời:


41

Có khả năng bạn là người phụ nữ độc thân, nhưng cũng có thể bạn chỉ là một nhà phát triển cơ sở và mới làm việc.

Kiểm tra lỗi và thông điệp biểu cảm là quan trọng. Nếu bạn định thêm thứ gì đó vào mã, hãy đảm bảo rằng nó đúng và theo tiêu chuẩn của nhóm. Tương tự, nếu bạn đang sửa đổi mã của người khác, hãy cố gắng cải thiện nó ở nơi có thể - đừng viết lại toàn bộ, nhưng hãy cố gắng để nó sạch hơn một chút so với bạn tìm thấy.

Có một phiên bản bằng văn bản của các tiêu chuẩn mã hóa mà nhóm của bạn tuân theo không? Nếu không, nó có thể là một ý tưởng tốt để viết tất cả xuống. Bạn có thể dẫn đầu nỗ lực bằng cách viết ra những lỗi bạn mắc phải và hình thành chúng thành một danh sách kiểm tra mà bạn có thể tham khảo trước khi gửi các thay đổi của mình để xem xét. Là một tác dụng phụ, bạn có thể sử dụng tiêu chuẩn bằng văn bản đó để kháng cáo các từ chối trong tương lai nếu chúng mâu thuẫn với nó.

Có vẻ như có thể có một số thiếu hiểu biết giữa bạn và trưởng nhóm. Nó có thể hữu ích cho bạn để yêu cầu một cuộc gặp riêng với anh ấy và thảo luận về những gì bạn có thể làm để cải thiện. Bạn có thể dẫn dắt bằng một thứ như "Tôi cảm thấy như mình vẫn còn thiếu rất nhiều sắc thái của những gì tôi nên làm. Là một nhà phát triển cơ sở tôi muốn phát triển và cải thiện. Bạn có thể giúp tôi đến đó không?" và hãy xem chuyện gì xảy ra.


Câu trả lời của Anna nói chung là rất hợp lý. +1. Tôi nghĩ làm việc ở nơi bạn làm việc sẽ khiến tôi phát điên. Không quản lý của bạn quan tâm về thời hạn đáp ứng? Nếu mã hoạt động, gửi nó. Làm sạch nó sau. Heck, bạn thậm chí có thể làm sạch nó vào thứ Hai và đẩy nó qua trong phiên bản tiếp theo. Hành vi này của người quản lý của bạn sẽ không bao giờ bay đến nơi làm việc của tôi và tôi rất vui vì tôi có thể tập trung vào việc đáp ứng thời hạn thay vì chính trị. Hy vọng tình hình của bạn trở nên tốt hơn và bạn tìm ra giải pháp. :)
jmort253

11
@ jmort253 Cảm ơn. :) Điều đó nói rằng, "nếu mã hoạt động, vận chuyển nó" có thể là một thái độ nguy hiểm cần phải có. Mã làm việc không phải lúc nào cũng là mã tốt (mặc dù nó chắc chắn tốt hơn mã bị hỏng) và chất lượng mã là quan trọng trong dài hạn. Dọn dẹp nó sau này gần như không bao giờ xảy ra, vì các thời hạn khác xuất hiện và nhiều thứ cấp bách hơn xuất hiện. Có một thuật ngữ cho điều này - "nợ kỹ thuật".
Adam Lear

@Anna, đồng ý về tầm quan trọng của mã tuân thủ. Tôi đã đọc rằng mã không tuân thủ là đủ để Linus Thorvalds từ chối bản vá được gửi cho Linux ngay tại chỗ (nhưng tôi không thể xác định được mã ngay bây giờ).

@ Anna / Thorbjorn - Đôi khi bạn chỉ cần làm những gì khách hàng muốn mặc dù có thời hạn. Khách hàng của bạn sẽ không hiểu lắm nếu anh ấy / cô ấy mất doanh thu kinh doanh trị giá 15.000 đô la vì bạn chỉ muốn dọn sạch các lỗi viết hoa. Thật không may, cố gắng loại bỏ 100% nợ kỹ thuật không phải lúc nào cũng có thể. Nó sẽ tương tự như chờ đợi 40 năm để tiết kiệm đủ tiền mặt để mua ngôi nhà mơ ước của bạn thay vì thế chấp. Chắc chắn, bạn sẽ được tự do và rõ ràng, nhưng bạn đã dành cả cuộc đời của mình để đối phó với chủ nhà mờ ám.
jmort253

Các dự án nguồn mở khác với các dự án lợi nhuận. Nhiều dự án nguồn mở có thể đủ khả năng để có các tiêu chuẩn chặt chẽ hơn vì không phải lúc nào cũng có lợi nhuận để có / mất. Các dự án độc quyền có các mục tiêu khác nhau và đôi khi những mục tiêu kinh doanh đó được ưu tiên. Tôi không nói rằng mã không nên tuân thủ, chỉ là đôi khi bạn chỉ cần làm những gì bạn phải làm và có kỷ luật để quay lại và khắc phục sự cố sau khi triển khai.
jmort253

25

Có vẻ như bạn có thể lấy những thứ này quá cá nhân. Đừng; loại điều này xảy ra tất cả các thời gian.

Những lý do để từ chối đăng ký của bạn (đặt tên biến, chất lượng bình luận, vị trí cấu hình) có vẻ khá chuẩn đối với tôi.

Thời điểm của nó là quyết định của nhóm trưởng của bạn và tôi sẽ không lo lắng về điều đó nếu tôi là bạn. Nếu ai đó bị chặn vào cuối tuần, trưởng nhóm có thể chọn cho phép đăng ký và yêu cầu bạn khắc phục sau đó. Nếu anh ta cảm thấy thích hợp để đá nó trở lại mặc dù nó có thể chặn một số nhà phát triển khác, đó là trách nhiệm của anh ta.

Đối với trưởng nhóm nói với bạn rằng đừng bắt chước người khác mà hãy làm những gì đúng, có vẻ như anh ta đang cố gắng cung cấp cho bạn một số sáng kiến ​​để làm cho cơ sở mã tốt hơn. Đó là một dấu hiệu tốt. Anh ấy tin tưởng bạn sử dụng phán đoán của bạn , vì vậy hãy tiếp tục và làm những gì bạn biết là đúng. Điều đó không có nghĩa là bạn phải thay đổi mã của người khác, nhưng điều đó có nghĩa là bạn phải chịu trách nhiệm về chất lượng mã mà bạn viết.


2
+1 Bạn đang tập trung vào các mối quan hệ và cảm xúc. Các lập trình viên bạn đang làm việc với âm thanh rất khô khan nhưng họ chỉ tập trung vào các vấn đề về mã. Điều này khá phổ biến trong môi trường lập trình mà tôi đã làm việc. Tôi đã thấy điều này bất kể giới tính bằng cách nào.
Michael Durrant

14

Một bổ sung cho các câu trả lời khác:

Là một Nhà phát triển chính, tôi thường kén chọn hơn với các nhà phát triển cơ sở vì họ dễ uốn nắn hơn nhiều so với những người đã làm việc trong một vài năm. (Kỹ năng ppl của tôi không tốt ... chưa.)

Rất khó để thay đổi một người đã làm việc (và kiếm được mức lương xứng đáng) trong một thời gian và hài lòng với mức độ mã của anh ấy / cô ấy (mặc dù chất lượng có thể được cải thiện). Những kẻ đó không quan tâm nếu bạn cố gắng hướng dẫn họ trở thành những lập trình viên giỏi / giỏi hơn. Họ rất vui khi làm việc trong nhà máy sản xuất mã.

Những người mới, giống như bạn, OTOH, thường khao khát được hướng dẫn và biết điều gì đúng và không. Ngoài ra, họ có thể hấp thụ sự trở lại và thay đổi cách của họ để tốt hơn. Họ không được thiết lập theo cách khác.

Nếu bạn ghi nhớ những lời khuyên này và biến chúng thành một phần trong cuộc sống hàng ngày của bạn, bạn sẽ thấy rằng bất cứ lúc nào bạn sẽ viết mã vượt trội so với phần lớn cơ sở mã hiện có.

Vì thế ...

.. có thể là bạn đang nhận được nhiều phản hồi hơn chỉ vì bạn có tiềm năng để tạo ra thứ gì đó. :)


Điều này làm tăng rất nhiều điểm tốt.
Sevenseacat

13

Hoàn toàn có khả năng bạn đang bị chỉ trích vì ... bạn là nhà phát triển cơ sở.

Từ mô tả của bạn, có vẻ như bạn đã không tuân theo tiêu chuẩn khi nhóm trưởng nhận thấy điều đó .

Giải pháp rất đơn giản:

  • Nếu đó là tiêu chuẩn, hãy làm theo nó.
  • Nếu bạn không hiểu tiêu chuẩn, hãy yêu cầu làm rõ.
  • Nếu cách giải thích của bạn về tiêu chuẩn hoặc hướng dẫn khác với hướng dẫn của nhóm, hãy yêu cầu làm rõ

Đừng tạo ra một trận chiến từ nó; nếu bạn cố gắng làm cho đội dẫn đầu "sai" thì ngay cả khi bạn thắng, bạn vẫn thua. Học bài học thích hợp và tiếp tục phát triển.


1
Cố gắng làm theo một số "tiêu chuẩn" thành "T" khi một người đang đối phó với những người giả như cô mô tả sẽ không làm được gì nhiều. Nó sẽ là một cuộc tranh cãi bất tận về định nghĩa và ngữ nghĩa.
MrDatabase

4
@MrDatabase Họ không giống với tôi. Một chút kén chọn, có lẽ, nhưng ma quỷ thường trong các chi tiết và một khi bạn bắt đầu trượt tiêu chuẩn của mình, toàn bộ ứng dụng của bạn có thể xuống dốc nhanh chóng.
Adam Lear

3
Đúng là các tiêu chuẩn cần được tôn trọng. Tuy nhiên, cô chứng minh rõ ràng rằng nó không thực sự là một tiêu chuẩn (các nhà phát triển trước đó đã không tuân thủ nó). Do đó, đồng nghiệp của cô ấy áp đặt "tiêu chuẩn" lên cô ấy (không nói điều gì đó như "nhìn này ... chúng tôi biết điều đó có vẻ không nhất quán nhưng chúng tôi thực sự đang cố gắng cải thiện cơ sở mã của mình") là đạo đức giả và không có ích. Khi đồng nghiệp hành động như vậy, bạn cần có cách tiếp cận khác, thông minh hơn.
MrDatabase

@ user15859: nếu bạn đang đề cập đến câu trả lời của tôi, đó hoàn toàn không phải là ý định của tôi. Tôi tin rằng tôi đã nói chính xác những điều mà Anna đã nói trong câu trả lời của cô ấy. Không có ý định xúc phạm. Các vi phạm tiêu chuẩn mà bạn đề cập rất quan trọng đối với việc bảo trì dài hạn và bất kỳ sự mơ hồ nào trong phạm vi áp dụng các tiêu chuẩn phải được giải quyết với nhóm trưởng của bạn. Nếu bạn lười biếng, bạn sẽ không đăng ở đây. Nếu bạn không đủ năng lực, bạn sẽ không quan tâm lắm. Tôi không tin bạn là một trong số đó.
Steven A. Lowe

1
Tôi nghĩ rằng cô ấy đang đề cập đến những gì Woot4Moot đã nói khi anh ấy sử dụng "sự lười biếng và không đủ năng lực" như một cụm từ trong bình luận của mình. Tôi nghĩ rằng câu trả lời của bạn là tốt vì nó cung cấp cho OP một số lời đề nghị và phòng để hành động dựa trên sự giải thích của cô ấy về những gì đang thực sự xảy ra.
jmort253

10

Lời nhắn của tác giả

Vài năm sau đó; Tôi đã chỉnh sửa nó để phản ánh chính xác hơn cảm giác của tôi về tình huống này. Tôi đang đặt nhiều sắc thái hơn vào câu trả lời của mình vì tôi đang tìm hiểu thêm về sắc thái trong những tình huống này. Thật dễ dàng để yêu cầu một câu trả lời 'đen hoặc trắng', nhưng tất cả chúng ta đều biết rằng nó không đơn giản. Câu trả lời của tôi bây giờ phản ánh điều đó.

Từ những gì bạn đã mô tả; hành vi bạn gặp phải dường như không liên quan gì đến giới tính của bạn. Điều đó không có nghĩa là bạn không trải qua bất kỳ điều trị nào liên quan đến giới tính (tôi hy vọng bạn không), chỉ có điều những gì bạn mô tả dường như không liên quan đến giới tính.

Khi tôi là trưởng nhóm, tôi đối xử bình đẳng với mọi người. Không có chỗ trong công nghệ để đối xử tệ với ai đó vì giới tính của họ. Tôi không biết làm thế nào để đối phó với nó nếu nó xảy ra với bạn.

Điều quan trọng là bạn tin tưởng rằng Trưởng nhóm của bạn đối xử bình đẳng nam nữ. Nếu có bằng chứng anh ta không có, thì câu nói cũ được áp dụng: Thay đổi môi trường của bạn hoặc thay đổi môi trường của bạn.

Bằng nhau, ý tôi là anh ấy đối xử bình đẳng với mọi người mà không tôn trọng giới tính. Nếu anh ta đang làm công việc của mình một cách chính xác, bạn không nên thấy anh ta phê bình bất cứ ai khác; và họ không nên nhìn thấy anh ta chỉ trích bạn. Trước những người khác, việc trưởng nhóm thể hiện sự tự tin là rất quan trọng, ngay cả khi anh ta chỉ dành năm phút cuối cùng trước khi sửa chữa hành vi riêng tư.

Bây giờ về các vấn đề bạn nêu ra:

Bạn đã kiểm tra mã không đáp ứng tiêu chuẩn mà anh ấy đặt ra, vì vậy anh ấy đã từ chối chi nhánh của bạn. Nếu tôi ở trong đôi giày của anh ấy, tôi sẽ không làm điều tương tự theo cách tương tự, nhưng tôi sẽ đảm bảo rằng cấp dưới của tôi (từ lẻ; vì tôi không nghĩ rằng một nhà lãnh đạo là 'vượt trội' so với những người mà họ chì; nhưng nó chính xác (không đầy đủ) mô tả tình huống) biết điều đúng đắn cần làm là gì. Nếu họ không biết các tiêu chuẩn là gì, đó là lỗi của tôi với tư cách là một nhà lãnh đạo. Tùy thuộc vào tôi để sửa nó. Trong trường hợp này, bạn có thể đã phạm sai lầm, nhưng thực tế là nó đã xảy ra có nghĩa là bạn 1) không được cho biết điều đúng đắn cần làm là gì hoặc 2) không được đưa ra một cách thích hợp. Không phải lỗi của bạn.

Một trong những phần quan trọng nhất của việc trở thành một lập trình viên là nhận ra rằng cơ sở mã mà bạn làm việc phải được duy trì bởi nhiều người khác nhau. Bất kỳ mớ hỗn độn biến đổi hoặc những thứ khác làm mất khả năng đọc mã đều không minh bạch đối với khách hàng , vì phải mất nhiều thời gian hơn để khắc phục các sự cố trong mã khó đọc hơn.

Nếu nhóm của bạn đã viết hướng dẫn mã hóa, hãy làm theo chúng. Nếu họ không làm như vậy, thì sẽ có một số loại quy ước cộng đồng cho ngôn ngữ của bạn (Đối với .NET và C #, Microsoft có một tiêu chuẩn mà rất nhiều công ty tuân theo).

Hỏi Trưởng nhóm của bạn nơi hướng dẫn mã hóa để bạn có thể chắc chắn rằng bạn tuân theo chúng. Đưa hai bản kiểm tra vào các cuộc họp của bạn trong đó hai nhà phát triển khác không tuân thủ các nguyên tắc, để khi anh ta nói không có, bạn có thể chỉ ra rằng những người khác dường như cũng gặp vấn đề với nó và mọi người đều được hưởng lợi từ việc có những hướng dẫn.

Nếu anh ấy đối xử công bằng với bạn, thì anh ấy sẽ thấy điều này và điều này sẽ nằm trong đầu danh sách những việc cần làm của anh ấy. Nếu anh ta không đối xử công bằng với bạn, thì bạn có đạn nếu điều đó cứ xảy ra.

Nói "Tôi sẽ hiểu nó sau" là xấu. Sau này không bao giờ xảy ra. Hãy dành thời gian để làm điều đó đúng. Không có sau này trong lập trình.

Thật khó khi bạn là một nhà phát triển cơ sở. Bạn cảm thấy áp lực khi thực hiện và có rất nhiều người đang nhìn bạn, và mọi sai lầm bạn mắc phải đều gắn liền với tên của bạn trong kiểm soát nguồn mãi mãi.


1
Tôi sẽ bình luận thứ hai về "Tôi sẽ nhận được nó sau". Nếu tôi có niken mỗi lần tôi nghe thấy điều đó, thì tôi sẽ không ở đây để gõ bình luận này. :-)
Eric King

Đối với .Net có kiểu cop. Bật nó lên, để mã sẽ không được xây dựng cho đến khi StyleCop hài lòng. Điều này loại bỏ sự chủ quan của con người là bắt nạt lực lượng lao động. Bạn thấy đấy, công nghệ có thể giúp bạn quyết định xem Michael Phelps là # 1 hay # 2. Trong trượt băng nghệ thuật, tuy nhiên ... figureskating.about.com/od/famousskaters/tp/scandals.htm Là một đội không nên về điện vấp ngã. Không nên có [dis-] mục yêu thích trong một đội. Người ta phải cẩn thận để đảm bảo rằng ấn tượng đó không được hình thành. Một cách tốt để làm như vậy là bật các quy tắc sẽ kiểm tra mã và cung cấp cho bạn một câu trả lời không thiên vị.
Công việc

3

Không ở đâu trong bài viết của bạn, bạn đề cập đến cách những người khác xung quanh được đối xử. Bạn cứ lặp đi lặp lại rằng bạn "cảm thấy" bạn đang "độc thân" bởi vì bạn là "phụ nữ".

Tôi nghĩ rằng bạn đang được đối xử như một lập trình viên cơ sở bất kể giới tính của bạn và bạn nên biết ơn vì điều đó, vì đó là ý nghĩa của sự bình đẳng. Tôi cũng cảm thấy bạn đang làm ầm ĩ lên những thay đổi thẩm mỹ mã nhỏ, dài 5 phút mà bạn được yêu cầu thực hiện ngay bây giờ thay vì đưa chúng vào danh sách việc cần làm và không bao giờ tiếp cận chúng.

Không ở đâu trong bài viết của bạn, bạn đã đề cập đến việc bạn được lệnh làm những việc này vào cuối tuần. Nó có thể là hoàn toàn tốt để kiểm tra các bản sửa lỗi vào sáng thứ Hai.

Trưởng nhóm của bạn có thể là một chút tầm thường đối với thị hiếu của tôi, nhưng từ bài đăng của bạn, tôi không thấy có gì sai với yêu cầu của anh ấy hoặc cô ấy.

Xin vui lòng ngừng chơi thẻ giới tính cho không có gì . Tôi cảm thấy điều này là không đúng đắn và làm suy yếu khái niệm bình đẳng giới.


1

Tôi không cảm thấy việc từ chối chi nhánh của mình trên cơ sở này là hữu ích. Rất nhiều người đã làm việc vào cuối tuần, và tôi chưa bao giờ nói rằng tôi sẽ làm việc. Thực tế, một số người có thể đã bị chặn vì tôi không có thời gian để thực hiện các thay đổi và gửi lại. Chúng tôi đang làm việc trên một dự án rất nhạy cảm với thời gian và dường như với tôi rằng việc từ chối hoàn toàn mã dựa trên những điều minh bạch đối với khách hàng là không hữu ích. Tôi có thể sai, nhưng có vẻ như những điều này nên được xử lý theo kiểu cam kết khi tôi có thời gian.

Thật khó để nói bất cứ điều gì hữu ích như một người không nhìn thấy mã của bạn cũng như không biết gì về lịch trình dự án của bạn. Nhưng, nếu khách hàng tiềm năng của bạn cư xử có trách nhiệm và làm tốt công việc, anh ta biết rằng những người khác không thực sự bị chặn và nước rút sẽ không bị trễ. Vì vậy, đừng lo lắng về điều đó. Có lẽ bạn đánh giá quá cao tác động đến cam kết của bạn. Mặt khác: nếu dự án của bạn là thời gian quan trọng và vượt qua tất cả các thử nghiệm, thì quá khó để từ chối mã, có thể được sửa sau khi phát hành trong chớp mắt.

Làm cho nó hoạt động Làm cho nó đúng Làm cho nó nhanh

Vì vậy, nếu người lãnh đạo của bạn đưa ra quyết định từ chối cam kết của bạn, như một chuyên gia anh ta nên biết, anh ta đang làm gì.

Bây giờ, tôi có thể thấy rằng trong một số môi trường, đây sẽ là chuẩn mực. Tuy nhiên, những lời chỉ trích dường như không được phân bổ đều, đó là điều dẫn đến vấn đề tiếp theo của tôi. Cơ sở của hầu hết các vấn đề này là do thực tế là tôi đã ở trong một cơ sở mã mà người khác đã viết và đang cố gắng xâm lấn tối thiểu. Tôi đã bắt chước các tên biến được sử dụng ở nơi khác trong tệp. Khi tôi nói điều này, tôi đã nói thẳng: "Đừng bắt chước người khác, chỉ cần làm những gì đúng."

Là một Junior, thật khó để tìm được đường vào một cơ sở mã công ty.

Tốt nhất: có các tiêu chuẩn mã hóa được ghi lại - và bạn hy vọng sẽ học được cách nắm bắt chúng.

Thông thường: có các tiêu chuẩn mã hóa không có giấy tờ - và bạn phải học qua thử nghiệmlỗi hoặc tôi nên nói cam kết và _reject? Điều này thường gây đau đớn (như trong trường hợp của bạn). Điều này đôi khi nguy hiểm về chất lượng mã và có thể dẫn đến lập trình sùng bái hàng hóa , trong đó người ta không chỉ bắt chước cách đặt tên biến, mà còn sao chép và dán các cấu trúc và mẫu từ cơ sở mã một cách trung thực, nó phải được thực hiện như vậy. Đừng làm thế! Thậm chí không bắt chước cách đặt tên biến hiện có.

Bám sát mã sạch . Đó là thực hành tốt và cung cấp cho bạn một vị trí dễ dàng để bảo vệ. Nếu nó có thể đọc được, có thể kiểm tra và có thể bảo trì mã, bạn hầu như đã giành được bất kỳ cuộc thảo luận nào.

Và điều này dẫn đến một lời khuyên khác (cuối cùng): Thực hiện theo quy tắc trinh sát của cậu bé !

Luôn luôn để codebase ở trạng thái tốt hơn so với trước đây. Ngay cả khi mã xung quanh bạn đang làm việc khó chịu, hãy làm sạch mã của bạn - và nếu bạn có thời gian sửa chữa môi trường xung quanh.


0

Dành một ít thời gian để tìm hiểu các sắc thái khác nhau trong tính cách của đồng nghiệp. Theo kinh nghiệm của tôi, bạn có thể tránh những lời chỉ trích vô lý, không cần thiết, không nhất quán hoặc chỉ đơn giản nếu bạn làm việc xung quanh những đồng nghiệp của mình.

Ví dụ, một số đồng nghiệp có thể bị đói vào thứ Hai. Họ có thể rất cáu kỉnh và quá háo hức từ chối các nhánh mã hoặc cam kết nhất định. Nếu bạn phải làm việc với ai đó như thế này, hãy cố gắng tránh việc cam kết mã vào thứ Hai.

Mặt khác, một đồng nghiệp đói bụng có thể quá quan tâm đến tính dài dòng của các thông báo lỗi ... vì vậy sáng thứ Hai có thể là thời điểm hoàn hảo để thực hiện mã của bạn :-p

Các quirks cá tính trong văn phòng hoặc nơi làm việc là vô tận theo nghĩa đen. Hy vọng bạn có thể tìm hiểu ai nên tránh và khi nào nên tránh họ. Ngoài ra, đừng quá khó khăn với bản thân :-) Bạn luôn có thể bỏ việc và tìm một công việc khác!


1
Tìm việc trước khi bạn nghỉ việc, rất nhiều nhà quản lý tuyển dụng thậm chí sẽ không phỏng vấn nếu bạn không có việc làm.
Woot4Moo

-2

Tôi chưa bao giờ làm việc trong một môi trường mà mã bị từ chối trên cơ sở những quy ước nhất định không được tuân theo. Nếu tôi ở trong đôi giày của bạn, tôi sẽ bị cám dỗ tìm kiếm việc làm ở một nơi mà tôi được trao quyền nhiều hơn để đưa ra quyết định đúng đắn và nơi khách hàng là trọng tâm chính, không phải là mã.

Tôi không nói mã sạch và tiêu chuẩn không quan trọng, nhưng khách hàng và dòng thời gian của sản phẩm không nên mắc phải vì lỗi chính tả trong một điều mà không một người phi kỹ thuật, khách hàng hoặc giám đốc điều hành nào sẽ thấy.

Như đã nói, có vẻ như bạn có thể đang làm việc trong một môi trường mà kỳ vọng không rõ ràng hoặc bạn không hiểu đầy đủ các yêu cầu, vì bất kỳ lý do gì.

Bất kể tình huống nào, tùy thuộc vào bạn để kiểm soát và đặt câu hỏi làm rõ. Hãy chủ động, nếu bạn chưa sẵn sàng. Các thành viên trong nhóm và trưởng nhóm của bạn có thể sẽ tôn trọng bạn hơn khi đặt câu hỏi để làm rõ các quy tắc đăng ký. Bạn cũng có thể yêu cầu "đánh giá sau hành động" nơi bạn và nhóm trưởng của bạn thảo luận về những gì bạn nên làm thay thế và cách bạn có thể cho biết sự khác biệt khi có hành động nhất định và khi nào không.

Tôi khuyên bạn nên dành thời gian, vì bạn là người mới, để xem liệu bạn có thể vượt qua mọi rào cản và giải quyết các vấn đề này bằng kinh nghiệm, giao tiếp và học các tiêu chuẩn hay không. Tuy nhiên, nếu sau vài tháng, tình hình không thay đổi và môi trường vẫn bị ảnh hưởng bởi sự mơ hồ, có lẽ đã đến lúc tìm kiếm việc làm ở một công ty khác.

Không phải mọi tổ chức đều hà khắc này, và bạn có thể thấy các môi trường làm việc khác phù hợp hơn với tính cách, phong cách và yêu cầu giao tiếp của bạn.


2
Điều này không có vẻ "hà khắc"; tính nhất quán là một thành phần quan trọng trong khả năng bảo trì, khả năng bảo trì là một thành phần quan trọng trong chất lượng và phần mềm chất lượng có cơ hội vận chuyển đúng hạn và chi phí thấp hơn nhiều so với 'mã thỏa hiệp'. Có thể khuyến khích rằng một cái gì đó giống như 80% các công ty phần mềm đang mong muốn thỏa hiệp chất lượng và chịu hậu quả, do đó dường như không có bất kỳ cơ hội việc làm "phi hà khắc" nào. :)
weberc2 20/03/2015

1
Tôi sẽ không muốn làm việc trong một môi trường mà các quy ước cơ bản không được thi hành. Nếu một dự án từ bỏ việc bảo vệ các nguyên tắc mã hóa của nó, thì nó sẽ bị tiêu diệt trong thời gian dài. Đặc biệt việc đặt tên biến không phải là một điều nhỏ nhặt: Cho dù có bao nhiêu mã hiện có được gọi là một ma trận nhất định A, tôi sẽ không bao giờ chấp nhận một cam kết gọi một ma trận khác Bđể thống nhất. Tất nhiên, tôi không biết OP có nghĩa là gì khi "bắt chước [...] tên được sử dụng ở nơi khác", tuy nhiên, với chất lượng của một số mã tôi đã thấy, nó có thể nằm dọc theo các dòng này.
cmaster
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.