Làm thế nào để tôi (một cách khéo léo) nói với người quản lý dự án hoặc nhà phát triển chính của mình rằng cơ sở mã của dự án cần công việc nghiêm túc?


9

Tôi mới gia nhập một nhóm phát triển nhỏ (tương đối) đang làm việc trong một dự án trong vài tháng, nếu không nói là một năm. Như với hầu hết các nhà phát triển tham gia một dự án, tôi đã dành vài ngày đầu tiên để xem xét cơ sở mã của dự án.

Dự án (một dòng ứng dụng nội bộ ASP.NET WebForms cỡ vừa đến lớn), vì thiếu một thuật ngữ mô tả nhiều hơn, là một thảm họa. Có ba vấn đề đáng chú ý ngay lập tức với các tiêu chuẩn mã hóa:

  1. Các tiêu chuẩn là rất lỏng lẻo. Nó mô tả nhiều hơn những việc không nên làm (không sử dụng ký hiệu Hungary, v.v.) hơn là những việc cần làm.
  2. Tiêu chuẩn không phải lúc nào cũng tuân theo. Có sự không nhất quán với định dạng mã ở khắp mọi nơi .
  3. Tiêu chuẩn không tuân theo hướng dẫn về phong cách của Microsoft. Theo tôi, không có giá trị nào trong việc đi lệch khỏi các hướng dẫn được đặt ra bởi nhà phát triển của khung và người đóng góp lớn nhất cho đặc tả ngôn ngữ.

Đối với điểm 3, có lẽ điều đó làm phiền tôi nhiều hơn vì tôi đã dành thời gian để lấy MCPD của mình với trọng tâm là các ứng dụng web (cụ thể là ASP.NET). Tôi cũng là Microsoft Certified Professional duy nhất trong nhóm. Vì những gì tôi học được trong tất cả các lần đi học, tự học và học tại chỗ (bao gồm cả việc chuẩn bị cho kỳ thi chứng chỉ), tôi cũng đã phát hiện ra một số trường hợp trong mã của dự án, nơi mọi thứ đơn giản không được thực hiện trong cách tốt nhất.

Tôi mới chỉ ở trong nhóm này được một tuần, nhưng tôi thấy rất nhiều vấn đề với cơ sở mã của họ mà tôi tưởng tượng rằng tôi sẽ dành nhiều thời gian hơn để chiến đấu với những gì đã được viết để làm mọi thứ theo cách của họ nếu tôi làm làm việc trên một dự án, ví dụ, tuân theo các tiêu chuẩn mã hóa, các mẫu kiến ​​trúc và các thực tiễn tốt nhất được chấp nhận rộng rãi hơn. Điều này đưa tôi đến câu hỏi của tôi:

Tôi có nên (và nếu vậy, làm thế nào để tôi) đề xuất với người quản lý dự án và trưởng nhóm của mình rằng dự án cần phải được cải tạo lớn?

Tôi không muốn đi vào văn phòng của họ, vẫy các chứng chỉ MCTS và MCPD của tôi xung quanh, nói rằng cơ sở mã của dự án của họ là tào lao. Nhưng tôi cũng không muốn phải im lặng và phải viết mã bùn ở trên mã bùn của họ , vì tôi thực sự muốn viết phần mềm chất lượng và tôi muốn sản phẩm cuối ổn định và dễ bảo trì.


5
Bạn có bao nhiêu kinh nghiệm với ASP.NET? (bên cạnh chứng chỉ MCPD của bạn).
Marcie

11
Chào mừng bạn đến với bất kỳ sản phẩm thành công. Mã 'di sản' luôn tào lao.
Steven Evers


Tôi khá chắc chắn rằng tôi đã thấy một câu hỏi tương tự trên stackoverflow. Không có cách nào tôi nghĩ rằng một kỹ sư có thể di chuyển một núi mã khổng lồ bằng một cái xẻng nhỏ. Tôi đoán bạn có thể bắt đầu dạy tái cấu trúc đồng nghiệp của mình.
Reno

