Làm thế nào tôi có thể yêu cầu sếp của tôi (một cách lịch sự) nhận xét mã của mình?


72

Tôi đang được ông chủ của tôi dạy (tôi vừa học xong và anh ấy muốn một người có ít kinh nghiệm lập trình, vì vậy anh ấy đã chọn tôi đào tạo tôi về những gì công ty đó chuyên về) và bắt đầu làm việc với các ứng dụng ASP.NET MVC , một số HTML và CSS . Tôi ổn với những thứ thiết kế web mà anh ấy đưa cho tôi (khá đơn giản để hiểu mà không cần làm rõ).

Nhưng ví dụ, anh ấy giao cho tôi một nhiệm vụ phải làm với ASP.NET MVC, anh ấy giải thích nó rất tốt. Nhưng anh ta không giải thích bất cứ điều gì trong mã anh ta vừa đưa cho tôi. (Chúng tôi sử dụng kiểm soát nguồn trong Visual Studio 2013 ), do đó, nó thực sự là hàng trăm dòng mã, không có bất kỳ nền tảng nào về những gì nó phải làm. Loại mã mà tôi đang xem là mã tôi chưa từng thấy trước đây, vì vậy rất khó để thử và tìm ra.

Tôi sẽ thử và hỏi anh ấy nhiều câu hỏi hơn, nhưng anh ấy luôn làm việc (đó là việc riêng của anh ấy), và tôi cảm thấy như thể anh ấy có thể cảm thấy khó chịu với tất cả những câu hỏi tôi có trong tay.

Vì vậy, chỉ cần một cái gì đó sẽ giúp tôi ra ngoài cho đến khi tôi nắm bắt được mọi thứ, làm thế nào tôi có thể yêu cầu sếp của tôi đưa ý kiến ​​vào mã của mình mà anh ấy đưa cho tôi, nhưng một cách lịch sự?


2
Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .
maple_shaft

1
Một cách khác để hỏi là sử dụng các công cụ lập chỉ mục và điều hướng mã nguồn như SourceGraph .
Dan Dascalescu

Gần đây tôi đã bắt đầu trong một nhóm làm việc trên một ứng dụng MVC5 lớn (> 100 nghìn dòng). Có 150 bài kiểm tra đơn vị cho toàn bộ và tất cả chúng đều được tôi thêm vào trong vài tháng qua. Một số ý kiến ​​trong mã chủ yếu là trong các ngôn ngữ khác. Welcome to business programming :)
Mark K Cowan

Các câu hỏi như "Làm thế nào để tôi yêu cầu X làm Y" thường tốt hơn ở Nơi làm việc khi X liên quan đến đồng nghiệp.
Blrfl

Câu trả lời:


130

Bạn đang ở trong 'tận cùng' và, theo tôi, đó là cách tốt nhất để học. Không phải vì bạn đang xem những thứ bạn không có đầu mối, mà bởi vì nó buộc bạn phải tháo vát hơn và tìm ra thành phần nào đóng vai trò trong hệ thống mà bạn chưa quen.

Điều đó không giúp ích gì cho việc sếp của bạn quá bận rộn để xử lý ai đó tò mò (và bạn hoàn toàn thuộc quyền của mình để tìm hiểu; bạn rất muốn học, điều đó tốt). Nhưng, thật không may, yêu cầu cấp trên của bạn thay đổi phong cách và cách tiếp cận của họ vì lợi ích của việc học của bạn có thể không đi xuống quá tốt, đặc biệt là khi bạn đang đối phó với ai đó mà bạn nói là bận rộn.

Được ngồi trước hàng ngàn dòng mã mà bạn không quen thuộc là tiêu chuẩn. Bạn không thể luôn luôn giải thích nó bằng màu đen và trắng với các bình luận. Tuy nhiên vì lợi ích của việc học trong khi bạn chưa quen với nó, nếu bạn cảm thấy chắc chắn bạn phải hỏi ý kiến ​​của anh ấy - có thể giải thích lý do tại sao. Giải thích vì thực tế bạn không muốn làm phiền anh ấy bằng những câu hỏi vì anh ấy thường bận rộn. Điều này không chỉ xuất hiện ít hơn nhiều như bạn đang bảo anh ấy làm gì đó, mà nó còn mở ra các cuộc thảo luận về cách anh ấy có thể, thay vào đó, thích đặt câu hỏi sang một bên.


185
+1 cho "Được ngồi trước hàng ngàn dòng mã mà bạn không quen thuộc là tiêu chuẩn" - điều này không bao giờ xuất hiện trong các khóa học lập trình và nó luôn xuất hiện trong công việc.
pjc50

11
Cảm ơn bạn đã cho tôi hy vọng, tôi thực sự đã nghĩ đến việc bỏ công việc và đi đến trường đại học hoặc một cái gì đó. Tôi đã nói chuyện với anh ấy một lúc trước và anh ấy nói anh ấy rất ấn tượng với sự tiến bộ của tôi blah blah haha ​​.. @ pjc50 Tôi hoàn toàn đồng ý với bạn về cơ bản làm bài kiểm tra và bài học sau đó. Có lẽ tôi đã học được nhiều hơn trong tháng vừa qua so với 3 năm tôi đã ở trường!
Aidan Quinn

9
Chính xác. Lập trình như một giao dịch có hiệu quả đòi hỏi phải học nghề (có thể tự học), trong khi các khóa học CS có thể chứa rất ít lập trình thực tế. Chúng cộng sinh nhưng không giống nhau. Bạn không cần phải đến trường đại học để trở thành một lập trình viên tuyệt vời nhưng điều đó giúp bạn dễ dàng được tuyển dụng hơn, ngay cả khi khóa học có ít liên quan đến công việc bạn đang ứng tuyển.
pjc50

