Phải làm gì nếu đồng nghiệp đang chỉnh sửa mã của bạn chỉ để thay đổi giao diện?

Bạn nên làm gì, nếu một đồng nghiệp đang chỉnh sửa mã của bạn?

Không có mục đích thêm chức năng hoặc sửa lỗi, chỉ để thay đổi giao diện ...

Nói chuyện với họ về nó. Đi vào cuộc trò chuyện với thái độ "Họ không làm điều này để làm phiền tôi hoặc vì họ có một số dạng rối loạn ám ảnh cưỡng chế; họ đang cố gắng làm cho mã của tôi tốt hơn."

Bởi vì bạn có thể sai. Đó có thể là một sửa lỗi tinh vi và bạn không phát hiện ra nó.

Hoặc, có thể là có một tiêu chuẩn mã hóa mà bạn không biết về việc bạn vi phạm và họ chỉ sửa nó.

Hoặc, có thể là họ đang cố làm phiền bạn hoặc họ có một dạng rối loạn ám ảnh cưỡng chế nào đó. Nếu đó là trường hợp, yêu cầu họ dừng lại một cách tử tế, và nếu điều đó không hiệu quả, hãy đưa nó lên với sếp của bạn.

Nhưng bạn sẽ không bao giờ biết trừ khi bạn hỏi.

Tôi không kết hôn với cách mã của tôi tìm kiếm nó làm phiền tôi. :) Tôi cố gắng học hỏi từ những thay đổi. Có phải đồng nghiệp của tôi đã điều chỉnh tên biến? Viết một vòng lặp hiệu quả hơn? Làm cho mã dễ đọc hơn?

Nếu tôi không thể thấy những thay đổi đã cải thiện những gì đã có, tôi thường hỏi đồng nghiệp, người đã thực hiện những thay đổi đó là động lực đằng sau chúng. Có thể đó là lợi thế không rõ ràng đối với tôi. Và nếu tôi đúng và họ sai, thì có lẽ tôi có thể giải thích tại sao tôi viết nó theo cách tôi đã làm.

Nếu vẫn thất bại, hoàn nguyên việc đăng ký. ;)

Chỉnh sửa: Tất cả các cược đã tắt nếu mong muốn thay đổi mỹ phẩm giới thiệu một lỗi, mặc dù.

IMO bạn và nhóm của bạn nên sử dụng một tiêu chuẩn mã hóa. Nếu đây là trường hợp, thì các câu hỏi trở thành 'mã gốc của bạn có phù hợp với tiêu chuẩn không?' Nếu 'có' thì đồng nghiệp của bạn không nên chạm vào mã của bạn trừ khi thay đổi chức năng. Nếu 'không' thì tôi sợ đồng nghiệp của bạn có quyền dọn dẹp mã của bạn. Là một người dẫn dắt dự án, tôi thấy mình làm việc đó mọi lúc.

Nếu bạn không sử dụng một tiêu chuẩn mã hóa thì toàn bộ lập luận về những gì cấu thành 'mã tốt' trở nên quá chủ quan. Do đó tại sao bạn nên sử dụng một tiêu chuẩn mã hóa :)

Là một trong những người đó (những người thỉnh thoảng định dạng lại mã của người khác), lý do chính khiến tôi làm điều đó là khả năng đọc. Một số người cực kỳ cẩu thả với sự thụt lề của họ hoặc với các tab và không gian trộn.

Điều chính tôi có thói quen thay đổi là giảm các dòng dài để tôi có thể đọc toàn bộ mà không cần cuộn ngang. Tôi sẽ chia các câu lệnh phức tạp thành các câu lệnh riêng biệt hoặc định dạng lại các cuộc gọi / khai báo phương thức để liệt kê một tham số trên mỗi dòng nếu nó không phù hợp thoải mái trên một dòng. Tôi cũng sẽ chỉnh sửa các bình luận, để sửa lỗi tiếng Anh hoặc chỉ để làm cho mọi thứ rõ ràng hơn.