Tôi đã rời bỏ một công việc vì tìm thấy tình huống này và tôi thậm chí không phải là lập trình viên, tôi là quản trị viên hệ thống nhưng đã thấy đủ mã và các nguyên tắc mã hóa để biết nó sẽ KO công ty, (điều đó đã làm). Điều tốt nhất tôi có thể làm, đó là giúp họ bây giờ, giải thích rằng ba tuần dọn dẹp và viết lại mô-đun cốt lõi sẽ tiết kiệm hàng tháng trong quá trình phát triển trong tương lai - Phải mất một ứng dụng, trước khi họ bắt đầu xem xét, đến lúc CV của tôi có tìm thấy đường của nó trực tuyến! Giữ vững lập trường của bạn và chứng minh quan điểm của bạn nếu bạn có thể, sau đó để lại quyết định quản lý nó sẽ giúp cuộc sống của bạn dễ dàng hơn.
Mister IT Guru

Câu trả lời:


16

Bạn có thể dành thời gian để tranh luận về trường hợp của bạn; hoặc bạn có thể dành thời gian để dọn dẹp khi bạn đi cùng.

Chọn các Nguyên tắc, Mô hình và Thực tiễn Phát triển Phần mềm SạchMã nhanh và áp dụng những gì bạn học được khi bạn làm việc trên hệ thống. Cuối cùng, mọi người sẽ chú ý (cho tốt hơn, hoặc tồi tệ hơn).

Chỉnh sửa Cũng kiểm tra Làm việc hiệu quả với Mã kế thừa


miếng bánh pudding đang bị ăn dở. Nếu những gì bạn thấy thực sự cần phải sửa chữa, hãy sửa nó - và những người xung quanh bạn sẽ sớm nhận thấy.
quả việt quất

1
Chà, tôi đã có ý định sửa những thứ nhỏ nhặt khi tôi đi cùng. Nhưng, ví dụ ... cách nhóm thực hiện các cửa sổ bật lên trên biểu mẫu của họ là sai . Đó là thứ được thiết kế riêng và được sử dụng trong toàn bộ ứng dụng. Tôi không nghĩ rằng tôi có thể thoát khỏi việc viết lại mà không ai nhận ra, đặt câu hỏi hoặc hoàn nguyên các thay đổi của tôi.
Adam Maras

11
Tôi sử dụng một thuật ngữ gọi là "tái cấu trúc cơ hội". (Nó thực sự dư thừa vì tất cả tái cấu trúc là cơ hội). Tất cả chúng ta đã phải làm việc trên cơ sở mã mắt. Cố gắng thay đổi mọi thứ bằng lời nói chỉ đặt đội vào thế phòng thủ. Thay đổi bằng cách thực hiện (mã là tiền tệ của bạn) và khi ai đó hỏi tại sao, hãy giải thích lý do của bạn cho họ (nói cách tốt hơn là "cách cũ bị hút").
Michael Brown

2
Nếu nó sai, cũng thêm một trường hợp thử nghiệm vào bộ kiểm tra không thành công nếu chúng hoàn nguyên mã.
quả việt quất

5
BTW, cho đến khi bạn nghiêm túc chứng minh bản thân với mã của mình , bạn sẽ không bị coi trọng. Đừng là đứa trẻ kiêu ngạo lan can chống lại những người già. Tôi không nói nhận thức của bạn về mã không đúng, tôi nghiêm túc nói rằng vị trí xã hội của bạn ảnh hưởng đến thông điệp của bạn. Thành công với thành công.
Hack Saw

11

Từ những gì bạn mô tả, có vẻ như các vấn đề chủ yếu là về việc không tuân theo các tiêu chuẩn mã hóa và các vấn đề đặt tên. Đó không phải là một thảm họa , cho đến nay. Để so sánh, đây là một thảm họa, thực sự.