11
@AidanQuinn, hội chứng Impostor ( en.wikipedia.org/wiki/Impostor_sy Triệu chứng ) có thể gây khó khăn khi bắt đầu một công việc mới và thậm chí còn hơn thế khi bắt đầu công việc đầu tiên của bạn. Nếu anh ấy nói rằng bạn đang làm rất tốt, hãy nói với anh ấy.
Celos

6
Lập trình là phần lớn thời gian cảm thấy không đủ năng lực với những đợt bùng nổ xen kẽ ngắn của cảm giác thiên tài hoàn toàn giống như thần.
MrDosu

75

Đầu tiên, thu thập thông tin qua hàng ngàn dòng mã lạ và cảm thấy lạc lõng là cách mọi dự án phần mềm ở mọi nơi, từ lúc bắt đầu.

Sự khác biệt lớn nhất giữa bạn và một lập trình viên có kinh nghiệm là bạn không quen với nó.


Một vài điểm cần lưu ý:

  1. Với đủ nỗ lực, mỗi bit mã là có thể hiểu được. Rất nhiều người cảm thấy thất vọng nếu họ không thể tìm ra điều gì đó trong vòng vài phút. Hãy kiên nhẫn hơn thế.

  2. Một ông chủ tốt là càng mở càng tốt để gián đoạn và câu hỏi. Một nhân viên tốt cố gắng hết sức có thể để giảm thiểu gián đoạn và câu hỏi. Hãy ý thức về điều đó.

  3. Gián đoạn là tốn kém hơn so với câu hỏi. Bạn có thể sử dụng tốt hơn thời gian của bạn và thời gian của sếp bằng cách củng cố các cuộc thảo luận của bạn và không bao giờ kết thúc cuộc trò chuyện cảm thấy bối rối.

  4. Sếp của bạn là một lập trình viên giỏi hơn bạn. (Có lẽ.) Điều đó không có nghĩa là bạn không thể mạnh hơn trong một số lĩnh vực, nhưng nhìn chung chuyên môn của anh ấy tốt hơn. Cho đến khi bạn có nhiều kinh nghiệm, hãy chắc chắn rằng bạn đang học hỏi từ chuyên môn của anh ấy nhiều nhất có thể.

  5. Nếu bạn chắc chắn rằng nhiều bình luận sẽ giúp mã đáng kể, hãy hỏi sếp của bạn. "Thật khó cho tôi để hiểu những gì đang xảy ra ở một số nơi. Khi tôi tìm ra mọi thứ, bạn có phiền nếu tôi thêm ý kiến ​​không?" Có lẽ anh ghét bình luận. Có lẽ anh ấy sẽ thích nó. Có lẽ anh sẽ thờ ơ.

Tuy nhiên, cuối cùng, có thể một vài tháng sau bạn sẽ nhớ hỏi điều này và nghĩ, "Huh, tôi tự hỏi tôi có vấn đề gì với? Điều này không tệ lắm. Hừm, không sao cả."


6
Tôi đặc biệt thích điểm 3. Đôi khi thật hữu ích khi viết một email hai dòng nhanh chóng yêu cầu anh ấy đến giúp bạn một số vấn đề ngay cả khi anh ấy chỉ ngồi trong văn phòng cách bạn vài bước chân. Điều đó cho phép anh ta xác định khi nào anh ta sẵn sàng bị gián đoạn và cho phép bạn có thêm thời gian để xây dựng một danh sách câu hỏi đầy đủ hơn trước khi cuộc thảo luận thực sự diễn ra.
Phil

1
đến @Phil. Bạn sẽ ngạc nhiên về số lượng câu hỏi mà bạn tự tìm ra câu trả lời, chỉ bằng cách cẩn thận tạo ra một câu hỏi rõ ràng trong email. Chỉ cần quá trình giải thích sự nhầm lẫn của bạn với độ chính xác có thể bật đèn. Không thể cho bạn biết bao nhiêu lần tôi đã viết email loại đó không bao giờ được gửi bởi vì tôi đã tìm ra nó.
kmote

3
@kmote, tôi có nhiều câu hỏi Stack Overflow không được trả lời đã xảy ra theo cách tương tự :)
Paul Draper

18

Nếu sếp của bạn không có thời gian để trả lời tất cả câu hỏi của bạn, tại sao bạn nghĩ rằng anh ta sẽ có thời gian để bình luận mã di sản của mình? Và hơn nữa, điều gì khiến bạn nghĩ rằng những bình luận của anh ấy sẽ thực sự mô tả các bit và phần mà bạn không hiểu bây giờ? Theo kinh nghiệm của tôi, cố gắng thay đổi phong cách lập trình của sếp bằng cách chỉ hỏi anh ta sẽ không làm việc, lịch sự hay không.

