Làm thế nào để bạn mã mà không xúc phạm?

Điều tôi muốn nói là, làm thế nào để bạn phát triển dựa trên cơ sở mã mà bạn chia sẻ với các nhà phát triển đã làm việc trên nó trong nhiều năm và rất quen thuộc với nó?

Tôi không muốn giẫm lên ngón chân của bất kỳ ai, nhưng tôi không nhận được những lời phàn nàn quá tinh vi về cách tôi làm, cho dù đó là cách tôi làm trắng mã của mình hay tần suất tôi đăng ký SVN (quá thường xuyên). Vì vậy, trong khi tôi có thể thay đổi những điều đó một cách dễ dàng - nói chung tôi muốn trở thành một nhà phát triển nhóm tốt hơn.

Tôi không chắc phải làm gì, ngoài việc hỏi, nhưng có lẽ các bạn có một vài suy nghĩ tôi có thể thực hành.

CẬP NHẬT

Không có bất kỳ hướng dẫn về phong cách nào để nói về - chỉ là mọi người không quen chia sẻ cơ sở mã. Mọi người đều có thế giới mã nhỏ bé của riêng mình.

Đây là một cửa hàng perl, nhưng tôi chắc chắn những điều này áp dụng cho bất kỳ ngôn ngữ nào

CẬP NHẬT 2

CTO, người sau này trở thành CEO là một megalomaniac hoàn chỉnh và là nguồn chính của những khiếu nại này. Nếu bạn không làm mọi thứ chính xác như anh ấy thích, cho dù đó là sử dụng máy Mac, hay Emacs, hoặc 4 không gian tab thay vì 2, hoặc ăn mặc theo một cách nhất định, bạn sẽ kém hơn. Đó là một tình huống khủng khiếp mà tôi đã cố gắng sửa chữa, nhưng câu trả lời đúng duy nhất cho tôi là rời đi.

Tôi tin rằng đây là một trường hợp bắt nạt tại nơi làm việc, và sau đó, tôi nhận thức rõ hơn về những gì có thể là bắt nạt tinh vi và hành vi không phù hợp trong môi trường làm việc.

Để bất kỳ nhà phát triển tìm kiếm câu trả lời cho một tình huống như thế này, hãy rời khỏi ngay lập tức. Bạn không thể làm việc theo cách của bạn thoát khỏi tình huống nhóm xấu.

Hỏi. Đó là, hỏi những người bạn làm việc cùng. Làm hết sức mình để tuân theo phong cách đã thiết lập của mã hiện có. Hỏi đặc biệt là nếu có một danh sách tài liệu về các tiêu chuẩn mã hóa, và làm theo nó. Nếu không có, hãy viết một bản nháp đầu tiên dựa trên những gì bạn quan sát được trong mã và sau đó yêu cầu các thành viên khác trong nhóm phê bình nó. Bạn sẽ làm cho công ty (và các nhà phát triển mới đến sau bạn) một dịch vụ bằng cách bắt đầu ghi lại các thực tiễn mã hóa được chấp nhận. Rủi ro duy nhất có thể là bị kẹt ở giữa nếu hóa ra những người cũ không đồng ý với nhau về những gì được hoặc không thể chấp nhận được.

Ngoài ra, đừng sợ là chính mình . Bạn có thể là người mới, nhưng bạn là thành viên của nhóm và ý kiến ​​của bạn là hợp lệ. Nếu bạn có thể nghĩ ra những cách tốt hơn để làm một cái gì đó, hãy đề xuất nó. Tôn trọng các thành viên khác trong nhóm và cách làm việc đã được thiết lập, nhưng đừng để họ đẩy bạn ra xung quanh. Công ty sẽ không thuê bạn nếu nó không coi trọng đầu vào của bạn.

Nó sẽ giúp ích rất nhiều nếu bạn có thể tìm thấy ai đó trong đội có vẻ thân thiện và đặc biệt sẵn sàng trả lời các câu hỏi. (Nếu đó là một đội tốt, đó phải là tất cả mọi người, nhưng các đội không phải lúc nào cũng như vậy.) Sếp của bạn có thể đã chỉ định ai đó giúp bạn bắt đầu. Sử dụng người đó như một nguồn tài nguyên. Viết ra những câu hỏi khi chúng xảy ra với bạn, và sau đó yêu cầu người hữu ích đó trả lời chúng theo thời gian.

Đối với việc kiểm tra mã "quá thường xuyên", tại sao không tạo chi nhánh của riêng bạn cho các cam kết định kỳ của bạn và sau đó hợp nhất trở lại trung kế khi mã của bạn đã sẵn sàng? Không có hại cho ai khác khi làm điều đó và khi đồng nghiệp của bạn thấy bạn nhận được lợi ích từ SVN mà họ muốn, họ có thể đi theo sự dẫn dắt của bạn.

Về khoảng trắng: Chỉ cần làm điều đó tuy nhiên mã đã làm điều đó. Đi với dòng chảy.

Về séc SVN: Tài liệu rất rõ ràng. Điều đó giúp mọi người hiểu những gì đang diễn ra trong mã. (Theo dõi: Sự phản đối của họ đối với việc đăng ký thường xuyên là gì?)

Nói chung: Bắt đầu xây dựng một tài liệu tiêu chuẩn mã hóa. Đừng cố điền vào 100 quy tắc. Chỉ cần thêm các quy tắc khi họ đi lên.