Có lẽ bạn đã quen và yêu cầu tiêu chuẩn cao? Trong trường hợp đó, bất kỳ sai lệch so với sự hoàn hảo có thể được coi là một thất bại. Đó là một cái bẫy rất dễ rơi vào khi nhu cầu của bạn cao, nhưng điều quan trọng là phải giữ quan điểm về mọi thứ.

Tôi đề nghị bạn nói về điều này như một sự cải tiến, và giúp nhóm cập nhật hướng dẫn của họ và huấn luyện họ bắt đầu sử dụng nó thực sự. Tôi thực sự muốn sử dụng Định nghĩa Hoàn thành làm điểm chuẩn chất lượng và tạo ra một nhóm là một đội trừ tà tuyệt vời. Nhưng tôi không nghĩ bạn nên làm nhiều hơn thế, ít nhất là không phải là thành viên nhóm mới.


9

Chắc chắn đừng đi vẫy MCSD của bạn xung quanh, mọi người sẽ chỉ cười vào bạn một cách khá thẳng thắn, MS certs rất tốt để có nhưng họ không phải là một trình độ chuyên môn!

Bước nhẹ tham gia một nhóm mới, tìm kiếm cơ hội để đề xuất thay đổi khi bạn đi.

Đợi cho đến khi bạn nhận được vị trí đất trước khi bỏ mã đội.


Lý do tôi đề cập đến chứng chỉ MCPD của mình là vì có sự nhấn mạnh vào các thực tiễn tốt nhất đã được chứng minh. Đôi khi, trong một khuôn khổ như ASP.NET, thực sự có một cách đúng và một cách sai để làm mọi thứ.
Adam Maras

Không có nghi ngờ có một cách đúng đắn! Nhưng một số anh chàng mới đến vẫy một chứng chỉ không phải là cách để đi về nó. Trích dẫn kinh nghiệm, nó đáng tin cậy hơn!
ozz

1
@ Adam: chỉ cần một ý nghĩ, nhưng rộng lớn đa số ví dụ tôi đã thấy - rất đặc biệt với ASP.Net và thậm chí nhiều hơn như vậy với MVC - show phẳng ra cách khủng khiếp để làm điều này, trong khi tuyên bố họ đang thực hành "tốt nhất". Một cái nhìn đơn giản về số lượng ví dụ sử dụng các lớp EF hoặc L2S trong ViewModels của họ là minh họa.
quentin-starin

8

Bạn có thể xem xét rằng vấn đề là bạn. Không có ba điều bạn đề cập là xứng đáng để làm lại hoàn toàn một ứng dụng. Họ chỉ là chi tiết nitpicky.

Hãy nhớ rằng mục tiêu của ứng dụng không phải là có mã đẹp, đó là giải quyết vấn đề kinh doanh. Chắc chắn rằng thật tuyệt khi có mã phù hợp và tuân theo một tiêu chuẩn tốt, nhưng việc thiếu nó không phải là lý do để làm hỏng toàn bộ cơ sở mã. Chỉ vì động cơ không có nghĩa là nó cần phải được xây dựng lại.

Hãy nhìn xem, mọi người đều ghét mọi codebase mà họ không viết. Trong thực tế, nếu bạn chờ đợi ba năm và nhìn vào mã của riêng bạn, bạn cũng sẽ ghét nó và nghĩ rằng nó cần viết lại hoàn chỉnh. Sự thật là không. Trừ khi bạn có thể làm cho trường hợp mất hàng tháng để làm cho mã có tính thẩm mỹ cho bạn thay vì xây dựng các tính năng để thêm giá trị kinh doanh, bạn có thể đang sủa sai cây.