Điều tốt nhất bạn có thể làm trong tình huống như vậy: nhận xét các phần của mã bạn cần hiểu để tự thực hiện công việc của mình - tất nhiên một khi bạn đã hiểu những phần đó, và sau khi nhận được cam kết từ sếp của bạn rằng điều này sẽ ổn. Nếu bạn hoặc sếp của bạn sợ bạn có thể phá vỡ một cái gì đó bằng cách thêm nhận xét, hãy thêm những bình luận đó vào một nhánh riêng và hỏi sếp của bạn nếu anh ta sẽ dành thời gian để xem xét nhận xét của bạn trước khi chúng được hợp nhất vào thân cây. Vì sếp của bạn chỉ có ngân sách thời gian hạn chế, hãy cố gắng tự mình tìm ra một phần nhất định bằng cách đầu tư một khoảng thời gian hợp lý. Nếu bạn thực sự gặp khó khăn, hãy viết câu hỏi của bạn vào một danh sách và hỏi sếp của bạn, ví dụ, mỗi ngày một lần thay vì làm phiền anh ta 30 phút. Theo kinh nghiệm của tôi, phương pháp này hiệu quả với hầu hết mọi người, ngay cả khi họ rất bận rộn, miễn là họ sẵn sàng giúp đỡ bạn - đó là điều chắc chắn trong trường hợp của bạn.

Bằng cách này, bạn chắc chắn rằng bạn nhận được những bình luận bạn cần, và sếp của bạn sẽ thấy nơi bạn cần thêm thông tin, và nếu bạn đã làm đúng. Và miễn là bạn hạn chế chỉ bình luận những điều không rõ ràng, rất có thể bình luận của bạn sẽ tăng chất lượng tổng thể của cơ sở mã, điều này không chỉ mang lại lợi ích không chỉ cho bạn mà còn cho tất cả những người khác phải đối phó với mã, bao gồm cả ông chủ của bạn.


3
Bạn cũng có thể đề xuất một bản vá thêm một số ý kiến ​​cho sếp của bạn.
Basile Starynkevitch

2
@BasileStarynkevitch: tất nhiên, để tránh nguy cơ phá vỡ thứ gì đó, anh ta có thể thêm ý kiến ​​vào một nhánh riêng trước và yêu cầu sếp của mình xem xét các bình luận trước khi chúng được hợp nhất vào thân cây.
Doc Brown

2
@DocBrown Làm việc trong một chi nhánh riêng nói chung là một chiến lược tốt, nhưng nếu việc thêm ý kiến phá vỡ điều gì đó, thì tôi sẽ nói rằng cơ sở mã hóa có vấn đề lớn hơn ......
CVn

1
@ MichaelKjorling: thực ra, đó là điều mà OP nên thảo luận với ông chủ của mình. Sử dụng một nhánh khác có hai ưu điểm: nó tránh được các lỗi vô ý bằng cách tạo ra một lỗi đánh máy như xóa một dòng quá nhiều khi xóa một bình luận lỗi thời và nó đẩy sếp xem xét các bình luận.
Doc Brown

@ MichaelKjorling không phải là về những bình luận phá vỡ một cái gì đó, mà là những bình luận cần phải phù hợp với mã thực tế.
Hugo Zink

8

Trước hết hãy để đây là một ví dụ để bạn nhận xét mã của bạn đúng cách, châu chấu!

Sau đó, tôi phải làm điều này mọi lúc. Tôi đã kiểm tra bản sao địa phương của mình và tôi xem qua nó và tự nhận xét. (Tôi có thể loại bỏ tất cả chúng ra một lần nữa nếu tôi sẽ kiểm tra lại - hoặc để chúng vào, nếu không ai bận tâm.) Điều này (những gì tôi nhận xét), tôi có đúng không? Vì vậy, bạn có thể đã thực hiện bình luận thực tế, nhưng nó đã được thực hiện và đó là điểm chính.


5

Đây không chỉ là một yêu cầu cá nhân. Bạn đang cố gắng thay đổi thói quen / văn hóa, và điều đó không dễ dàng. Đó chắc chắn không phải là thứ có thể được thực hiện bằng một cuộc trò chuyện trên hành lang hoặc e-mail. Nó sẽ mất một số nỗ lực từ phía bạn.

Hãy là sự thay đổi mà bạn muốn thấy trên thế giới.

Câu trích dẫn có thể được gán sai cho Mahatma Gandhi, nhưng đó là lời khuyên áp dụng. Khi bạn cố gắng giải mã codebase, hãy viết những bình luận mà bạn muốn thấy, hết khả năng của bạn và cam kết chúng, sau khi được sếp của bạn xem xét. Ưu điểm:

  • Bạn đang chủ động, thay vì cằn nhằn.
  • Bạn đang làm gương tốt. Trong trường hợp tốt nhất, sếp / nhóm của bạn sẽ thấy những lợi ích và làm theo.
  • Một số ý kiến ​​có thể sẽ nói /* Mystery parameter 3 */hoặc /* 2015-02-09 AidanQuinn: Is this code ever called? */- đó là những cơ hội để các đồng nghiệp của bạn ghi lại mã đúng hoặc sửa các lỗi tiềm ẩn.
  • Nếu trong quá trình đánh giá trước khi cam kết, người ta phát hiện ra rằng một bình luận bạn đã viết là không chính xác, thì bây giờ các đồng nghiệp của bạn biết rằng mã này không rõ ràng.

Không được viết lại hoặc tái cấu trúc khi bạn thực hiện việc này và việc đưa ra các bình luận nên gần như không có rủi ro. Nếu bạn viết lại bất cứ điều gì, hãy giữ những thay đổi đó dưới dạng các cam kết riêng biệt.

(Tuy nhiên, trước khi bạn bắt tay vào dự án này, hãy chắc chắn rằng những mong đợi của bạn về nhận xét là hợp lý. Nếu ý tưởng của bạn về mã được nhận xét tốt nằm ngoài định mức ( Ví dụ 1 , Ví dụ 2 ), thì bạn sẽ chỉ bị lừa bản thân bạn.)


5