Vâng, tôi có thể để nó một mình, nhưng tôi muốn giảm bớt nỗ lực tinh thần cần thiết để đọc mã.

Bạn nên làm gì về nó? Đầu tiên, hãy xem xét rằng có thể người này đang làm cho mã của bạn tốt hơn. Ngoài ra, bạn nên đảm bảo rằng bạn có một số sự đồng thuận trong nhóm của mình về cách mã được định dạng. Nếu mỗi người có những thói quen khác nhau, nó sẽ làm mọi người chậm lại. Nếu họ không làm cho mã của bạn tốt hơn và họ đang đi ngược lại ngũ cốc, thì bạn cần phải đối đầu với họ về nó. Nếu điều đó không hiệu quả thì bạn có thể cần phải lôi kéo người khác tham gia.

Hỏi họ tại sao họ đang làm điều đó; một lời giải thích hợp lệ có thể làm giảm sự thất vọng của bạn, nhưng bạn nên cho họ biết nó làm phiền bạn đến mức nào. Ai biết được, có thể họ nghĩ rằng họ đang làm cho bạn một việc và sẽ dừng lại khi họ học điều đó xúc phạm bạn. Hoặc bạn có thể đang đối phó với một người thực sự đang bị một tình trạng y tế.

Anh ấy có được phép không? Các thay đổi có cải thiện mã không? Nếu vậy, hãy nuốt niềm tự hào của bạn. Nếu bạn cảm thấy chất lượng mã bị xấu đi, hãy liên hệ với đồng nghiệp và hỏi họ tại sao họ cảm thấy cần phải thay đổi mã của bạn mà không có lợi ích rõ ràng. Nếu việc đó được thực hiện một cách bất chấp hoặc bởi vì người đó cảm thấy nhầm họ tốt hơn bạn và bạn không thể làm việc đó với họ, hãy đưa nó lên với sếp của bạn.

IDE giống như Visual Studio có một tùy chọn được gọi là Format Documentđịnh dạng mã theo các quy tắc mà người dùng đã đặt trong IDE. Đó có thể là đồng nghiệp của bạn đang sử dụng điều này (có thể tự động mà không biết hoặc do ứng dụng có chủ ý). Có lẽ IDE của họ sử dụng khoảng trắng thay vì tab hoặc ngược lại và những thứ này đang được áp dụng tự động mà không hề biết? Nhưng bạn cần nói chuyện với họ để tìm hiểu.

Ngẫu nhiên, tôi sẽ thường định dạng lại mã của đồng nghiệp nếu nó rõ ràng không tuân theo một loại sơ đồ định dạng nào (nghĩa là nó ở khắp mọi nơi). Đó là một cách hy vọng tinh tế để làm cho họ chú ý. (Tuy nhiên, tôi sẽ không định dạng lại nếu nó gọn gàng, nhưng không theo ý thích của tôi).

Nếu anh ấy thay đổi nó để đáp ứng các tiêu chuẩn mã hóa của nhóm của bạn, bạn nên tuân theo các tiêu chuẩn vào lần tới.

Nếu anh ta thay đổi nó sao cho nó không còn tuân theo các tiêu chuẩn mã hóa của nhóm bạn, hãy thông báo cho anh ta biết anh ta đã làm gì sai và yêu cầu anh ta thay đổi lại.

... Nhóm của bạn có một bộ tiêu chuẩn định dạng mã được mọi người sử dụng, phải không?

Thỉnh thoảng tôi sắp xếp lại mã được viết bởi các đồng nghiệp lộn xộn (hoặc sửa lỗi chính tả trong các bình luận). Họ biết rằng tôi bị ám ảnh trong định dạng và trật tự mã và do đó họ để tôi làm điều đó mà không phàn nàn quá nhiều. Đôi khi họ cũng cho tôi một soda hoặc cookie miễn phí.

Tất nhiên điều này là thỉnh thoảng công việc , vì nó đã phá vỡ chức năng "đổ lỗi" trong SVN.

Đây cũng là một cách rất cơ bản để thực hiện một số loại đánh giá mã (tôi thường đọc hầu hết các mã được đồng nghiệp cam kết trong các mô-đun tôi đang làm việc).