Không có gì nói rằng bạn phải viết mã bùn chỉ vì có thể có một số trong cơ sở mã. Và không có gì nói mã IS kydgy chỉ vì nó không tuân thủ phong cách thú cưng của bạn. Chỉ cần cấu trúc lại khi bạn thực hiện các phần bạn làm việc và viết mã tốt khi bạn làm việc trên các công cụ mới.


Điều này! Rất nhiều điều này. Đó là một điều nếu nó tạo ra lỗi, nhưng nếu chỉ là BẠN đang cố gắng buộc các vấn đề khó chịu về OCD của bạn xuống cổ họng của người khác thì bằng mọi cách hãy rời khỏi đội của tôi!
Glstunna

6

Những điều này là ổn để lo lắng nhưng nếu bạn là người mới trong nhóm thì đừng khuấy thuyền, cho đến khi bạn tạo được sự tin cậy với họ.

Có vẻ như bạn đã chọn ba điều (tương đối) nhỏ để băn khoăn. Có những thứ khác tôi lo lắng hơn về:

  • Là mã tài liệu tốt?
  • Mã có tuân thủ thông số kỹ thuật / tài liệu thiết kế không?
  • Mã có hoạt động không?
  • Có dễ hiểu những gì mã làm?
  • Bạn đang xem xét việc gửi khối lượng lớn của cơ sở mã này đến TheD DailyWTF?

1
1) Số 2) Không thực sự. 3) Hầu hết thời gian? 4) Đôi khi. 5) CÓ.
Adam Maras

6

Bạn đã ở đó được một tuần? Tôi không chắc rằng bạn đã biết đủ để đưa ra bất kỳ đề xuất nào cho người quản lý dự án. Ngay cả khi bạn có nghi ngờ rằng quy tắc và thực hành của nhóm này là "xấu", cách tốt nhất để tác động đến những điều này theo thời gian là dần dần có được sự tin tưởng và tôn trọng của họ. Tham gia vào một dự án và sau một tuần nói với nhóm rằng mã của họ cần được viết lại không phải là một cách tốt để có được sự tin tưởng và tôn trọng.

Trong vài tháng đầu tiên của bạn, hãy tập trung vào việc nêu một ví dụ tốt hơn và đặt câu hỏi về lý do tại sao họ đã làm những việc nhất định. Hãy cẩn thận về giọng điệu của bạn khi bạn hỏi những câu hỏi này. Nếu bạn gặp một anh chàng mới "biết tất cả", sẽ không có ai lắng nghe ý kiến ​​của bạn sau này khi bạn thực sự ở vào vị trí ảnh hưởng đến cách mọi thứ được thực hiện.

Theo thời gian, nếu mã của bạn thực sự "tốt hơn", các nhà phát triển khác sẽ thấy điều đó. Họ sẽ bắt đầu đến với bạn như một nguồn tài nguyên để giúp họ sửa chữa chúng, và sau đó hỏi lời khuyên của bạn về cách họ nên làm việc. Vào thời điểm đó, bạn sẽ ở một vị trí tuyệt vời để nói với nhóm (và quản lý) ý kiến ​​của bạn về các tiêu chuẩn mã hóa và tương tự. Quá trình này mất bao lâu sẽ khác nhau tùy theo tổ chức. Nó có thể chỉ là một vài tuần trong một môi trường rất thích nghi, hoặc vài tháng đến nhiều năm trong một nền văn hóa khắc kỷ hơn. Xây dựng ảnh hưởng của bạn một người tại một thời điểm.


6