Tôi sẽ không hỏi thêm ý kiến, nhưng đây là một số ý tưởng cho bạn:

  1. Lên lịch ngồi xuống với sếp của bạn và để anh ta vượt qua mã ở cấp độ cao. Điều này sẽ giúp bạn bắt đầu. Tôi sẽ mong đợi một vài giờ đến có thể là nửa ngày để bạn có thể tăng tốc. Điều này nên bao gồm thiết kế tổng thể, các mẫu được sử dụng, vv
  2. Tạo một dự án thử nghiệm và bắt đầu viết thử nghiệm đơn vị đối với mã, điều này sẽ giúp bạn hiểu nó mà không ảnh hưởng đến nó. Bạn cũng có thể tìm thấy một số lỗi là tốt!
  3. Gỡ lỗi mã khi cần thiết để hiểu các khu vực nhất định.
  4. Hãy cải tiến hoặc sửa lỗi tồn đọng và làm việc với nó.

Nhận xét là OK, nhưng nếu mã được viết theo cách thẳng thắn thì có thể hiểu được sau vài ngày.

Cũng đừng hy vọng hiểu tất cả, tốt hơn hết là tập trung vào các lĩnh vực chính trước và sau đó mở rộng kiến ​​thức cơ sở mã khi cần thiết.


2

Tôi đã ở trong một tình huống rất giống với bạn khoảng một năm trước. Tôi bắt đầu làm việc với ít kinh nghiệm lập trình (mặc dù tôi biết một chút về OO và một số ngôn ngữ khác để bắt đầu) và một người dạy tôi có rất ít thời gian. Anh ấy luôn luôn hữu ích, nhưng tôi cảm thấy mình không muốn hỏi mọi câu hỏi mà tôi có.

Những người khác đã đề xuất những thứ cực kỳ hữu ích ở đây (ví dụ viết bài kiểm tra đơn vị, nhưng theo kinh nghiệm của riêng tôi, đó là thứ sẽ hơi "quá xa" đối với tôi từ đầu; hoặc tự nhận xét các phần của mã, nhưng điều đó có thể khó khăn tùy thuộc vào điểm / câu hỏi đầu tiên tôi sẽ hỏi bạn sau một phút nữa). Các điểm sau đây tổng hợp những gì tôi đã làm và những gì đã giúp tôi, nhưng nó phụ thuộc rất nhiều vào việc chính xác vấn đề của bạn nằm ở đâu.

Ngoài ra, tôi phải đồng ý với @AK_, người nói rằng bạn không thực sự cần bình luận trong C #. Điều đó có thể không đúng 100% (tôi cảm thấy có những lĩnh vực mà các bình luận chắc chắn có ích, ví dụ như mã phản chiếu nặng) nhưng thực chất nó là như vậy. Nếu bạn viết 'mã sạch' thực sự với các phương thức và biến được đặt tên tốt và có rất nhiều 'cắn' mã, chúng sẽ gần như không cần thiết. Bất cứ khi nào tôi cảm thấy cần bình luận khi đọc mã cho đến nay, sau khi tôi hiểu những gì nó đã làm, tôi rất không hài lòng với cách nó được thực hiện và nghĩ rằng nó có thể rõ ràng hơn ngay từ đầu bằng cách tái cấu trúc tốt. Chỉnh sửa: Tôi đặc biệt nói về các nhận xét C # ở đây, không phải tài liệu (có thể là tài liệu riêng hoặc nhận xét XML), vì tôi nghĩ rằng tài liệu đó luôn quan trọng.

  • Xác định chính xác vấn đề của bạn là gì và nếu bạn có thể phân loại chúng. Đó là, bạn vẫn có vấn đề với chính ngôn ngữ hoặc không hiểu một cú pháp cụ thể (ví dụ: biểu thức lambda và LINQ nói chung, hoặc Reflection)? Nếu bạn không hiểu các dòng mã, bạn sẽ không hiểu toàn bộ phương thức / khối làm gì, vì vậy việc tự nhận xét nó sẽ khó khăn. Thay vào đó, hãy lấy một cuốn sách hay ('C # in a Nutshell' nó dành cho tôi, nhưng tôi nghe nói 'C # in Depth' cũng rất ngoạn mục) và đọc những điều bạn gặp phải. Việc phân loại các vấn đề này trước giúp việc này trở nên dễ dàng hơn, vì bạn có thể lấp đầy 'khoảng trống lớn hơn' ngay lập tức hoặc thậm chí hỏi sếp về vấn đề đó, vì nó không còn nhiều câu hỏi nữa, mà là giải thích một chủ đề duy nhất hoặc các cấu trúc được sử dụng phổ biến nhất để bạn có thể nhận được một 'cú hích' khổng lồ

  • Song song với những điều trên, tôi đã cố gắng làm quen với 'mã hóa sạch' và các thực tiễn chung tốt nhất (không phải ngôn ngữ cụ thể). Hiệu quả của việc này có thể không phải là ngay lập tức, nhưng nó sẽ sớm được đền đáp, khi bạn phải mở rộng các công cụ hiện có hoặc tự hỏi tại sao ai đó tạo ra nhiều phương thức nhỏ thay vì một phương thức chứa mọi thứ ;-)

  • Hãy nắm bắt các mẫu thiết kế phổ biến. Chúng có thể xuất hiện ở đây và ở đó trong mã bạn đang đọc, và nếu bạn nhận ra chúng, nó sẽ ngay lập tức cho bạn một khoảnh khắc. Ngay cả khi bạn hiểu những gì mã bạn thấy ở đó, nó có thể khiến bạn tự hỏi tại sao nó được thực hiện theo cách này và việc tự mình tìm ra mã này thường không dễ dàng.