Ngoài ra: Đặt câu hỏi của các nhà phát triển đồng bào của bạn. Điều đó cho họ cơ hội cân nhắc trước khi bạn làm điều gì đó họ sẽ không thích. Thêm vào đó, nó xây dựng các mối quan hệ. Thêm vào đó, bạn tìm hiểu thêm về cách các cửa hàng hoạt động.

Theo kiểu định dạng mã (khoảng trắng, tab, nơi niềng răng, v.v.), bạn nên tuân theo tiêu chuẩn phổ biến trong mã. Nếu không có ai, tôi không nghĩ họ có nhiều điều để phàn nàn. Khi nói đến nó, cho dù bạn có niềng răng trên dòng riêng của họ hay không, đặt khoảng trắng xung quanh danh sách tham số phương thức, v.v. là sở thích cá nhân và bạn nên nhường theo kiểu thịnh hành vì về lâu dài, nó thực sự không quan trọng . Điều quan trọng là sự nhất quán.

Khi nói đến việc kiểm tra mã vào SVN, tôi sẽ cố gắng truyền giáo những gì tôi cảm thấy là cách làm đúng đắn, thay vì để bản thân bị cuốn theo. Tôi không kiểm tra mã của mình trừ khi nó xây dựng và vượt qua các bài kiểm tra và nếu tôi thực hiện một số thay đổi không liên quan, tôi sẽ chia công việc của mình thành một số cam kết. Nếu một cái gì đó sẽ bị phá vỡ trong một thời gian, tôi tạo một chi nhánh và làm công việc của tôi ở đó. Cam kết nhận được mô tả ý kiến. Điều này hoạt động tốt hơn theo kinh nghiệm của tôi so với phương pháp "kiểm tra một đống thay đổi vào thứ Sáu lúc 5:00" và dường như đó là "cách thực hành tốt nhất" theo hầu hết những gì tôi đã đọc ở đây và ở nơi khác.

Trước tiên hãy đọc tài liệu quy ước mã hóa của họ (nếu họ không có thì hãy yêu cầu họ viết một tài liệu để bạn có thể làm theo)

Sau đó chú ý và thực hiện một nỗ lực có ý thức để làm theo điều đó và những gì họ nói. Có vẻ như với bạn rằng chúng rất khắc nghiệt nhưng các tiêu chuẩn mã hóa rất quan trọng, tốt hơn hết là chỉ ra những gì sai thay vì để nó phát triển thành vấn đề sau này khi bạn đang thực hiện những thay đổi lớn hơn.

Tôi chắc chắn rằng bạn sẽ làm điều tương tự trong một năm hoặc hai lần khi một số người mới đang bước trên ngón chân của bạn :)

Yêu cầu các tiêu chuẩn mã công ty. Chú ý hơn đến chi tiết. Nếu bạn thấy những người khác làm theo một hình thức không gian và nẹp trắng rất cụ thể, thì hãy làm theo họ. Là một Sr. bạn có thể lập luận rằng điều này rất kén chọn, nhưng với tư cách là một người mới hoặc một người mới trong một dự án bạn cần chứng minh rằng bạn có thể làm theo trước khi bạn có thể lãnh đạo.

Ngoài ra, hãy hiểu rằng bất kỳ nhà phát triển mới nào trong một dự án thực sự sẽ có một thời gian "tăng tốc" cần thiết . Vì vậy, đừng lo lắng về điều đó.

Điều tốt nhất bạn có thể làm là làm theo lời khuyên họ đưa ra cho bạn. Không có cách nào để nói trước những gì họ muốn. Trừ khi bạn là người tâm lý.

Tuy nhiên, tôi sẽ đề nghị rằng khi mọi người cho bạn lời khuyên, bạn hãy ghi lại. Bạn có wiki không? Nếu vậy, sử dụng nó. Nếu không, một tệp văn bản được kiểm tra bằng mã nguồn có thể là một ý tưởng tốt. Xây dựng một hướng dẫn lập trình được tổ chức tốt. Nó sẽ giúp bạn nhớ cách thực hiện và nếu ai đó mâu thuẫn với lời khuyên trước đó bạn đã đưa ra, nó cung cấp cho bạn một điểm tham chiếu để thảo luận về sự không nhất quán. Thêm vào đó, khi người tiếp theo gia nhập đội, họ sẽ không phải trải qua những gì bạn đang trải qua.

Tôi sẽ đề nghị bạn không gán lời khuyên trong tài liệu cho các cá nhân (vì vậy "các khối mã phải được thụt vào bởi ba khoảng trắng", chứ không phải "Bill nói với tôi rằng các khối mã nên được thụt vào bởi ba khoảng trắng"). Tuy nhiên, nếu bạn có thể ghi lại thông tin đó theo cách không phô trương (ví dụ: trong nhận xét cam kết, hãy viết "quy tắc bổ sung về thụt lề dựa trên lời khuyên của Bill"), thì có thể hữu ích trong việc giải quyết mâu thuẫn, bởi vì bạn có thể nhận được ngay hai quan điểm trên một cái gì đó. Điều tôi đang nghĩ ở đây, thực sự, là nếu bạn đưa ra lời khuyên mâu thuẫn, bạn cần tránh trở thành một quả bóng đá bị đá bởi hai đồng nghiệp, những người không đồng ý với nhau. Đó là một chút của một cách tiếp cận cover-ass-ass của bạn, nhưng nó có thể là thận trọng.

Một cách dễ dàng là tìm hướng dẫn phong cách và làm theo nó. Hầu hết không có bất cứ điều gì quá xúc phạm ở họ và sẽ ngăn bạn xúc phạm người khác.