Bạn sẽ không bao giờ đi vào một công việc mới, nơi bạn sẽ nghĩ rằng cơ sở mã là hoàn hảo và mọi thứ đã được thực hiện theo cách "đúng". Học cách chấp nhận điều này. Tất cả những gì bạn có thể làm với mã kế thừa là tái cấu trúc và di chuyển về phía trước từng chút một. Một số điều bạn không muốn cấu trúc lại cho đến khi bạn hiểu thêm về lý do tại sao họ làm những gì họ đã làm. Ngoài ra, không ai trong doanh nghiệp sẽ trả tiền cho bạn để sửa mã làm việc, vì vậy bạn sẽ phải đưa ra một trường hợp kinh doanh tại sao nó cần làm việc trước khi bước lên và dành thời gian. YOu tốt hơn hết là chờ đợi để cấu trúc lại mã khi có một thay đổi bạn cần thực hiện với nó. Bạn có thể không chọn phương pháp họ đã làm cho một số thứ, nhưng nếu nó hoạt động, hãy rất cẩn thận về việc thay đổi nó và giới thiệu các lỗi mới. Đặc biệt là khi bạn chưa được yêu cầu thay đổi nó.

Sau một tuần, bạn không có uy tín để đưa ra đề xuất lớn về cách họ làm kinh doanh. Nếu bạn mang mọi thứ lên bây giờ, mọi người sẽ cười bạn và sẽ không bao giờ coi trọng bạn. Hãy chứng minh bản thân với một số mã tốt trước và sau đó mọi người sẽ có xu hướng lắng nghe nhiều hơn.

Và thẳng thắn không ai quan tâm rằng bạn là một Microsoft Certified Professional. Bất cứ ai có nhiều kinh nghiệm đều thấy nhiều lập trình viên tồi có chứng chỉ đó là người tốt. Tôi không nói rằng điều đó làm cho bạn trông tệ khi có chứng nhận, tôi nói rằng chúng ta không đặt nhiều niềm tin vào họ bởi vì chúng ta chưa thấy nơi họ hiệu quả đang cho chúng ta thấy ai là một lập trình viên giỏi.


5

Có lẽ tôi sẽ cố gắng tìm ra cách trình bày đề xuất với ý định rằng cuối cùng bạn không thể biện minh cho vị trí của mình một cách đầy đủ. Một vài câu hỏi để suy ngẫm trong việc tạo ra đề xuất đó:

  • Bao nhiêu giá trị kinh doanh đạt được bằng cách thực hiện các loại thay đổi bạn mô tả ở đây?
  • Bạn đã xem xét các tùy chọn như viết lại ứng dụng từ đầu, sửa đổi mã hiện có để làm cho nó trở nên hoàn hảo hơn, hoặc chỉ thực hiện một số thay đổi nhỏ theo thời gian?
  • Bạn có biết những tính năng và lỗi nào đang muốn bây giờ sẽ ngăn bạn thực hiện những thay đổi bạn muốn không?

Mặc dù tôi có thể đánh giá cao việc muốn sửa lỗi cơ sở mã kém, nhưng điều này phải được cân nhắc để nó có ý nghĩa từ quan điểm kinh doanh để làm điều đó.


1
Tin tôi đi, tôi rất muốn đề xuất viết lại. Tôi gần như muốn về nhà và bắt đầu một cơ sở mã mới trong ASP.NET MVC 3 chỉ để cho họ thấy nó tốt hơn bao nhiêu. Tôi chỉ không nghĩ rằng nó sẽ được đón nhận, vì tôi là người mới trong đội.
Adam Maras

3

Hiện tại bạn không ở vị trí để ngăn chặn mã xấu, vì vậy bạn sẽ phải tìm ra cách chứa mã đó.

Thủ tướng và các trưởng nhóm sẽ chỉ quan tâm nó không hoạt động. Mối quan tâm tiếp theo của họ sẽ là khi họ yêu cầu bạn thực hiện các thay đổi và tự hỏi tại sao mọi thứ 'đơn giản' lại mất nhiều thời gian như vậy. Đó là nơi bạn sẽ đến.

Bắt đầu ngay bây giờ với vấn đề nhất quán. Dù phương thức tiêu chuẩn tiềm năng hiện tại là gì, hãy thử xác định nó và xem liệu bạn có thể thực thi nó không. Nếu bạn bắt đầu với phương pháp mà không ai quen thuộc, bạn sẽ nhận được rất nhiều phản hồi.