Xin đừng lấy văn bản trên khi tôi đưa ra các giả định về 'kỹ năng' của bạn, tôi thường vô tình chuyển đổi giữa việc nói về những trải nghiệm của tôi và nói 'với bạn'. Nó chủ yếu có nghĩa là những gì tôi gặp phải , và những gì tôi đã làm . Như những người khác đã nói, đây có thể là một trải nghiệm rất tốt và gần như là tiêu chuẩn trong công việc đọc mã không phải của riêng bạn và bạn không biết nhiều về trước. Nhưng nó có thể thực sự thỏa mãn khi cuối cùng cũng nắm bắt được những gì đang diễn ra ở đó và nhận ra bản thân bạn trở nên tốt hơn với 'kỹ năng' đặc biệt này. Hãy coi đây là cơ hội để học hỏi nhiều trong thời gian thực sự ngắn, chúc may mắn! :)


1

Bạn có thể sẽ không khiến anh ấy thay đổi phong cách.

Những gì bạn có thể làm là hỏi nhiều câu hỏi, và viết ra câu trả lời.

Tôi được thừa hưởng một cơ sở mã lớn trong công việc cuối cùng của tôi, ít tài liệu và một vài bình luận. Vì vậy, tôi sẽ cố gắng trong nửa giờ cho cùng một vấn đề, sau đó nếu tôi vẫn không thể tìm ra nó, tôi sẽ đi hỏi ai đó đã viết nó, hoặc biết cách sử dụng nó. Sau đó, tôi sẽ ghi lại tất cả những điều mà anh ấy nói với tôi. Hầu hết đã đi vào tài liệu của chúng tôi, một số đi vào mã dưới dạng bình luận. Sau một năm, tôi đã thực sự viết một phần lớn tài liệu của chúng tôi và tôi biết rất nhiều về cơ sở mã.

Chúc may mắn!


1

Tôi đã có cùng một vấn đề. Tôi là sinh viên của phyzist và có kinh nghiệm lập trình tốt. Tôi đã lập trình bằng nhiều ngôn ngữ nhưng không có gì cho ứng dụng cao cấp.

Tôi đã nộp đơn xin việc cho nhà phát triển web và họ ngay lập tức đưa tôi vào phần cuối của lập trình web. Khi ông chủ chỉ cho tôi api cơ sở cho ứng dụng REST nút, tôi đã nghĩ rằng tôi sẽ ném ra. Tôi chưa bao giờ thấy các chức năng với gọi lại và cú pháp lạ như vậy. Và tôi hỏi ông chủ của tôi rằng tôi có vấn đề gì không nếu tôi không hiểu bất cứ điều gì trong mã. Anh buồn không, anh buồn vì tôi có 1 tháng để tìm ra nó và trong thời gian đó tôi sẽ làm một CMS để thử nghiệm tôi với một người đi trước khác.

Vâng và tôi đã đi 1 dòng mã vào thời điểm đó và google mọi điều mà tôi chưa biết. Vì vậy, 1 tuần đã trôi qua và tôi đã quen thuộc với mã đủ để tôi có thể thực hiện một số kết hợp với front ender. Mã của tôi lúc đầu là tào lao nhưng se tôi 3 tháng sau đó! Tôi đang mã hóa tốt hơn và nhanh hơn kiến ​​trúc sư phần mềm của chúng tôi!

Tôi sugest rằng bạn không bao giờ ngừng học hỏi! My moto -> Tiếp tục học hỏi và giữ bình tĩnh :) Đừng phụ thuộc vào sếp hãy độc lập và hỏi anh ta trực tiếp nhưng chỉ là những vấn đề khó khăn nhất. Bởi vì bạn sẽ hạnh phúc sau khi bạn tìm ra nó bằng chính bản thân mình. Và hãy nhớ khi bạn ngừng học hỏi điều gì đó sai, hãy học ngày ewery làm thế nào để trở thành một lập trình viên giỏi.

Nếu bạn học được từ ông chủ, bạn sẽ không bao giờ giỏi hơn anh ta đặt ra tiêu chuẩn của riêng mình, học cách gõ mù, plugin VIM hoặc VIM cho IDE, Linux wmii của bạn, vì vậy một ngày nào đó bạn sẽ vượt qua ông chủ và tốt hơn anh ta!


bài này khá khó đọc (tường văn bản). Bạn có phiền chỉnh sửa ing nó thành một hình dạng tốt hơn?
gnat

Xin lỗi vì sự thiếu hiểu biết của tôi :)

bài đăng cập nhật dễ hiểu hơn nhiều (chỉnh sửa tốt!) nhưng những gì tôi có thể thấy bây giờ dường như chỉ lặp lại các điểm đã được thực hiện (và được giải thích rõ hơn) trong các câu trả lời trước, đặc biệt là trong bài này
gnat

1
Tôi xin lỗi, tôi đang làm việc này vào buổi sáng trước khi đi làm và tôi không có quá nhiều thời gian trong tay, vấn đề chính là chủ sở hữu câu hỏi sẽ thấy, vì những điểm tôi không quan tâm :)

0