Mã công ước là các câu trả lời. Bạn nên có một trong công việc. Nếu bạn không, hãy bắt đầu ngay bây giờ (một điểm khởi đầu tốt là hướng dẫn phong cách google ). Khi có các quy tắc bằng văn bản (hoặc ít nhất được biết đến), câu trả lời cho câu hỏi của bạn là không đáng kể.

Tôi cảm thấy bạn đang nghĩ rằng thật xúc phạm khi làm như vậy ...? Ví dụ, bản thân tôi sẽ ngay lập tức sửa mã này

int myFunction( ) {

    int i ;
  return  0;

}

để trở thành

int myFunction() {
    int i;
    return 0;
}

vậy ... tôi có nên bị trừng phạt vì hành động của mình không? Trong cuộc sống thực, tôi thực sự có hàng tấn nhật ký SVN đọc 'Định dạng'. ;-)

Sử dụng một công cụ kiểm tra phong cách

Bắt đầu sử dụng StyleCop hoặc tương tự và thực thi các quy tắc kiểu mã và cũng khiến nó trở thành nghĩa vụ đối với tất cả các nhà phát triển sử dụng nó. Tất cả các mã sẽ trông giống nhau mà không có ngoại lệ. Và kết hợp với những người khôn ngoan để thảo luận về các quy tắc phù hợp nhất cho tổ chức của bạn. Mặc dù các quy tắc mặc định rất giống với mã khung .net.

Đó là cách dễ nhất để làm điều đó. Tôi thấy mình đã sửa mã của người khác tại một trong những người chủ trước đây của mình bởi vì anh chàng kia đang viết mã với số lượng dòng trống quá mức và không có quy tắc thụt đầu dòng nào. Mã thực sự không thể đọc được bởi một nhà phát triển trung bình. Nếu StyleCop tồn tại trở lại thì nó sẽ khiến nhiều người trong chúng ta thực sự hạnh phúc.

đây là một suy nghĩ tôi thấy trên internet nói về tái cấu trúc và có thể giải thích tại sao ai đó sẽ chạm vào mã của bạn để làm cho nó tốt hơn:

Tại sao?

Có hai lý do chính để tái cấu trúc:

1. Để cải thiện mã / thiết kế trước khi xây dựng trên đỉnh của nó: Thật sự rất khó để đưa ra mã tốt trong lần thử đầu tiên. Lần thử đầu tiên để thực hiện bất kỳ thiết kế ban đầu nào sẽ cho chúng ta thấy rằng chúng ta hiểu sai hoặc quên một số logic.

2. Để thích ứng với những thay đổi trong các yêu cầu. Thay đổi xảy ra trong quá trình phát triển phần mềm; đáp ứng để thay đổi là tốt hơn để có một cơ sở mã tốt. Chúng tôi có hai tùy chọn cho cả hai kịch bản, đường dẫn mã hoặc cấu trúc lại nó. Việc vá mã sẽ dẫn chúng ta đến mã không thể nhầm lẫn, và sẽ làm tăng nợ kỹ thuật của chúng ta, tốt hơn là nên tái cấu trúc.

Khi nào?

1. Càng sớm càng tốt càng dễ dàng.

2. nhanh hơn và ít rủi ro hơn để tái cấu trúc mã gần đây được tái cấu trúc thay vì chờ tái cấu trúc để mã gần hoàn thành.

Gì?

1. Tất cả các mã và tất cả các thiết kế là ứng cử viên để tái cấu trúc.

2. Một ngoại lệ cho việc không tái cấu trúc một cái gì đó có thể là một đoạn mã hoạt động có chất lượng thấp, nhưng do gần đến hạn chót, chúng tôi thích giữ nợ kỹ thuật hơn là mạo hiểm với việc lập kế hoạch.

Bạn chỉ cần để anh ấy làm hết sức mình, nếu nó sẽ tuyệt vời cho cả hai và tiết kiệm thời gian của bạn trong tương lai!

chúc mừng