Các thành viên khác trong nhóm có thể muốn được chứng nhận và bạn sẽ là một nguồn tài nguyên tuyệt vời. Hy vọng rằng ít nhất họ sẽ muốn cải thiện và tìm đến bạn để chỉ cho họ con đường.

Khiếu nại về Ký hiệu Hungary sẽ khiến bạn không có thiện cảm và có lẽ là một trong những trận chiến cuối cùng trong danh sách ưu tiên.


3

Tôi đồng ý rằng bạn cần thận trọng về điều này. Bạn cần xây dựng danh tiếng trong nhóm trước khi bạn có thể nêu ra những lời chỉ trích và đề xuất những thay đổi sâu sắc trong mã hoặc quy trình. Tôi sẽ chỉ ghi chép về những phát hiện và đề xuất của tôi trong thời gian này, và tận dụng cơ hội để làm quen với các thành viên trong nhóm và quản lý, tham gia các cuộc thảo luận miễn phí nhưng không từ chối nếu cuộc nói chuyện chuyển sang các vấn đề chất lượng, câu hỏi mã hóa, v.v. một số câu hỏi của riêng tôi vào ao (nhưng ở dạng tổng quát, không quá quan tâm đến bất kỳ vấn đề cụ thể nào tôi đã thấy trong cơ sở mã này). Bằng cách này, tôi có thể biết ý kiến ​​của các thành viên trong nhóm và tìm các đồng minh tiềm năng.

Trong trường hợp tốt nhất, bạn có thể thấy rằng một phần đáng kể của nhóm (và / hoặc quản lý) thấy các vấn đề tương tự như bạn, chỉ là không có sáng kiến ​​để làm gì về chúng hoặc không có tài nguyên nào được cấp bởi ban quản lý. Cùng nhau bạn có nhiều tiếng nói để thuyết phục quản lý nếu cần.

Như @Mike đề xuất, tự mình thực hiện một số công việc dọn dẹp là cần thiết, nhưng một lần nữa, tốt hơn hết là hãy kiên nhẫn với nó. Nếu bạn bắt đầu quá nhanh, bạn có thể xa lánh các thành viên khác trong nhóm, những người có thể coi đó là sự chỉ trích cá nhân. Ngoài ra, việc quản lý / tái cấu trúc mã mở rộng có thể được người quản lý của bạn xem là dấu hiệu cho thấy bạn không tập trung đủ vào nhiệm vụ thực tế. Vì vậy, bạn nên nhận được một số nhiệm vụ để tái cấu trúc trước khi bắt tay vào nó ở mức độ nghiêm trọng hơn. Thay đổi địa phương nhỏ có lẽ là OK mặc dù.

Ngoài ra, để thuyết phục quản lý, bạn cần lý do kinh doanh. Quản lý hiếm khi được di chuyển bởi các mô tả về phong cách mã hóa không nhất quán. Bạn cần cho họ thấy những giá trị mà những thay đổi được đề xuất có thể mang lại cho công ty - điểm mấu chốt là tiền mặt. Nếu bạn có thể đưa ra một tính toán có vẻ thuyết phục về chi phí và lợi ích dài hạn của các thay đổi được đề xuất khác nhau và cho thấy sự cân bằng tổng thể rõ ràng là về mặt tích cực, bạn đã cải thiện đáng kể cơ hội của mình.


3

Tự làm đi. Nếu bạn coi trọng các kiểu mã hóa nhất định, thì hãy làm việc với mã vi phạm các kiểu mã hóa . Kiểm tra một đoạn mã vi phạm từ kiểm soát nguồn, định dạng lại mã theo yêu cầu khoảng trắng của kiểu (ví dụ) và cam kết mã được cập nhật với thông báo "Tuân thủ quy tắc của hướng dẫn kiểu trên khoảng trắng."


+1: Phải - Yêu cầu sự tha thứ, không được phép.
Jim G.