Là một kỹ sư phần mềm có 20 năm, chủ yếu làm việc về các công cụ liên quan đến an toàn (SF-PD), tôi phải nói rằng ông chủ của bạn có thể không phải là người bạn muốn trở thành ví dụ của bạn. Thiếu ý kiến ​​là một dấu hiệu của một lập trình viên nghiệp dư tự học, người không bao giờ học được cách thực hiện công việc đúng cách, hoặc một kỹ sư thiếu kinh nghiệm. Hoặc có lẽ một kỹ sư đơn giản là không có thời gian - thời hạn và sự nhanh chóng có thể làm những điều khủng khiếp cho mã của bạn! ;) Đó chắc chắn là một mô hình chống cho mọi kỹ sư phần mềm có thẩm quyền.

Sếp của bạn có thể là một lập trình viên rất giỏi, nhưng có vẻ như anh ta không phải là một kỹ sư phần mềm giỏi. Một kỹ sư sử dụng kinh nghiệm nhóm tập thể để tránh những cạm bẫy mà người khác đã bị bắt gặp. Nhận xét hiệu quả là một phần của trải nghiệm nhóm tập thể đó đối với phần mềm, giống như phân tích ứng suất là một phần của trải nghiệm nhóm tập thể cho kỹ thuật cơ khí. Những gì được coi là nhận xét hiệu quả là trôi chảy hơn, và đó chắc chắn là thứ bạn có được từ kinh nghiệm.