1
Tốt nếu bạn làm theo hướng dẫn về phong cách và bạn không bị chậm trễ trong các nhiệm vụ được giao, thật tệ nếu bạn đang làm điều này trước khi thực hiện nhiệm vụ được giao hoặc thay đổi thành một phong cách mà tổ chức chưa ra lệnh.
HLGEM

3

Sau một tuần, điều tồi tệ nhất bạn có thể làm là trực tiếp đến quản lý với việc này. Rất có thể họ đã dành rất nhiều thời gian vào mã và có một chút tự hào về nó. Bạn có thể sẽ đi ra như một "biết tất cả."

Những gì tôi sẽ làm nếu tôi là bạn là để cải thiện nó khi bạn đi cùng. Khi bạn làm quen với nó và khi bạn làm việc với nó nhiều hơn, bạn sẽ có cơ hội để cải thiện nó. Tại thời điểm đó, tôi sẽ bắt đầu cho thấy những lợi ích của những gì bạn đang làm cho các đồng nghiệp khác. Sau đó, khi các cuộc họp thiết kế đưa ra các mô-đun mới, hãy đưa ra một lập luận cho những gì bạn cho là cách tốt nhất.

Và thành thật mà nói, các tiêu chuẩn tồn tại vì một lý do, nhưng, nếu nó hoạt động và hoạt động tốt có giá trị gấp 100 lần trong cuốn sách của tôi (đặc biệt là sau một tuần vào). Tôi sẽ quan tâm hơn nếu bạn mở mã và thấy hàng tấn lỗi logic hoặc một cái gì đó thuộc về bản chất đó.


+1 cho nghiêm khắc biết tất cả. Tôi theo dõi một anh chàng MS cũ trên twitter và anh ta đang làm điều tương tự chính xác trong một vai trò mới và tweet về nó, một sai lầm lớn!
ozz

2

Đừng trực tiếp đến quản lý với 'vấn đề' này.

Đầu tiên, hãy nói chuyện với đồng nghiệp của bạn và tìm hiểu từ họ tại sao mọi thứ lại diễn ra như vậy. Sau đó, bạn có thể đánh giá tốt hơn cho dù có vấn đề hay không. Bạn có thể ngạc nhiên về những gì bạn học. Bạn cũng có thể tìm thấy các đồng minh trong việc muốn nó được làm sạch.

Nếu bạn không biết làm thế nào bạn đến được nơi bạn ở ngay từ đầu, điều đó sẽ khiến việc ra ngoài trở nên khó khăn hơn nhiều.


1

Đã có rất nhiều gợi ý hay ở đây và tôi không phải là người đầu tiên cho đến khi bạn chứng minh chính mình như những người khác. Những gì tôi sẽ thêm là thảo luận tốt với các đồng đội của bạn trước khi xa lánh họ bằng cách đi đến người quản lý dự án hoặc trưởng nhóm trước. Và chắc chắn cho họ thấy trước đó, rằng bạn nên được thực hiện nghiêm túc.

Nghe có vẻ như đó là vấn đề phong cách mà bạn gặp phải với mã. Tiếp quản mã của người khác và giữ mũi của bạn trong khi làm quen với cách họ viết nó chỉ là một phần của công việc, ngay cả khi đó là một việc nhỏ như cách họ định dạng nó. Bàn giao một trong những 'em bé' của bạn cho người khác để họ xé nó bằng đôi bàn tay mũm mĩm của họ thậm chí còn tệ hơn ...

Nếu cuối cùng nó còn hơn thế - và vấn đề có nhiều chức năng hơn là chỉ theo phong cách - nếu bạn đi đến nhóm trưởng / chiều, tốt nhất là bạn cần phải làm lại theo cách nó sẽ tiết kiệm tiền và nỗ lực trong tương lai dự án phát triển. Tốt tái cấu trúc cũ.

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.