Điều cơ bản nhất là các bình luận không nên nói những gì một dòng mã làm. Đôi khi, các bình luận cho biết những gì một chức năng làm là quá thừa (đặc biệt là trong C #). Nhận xét quá mức có thể chỉ là không hiệu quả (và là một con trỏ thiếu kinh nghiệm) bởi vì bạn không thể tìm thấy những thứ quan trọng trong quá khứ. Là một người mới, bạn vẫn có thể làm việc để tìm ra "cái gì" của mã, và bạn chỉ cần đọc và hiểu những gì anh ta đã làm.

Điều quan trọng cho các bình luận là họ nói TẠI SAO một dòng mã hoặc một hàm làm những gì nó làm, trong đó điều này có thể không rõ ràng. Bạn có cần thiết lập mô-đun X trước mô-đun Y không? Điều quan trọng là phải kiểm tra mã trả về để xem liệu một tệp đã được mở hay chúng ta có ý thức bỏ qua mã trả về vì điều này đã được kiểm tra ở một nơi khác? "Tại sao" của mã sẽ có liên quan đến tất cả mọi người, bất kể kinh nghiệm - và nó cũng sẽ liên quan đến anh ta trong 6 tháng, khi anh ta quên mất lý do chính đáng để làm một việc cụ thể. Nhận xét không chỉ dành cho người khác, nó cũng giúp bạn trong tương lai.

Nếu bạn muốn tránh làm phiền sếp, hãy hỏi những câu hỏi thông minh. Tập trung vào việc hỏi về "tại sao" và cố gắng tự mình tìm ra "cái gì" (trừ khi nó thực sự tối nghĩa). Không có ông chủ tốt nào sẽ bận tâm khi được hỏi những câu hỏi nếu chúng không phải là những thứ mà bạn có thể tìm thấy từ R-ing TFM. Và sẽ không có kỹ sư giỏi nào được yêu cầu làm điều gì đó sẽ giúp cuộc sống của một kỹ sư khác dễ dàng hơn, với chi phí thấp cho họ. (Chỉ cần đừng yêu cầu anh ấy điền vào các bình luận trên toàn bộ cơ sở mã!)


1
Đoạn đầu tiên ngụ ý rằng ông chủ Giáp và hầu hết những người còn lại của chúng tôi không đủ năng lực vì anh ta (giả định) không bình luận theo cách anh ta nên làm. Điều đó thật đáng tiếc, bởi vì những lời khuyên còn lại về thời điểm và cách nhận xét thực sự khá hợp lý. Hầu hết chúng ta có thể sẽ đồng ý với nó nếu chúng ta không thực hiện ngay từ đầu.
John M Gant

Ba đoạn cuối của câu trả lời của bạn khá hữu ích, @Graham. Xin đừng để một vài downvote làm bạn nản lòng.
DavidS

Tôi đã ngạc nhiên khi thấy các downvote. Thông tin về những gì, làm thế nào và tại sao để bình luận là chết trên. Tôi đồng ý với những người khác rằng suy đoán của bạn về năng lực của sếp là không hiệu quả.

@Superopescheese: Thật không may, bạn thường nhận được downvote vì giữ một vị trí khác ngoài "Mẹ và bánh táo". Tôi không đồng ý với một số điều bạn nói (không phải đoạn đầu tiên! IMO hoàn toàn hợp lệ) - nhưng bạn vẫn nhận được một upvote trên nguyên tắc.
einpoklum

0

Đã ở trong tình huống tương tự, tôi nói

  1. Sếp của bạn có thể muốn bạn học cách bẩn thỉu (bằng cách duyệt qua mã mà bạn không có đầu mối) vì một lý do. Đây là cách chúng ta học được nhiều hơn trong một tháng tại nơi làm việc hơn là một năm ở trường đại học như được đề cập trong các câu trả lời khác.

  2. Đây là "chuẩn mực" như được đề cập trong các câu trả lời khác. Bạn nên lo lắng hơn về việc bắt đầu từ đâu và làm thế nào để tiếp cận và tập trung vào điều gì hơn là cố gắng hiểu mọi dòng mã ngay lập tức. Hỏi sếp của bạn về các công cụ phù hợp và cách để gỡ lỗi / bước qua mã. Loại câu hỏi này sẽ mua cho bạn một số điểm.

  3. Một cách thường xuyên, hãy tiếp cận với sếp của bạn để nhận phản hồi về cách bạn đang làm để bạn có ý tưởng về việc bạn đứng ở vị trí phần trăm với giả định rằng sếp của bạn đã nhìn thấy nhiều người trong tình huống tương tự và có ý tưởng về cách họ làm.

  4. Hãy coi đây là một cơ hội và khi bạn hiểu rõ hơn về mã, hãy tiếp tục thêm các bình luận mà ban đầu bạn dự kiến ​​sẽ hỏi sếp của bạn.


0

Nếu bạn thực sự muốn thử yêu cầu anh ấy đưa ý kiến ​​vào mã của anh ấy (tôi không khuyên bạn) tôi sẽ đề nghị tìm mã mà bạn cần chỉnh sửa để thực sự có thể sử dụng một số nhận xét (hầu hết là tự giải thích) và đặt câu hỏi về như thế này "Tôi đã xem mã này ở đây và tôi đang cố gắng tìm ra [Vấn đề bạn gặp phải] và tôi không thể tìm thấy bất kỳ bình luận nào để giúp giải thích nó". Về cơ bản hãy cố gắng chứng tỏ rằng bạn đã nỗ lực để hiểu nó và giải thích lý do tại sao cả hai bạn đều có thể hưởng lợi từ những bình luận ở đó.

Có lẽ 90% mã được viết tốt không cần bình luận. Bạn chỉ thực sự muốn ghi lại các phần của mã đã được tối ưu hóa và trở nên khá căng thẳng. Tôi đã làm việc tại một công ty một lần yêu cầu bạn ghi lại từng đoạn mã mà bạn đã sửa đổi về cơ bản các bình luận cuối cùng gây bất lợi cho khả năng đọc mã vì họ thường nhắc đến mã đã bị xóa hoặc sửa đổi ngoài sự công nhận. Coi chừng những bình luận kém Tôi đã dành một tuần để gỡ lỗi một chức năng và cuối cùng tôi thấy rằng bình luận mà tôi tiếp tục đọc về việc đặt cờ như vậy và "sai" thực sự là toàn bộ vấn đề tôi đặt cờ thành "đúng" và mọi thứ đều hoạt động như nó được cho là


1
Mã không nhận xét không phải là mã được viết tốt. Tôi nói với các nhà phát triển của mình để đưa ra một nhận xét ở đầu mỗi khối như một quy tắc chung. Hoặc viết lại khối thành một phương thức với một tên tự ghi. Trừ khi phương thức của bạn là một câu lệnh if, một cuộc gọi phương thức và trả về, bạn cần một nhận xét.
người làm giàu giàu 10/2/2015

@richremer Tôi nghĩ chúng ta gần như hoàn toàn đồng ý. Tôi nhắm đến việc tự viết mã với các bình luận trong đó mọi thứ trở nên căng thẳng.
dkippers

0

Nếu bạn muốn nhận xét trong mã để hiểu lý do tại sao một cái gì đó đã được viết thì rất có thể (coi bạn là người mới) bạn chưa hiểu nhu cầu kinh doanh. Tôi chắc chắn bạn biết tất cả các cú pháp và có thể đọc mã nhưng trừ khi bạn biết mục đích của một số mã thì bạn sẽ cảm thấy hơi mất mát.

Một điều mà lò xo để tâm là lập trình cặp. Bạn nói rằng sếp của bạn rất ấn tượng với sự tiến bộ của bạn để bạn có thể đề nghị làm việc cùng với anh ấy. Điều này sẽ giúp cả hai bạn về lâu dài. Sếp của bạn sẽ thấy mình phải giải thích những điều anh ta coi là hiển nhiên và bạn sẽ tìm hiểu thêm về doanh nghiệp.


0

Như những người khác đã đề cập, điều này khá phổ biến, nhưng điều đó không có nghĩa là bạn chỉ cần mút nó và cày qua. Bạn không cần phải hiểu nhiều mã theo chiều sâu như bạn nghĩ, và có những chiến lược cụ thể để làm cho "kết thúc sâu" trở nên nông hơn:

  • Tìm một cái gì đó trong mã liên quan đến nhiệm vụ trong tay. Thông thường, thứ dễ tìm kiếm nhất là thứ mà người dùng có thể nhìn thấy, như nhãn của nút trên GUI. Viết xuống nơi bạn tìm thấy nó. Đây sẽ là điểm neo của bạn.
  • Bây giờ tìm kiếm mã đi một bước và viết nó xuống. Ai tạo ra nút? Mã nào được gọi khi nhấp vào nút?
  • Kiểm soát nguồn thường hữu ích cho việc tìm mã cách đó một bước. Tìm khi mã bạn đang xem được thêm hoặc thay đổi và xem mã nào khác được kiểm tra cùng lúc và tại sao.
  • Lặp lại cho đến khi bạn hiểu vừa đủ để thực hiện thay đổi của mình, cộng thêm một cấp độ sâu hơn để đảm bảo bạn không thiếu thứ gì.
  • Nếu bạn gặp khó khăn tại bất kỳ thời điểm nào, bây giờ bạn có một câu hỏi rất cụ thể để hỏi. Ví dụ: "Tôi không thể tìm ra nút này được khởi tạo từ đâu."

0

Dưới đây là 0,02 đô la của tôi về vấn đề này. Tôi không đề xuất một câu trả lời độc quyền, rất nhiều điều đã được nói ở đây khá phù hợp.

Tôi sẽ thử một chút kỹ thuật xã hội để sắp xếp mọi thứ để sếp của bạn thấy việc nhận xét một số mã của mình dễ dàng hơn / ít tốn thời gian hơn là không.

Bây giờ, điều này có thể khá dễ dàng nếu bạn sẵn sàng chấp nhận rủi ro lớn và làm phiền anh ấy - nhưng chúng tôi không muốn làm điều đó. (lưu ý bên lề: Bạn chỉ có thể không thể làm bất cứ điều gì mà không cần anh ấy viết ra hoặc đưa ra nhận xét cho bạn, bạn khăng khăng và làm phiền anh ấy về điều đó vô tận, v.v.)

Vậy thì cái gì thay thế? Một vài ý tưởng, tùy thuộc vào hoàn cảnh.

lựa chọn 1

  1. Dành thời gian để hiểu một đoạn mã của anh ấy khi làm X.
  2. Bây giờ nghĩ về một cách hợp lý Y để hiểu lầm nó.
  3. Nói với sếp (qua email hoặc nói qua bữa sáng hoặc những gì không phải) rằng bạn hiện đang cố gắng tìm ra nó.
  4. Thêm một bình luận nói rằng nó không rõ nghĩa của mã, nhưng bạn hiểu nó là Y; cố gắng làm cho nhận xét này hiển thị với anh ấy - nhưng đừng quá cố gắng!
  5. Hành động giả định Y - và đảm bảo rằng sếp của bạn nhận thấy hành động của bạn (vì vậy bạn không lãng phí thời gian làm việc trong một thời gian dài với giả định sai).
  6. Sếp nên chủ động sửa sai cho bạn. Tại thời điểm này, hãy nói với anh ấy điều gì đó như "Tôi thực sự muốn mã này có một vài bình luận để ngăn tôi đưa ra giả định sai. Tôi sẽ sửa nhận xét tôi đã thêm cho mình. Bạn có cho rằng bạn có thể giúp tôi với một số mô tả chung không Tôi có đủ kinh nghiệm để tìm ra ý định chính xác không và tôi chỉ cần một vài câu sẽ thực hiện được. " Hay cái gì đó ..

Tùy chọn 2

Bạn đang tập luyện. Cố gắng sắp xếp một cuộc họp hàng tuần với tần suất cố định (bổ sung?) Với anh ấy. Trong cuộc họp này đi qua một số mã - nhưng bạn cần phải chuẩn bị đủ để anh ta không phải giải thích từng dòng. Tại một số điểm - hy vọng - anh ấy sẽ nhận ra rằng anh ấy có thể bỏ qua cuộc họp nếu anh ấy chỉ cần thêm ý kiến.

Lựa chọn 3

Nhận một đồng nghiệp khác không hiểu được đoạn mã giống như bạn. Cả hai bạn tiếp cận sếp vào những thời điểm khác nhau hỏi những câu hỏi giống nhau. Đó là một cách chắc chắn để khiến anh ấy nhận ra mình không làm được điều gì đó ... nhưng không phải ai cũng có được sự sang trọng của những đồng nghiệp hữu ích trong cùng một dự án.


0

Vì vậy, chỉ cần một cái gì đó sẽ giúp tôi ra ngoài cho đến khi tôi nắm bắt được mọi thứ, làm thế nào tôi có thể yêu cầu sếp của tôi đưa ý kiến ​​vào mã của mình mà anh ấy đưa cho tôi, nhưng một cách lịch sự?

Nếu bạn không thể hiểu được mã, tại sao bạn nghĩ rằng các bình luận là giải pháp của bạn?

Tôi không biết phong cách lập trình của anh ta, nhưng tôi thừa nhận rằng nếu tên hàm và biến bị sai lệch, điều đó làm cho việc hiểu mã rất khó khăn. Nhưng nếu tên và hàm hoặc thậm chí là tổ chức của chương trình (các lớp, phương thức, thuộc tính ...) để làm cho mã dễ hiểu, thì mã thực sự sẽ tự nói chuyện với bạn.

Bạn nên hỏi anh ta về kiến ​​trúc chương trình và nếu bạn muốn yêu cầu anh ta một cái gì đó, hãy yêu cầu một số tên có ý nghĩa hơn cho các chức năng; đó là thuận tiện hơn cho anh ta để làm.


0

Ngay cả khi có một cách để hỏi điều này một cách lịch sự, có hai khả năng là sếp của bạn sẽ nghĩ gì về các bình luận trong mã của mình:

  1. Hoặc là những bình luận trong mã của anh ta sẽ là một điều tốt để có, hoặc

  2. Những bình luận trong mã của anh ta sẽ không phải là một điều tốt để có.

Nếu sếp của bạn nghĩ rằng các bình luận trong mã của anh ta sẽ không phải là một điều tốt, (và có những lập luận rất tốt cho điều này, tức là mã được coi là tài liệu , và sẽ không có tài liệu nào quy định một cách chính xác và rõ ràng như vậy như mã thực sự làm điều đó ,) thì sẽ không có gì xảy ra.

Bây giờ, nếu có bất kỳ cơ hội nào, sếp của bạn nghĩ rằng các nhận xét trong mã của anh ta sẽ là một điều tốt để có, thì có một cơ hội đáng kể rằng anh ta sẽ bảo bạn nghiên cứu mã của anh ta, hiểu cách thức hoạt động của nó và tiến hành thêm nhận xét vào mã mình . (Cũng có những lý lẽ rất tốt cho vấn đề này, tức là bạn cần phải học , và thời gian của anh ấy theo định nghĩa có giá trị hơn nhiều so với của bạn .)

Vì vậy, trừ khi bạn chuẩn bị phải làm điều này, bạn có thể tốt hơn không nên nói bất cứ điều gì.

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.