Làm thế nào là quan trọng để làm sạch mã của người khác khi phải đối mặt với một thời hạn chặt chẽ? [đóng cửa]


38

(Tôi đang nói về mã HTML / CSS (không phải ngôn ngữ lập trình) nhưng tôi nghĩ chúng ta cũng gặp phải vấn đề tương tự như với các lập trình viên.)

Tôi là nhà thiết kế mặt trước cao cấp trong một nhóm và tôi thường phải làm việc lại đầu ra của đàn em trong thời hạn chặt chẽ.

Tôi phải đối mặt với 2 vấn đề:

  1. Phong cách mã hóa của họ là một chút lộn xộn.
  2. Tính thẩm mỹ không tốt.

Phong cách mã hóa của họ, tôi thấy, là một túi hỗn hợp không có quy ước / tiêu chuẩn thích hợp. Tôi bị giằng xé giữa việc làm sạch mã hoặc chỉ xử lý mã của họ (thậm chí sao chép cách họ làm việc).

Tôi cảm thấy bực bội khi theo phong cách mã hóa của họ vì tôi cảm thấy mình có thể học được những thói quen xấu. Nhưng sau đó, đó là cách nhanh nhất để đáp ứng thời hạn.

Đối với những người có nhiều kinh nghiệm, cái nào hiệu quả hơn? Tôi có nên tiết kiệm dọn dẹp cho sau này? Hoặc dọn dẹp dọc đường khi tôi thực hiện các thay đổi?

(Tôi không muốn tỏ ra kiêu ngạo nhưng đó là thực tế. Họ sẽ mất nhiều năm hơn để viết mã tốt hơn. Tôi biết, tôi đã viết mã lộn xộn khi tôi bắt đầu.)


1
Nếu bạn có tùy chọn, hãy xem xét các sản phẩm JetBrains (Re-Sharper cho C #, IntelliJ cho Java và thậm chí một số ngôn ngữ 'động') có thể thực hiện các thay đổi thành ngữ trong toàn dự án, với rất ít thời gian đầu tư. (Nó cũng có thể được sử dụng để dạy tương tác cho đàn em những gì là bình thường. Nhưng hãy chắc chắn rằng bạn và họ đồng ý về cùng một cài đặt cho dự án. (Và hãy chắc chắn rằng bạn thực hiện tất cả những thứ đó trong một cam kết riêng biệt, vì vậy bạn không trộn lẫn thay đổi thực chất và mỹ phẩm trong cùng một cam kết),
David Bullock

1
có liên quan: lập trình
Doc Brown

2
Thực hiện một hướng dẫn phong cách / minimanual? Ý tôi là, họ sẽ không viết mã tốt hơn , nhưng mọi người đều có khả năng tuân theo các nguyên tắc yêu cầu viết những thứ tầm thường theo một cách riêng.
Peteris 17/03 '

10
Tôi đã thấy bạn có một vấn đề với việc thiếu tinh thần đồng đội ở đây. Bạn nên giáo dục và nuôi dưỡng đàn em; không chỉ viết lại mã của mình và phàn nàn về nó.
James

3
@Ramhound kể từ khi Turing nghĩ ra máy Turing tôi đoán. Nhưng trở lại vấn đề, nếu bạn là đàn anh nên để đàn em nghe bạn nói. Dạy chúng cách làm đúng (hoặc theo cách thèm muốn). Nhưng điều quan trọng là hỏi ý kiến ​​của họ và có thể họ có một số ý tưởng về cách làm công cụ theo cách tốt hơn. Ngoài ra nếu bạn đang sử dụng CSS thô cho bất kỳ dự án không tầm thường nào, bạn đang làm sai, hãy thử để dự án của bạn áp dụng LESS hoặc SASS.
Hoffmann

Câu trả lời:


79

Tôi tin rằng bạn đang nhìn vấn đề sai cách - bạn đang bỏ lỡ một cơ hội tuyệt vời để dạy cho đàn em cách viết mã tốt hơn.

Nếu bạn thường xuyên viết lại mã của họ, bạn có thể cho đàn em của bạn ấn tượng rằng bạn không coi trọng công việc của họ, điều này sẽ làm giảm tinh thần của họ và không giúp họ mã tốt hơn vào lần sau.

Tôi tin rằng một cách tiếp cận tốt hơn là thêm vào quy trình phát triển nhóm của bạn một nhiệm vụ xem xét mã. Nó không phải là về mọi đoạn mã đã cam kết, và nó không (tôi cho rằng không nên) chỉ được thực hiện bởi bạn - bất cứ khi nào một thành viên trong nhóm của bạn hoàn thành một nhiệm vụ đủ lớn, anh ta nên làm kết hợp với một (hoặc nhiều) đồng đội của mình, giải thích mã cho họ và nhận ý kiến ​​và phê bình mang tính xây dựng về thiết kế, kiểu mã hóa, lỗi có thể và các vấn đề bảo mật, v.v.

Khi đồng đội xem xét mã là bạn, họ sẽ học hỏi từ chuyên môn của bạn nhiều hơn sau đó khi bạn chỉ cần viết lại mã của họ (họ có cơ hội nghe lý do nên thay đổi mã) và có thể ít vi phạm hơn.

Cho họ cơ hội để tiến hành đánh giá mã sẽ tăng cường hơn nữa khả năng của họ - xem cách người khác viết mã và tại sao - và sẽ nâng cao lòng tự trọng của họ.

Họ cũng sẽ học được rất nhiều nếu bạn cho họ cơ hội xem lại mã của bạn . Bạn cũng có thể học được điều gì đó - vì vậy đừng làm điều đó chỉ để thể hiện!


Tôi 100% đồng ý với bạn, tuy nhiên tôi tự hỏi làm thế nào để áp dụng điều này khi có thời hạn chặt chẽ. Bạn có đề nghị thực hiện đánh giá mã ngay cả khi chúng có thể chiếm nhiều thời gian giới hạn quý giá của chúng tôi (trong cả quá trình xem xét và chỉnh sửa được thực hiện sau khi xem xét)?
Phil

3
Tôi không nghĩ rằng một thành viên trong nhóm nên thay đổi công việc của một thành viên khác trong nhóm mà không có sự đồng ý / đồng ý của anh ấy. Người viết mã phải chịu trách nhiệm về nó và trừ khi mã có lỗi nghiêm trọng người viết ban đầu không có sẵn, thì trong một lịch trình chặt chẽ không có lý do gì để thay đổi mã của người khác. Nếu bạn thấy mã quá lộn xộn - hãy liên lạc với nhà phát triển và bảo anh ta dọn sạch nó cho lần phát hành tiếp theo.
Uri Agassi

23
@Phil Khi tính thời hạn, thời gian cho các phiên xem xét mã nên được xem xét. Nó không phải là một bước bổ sung trên đầu của quá trình phát triển - nó là một phần không thể thiếu của quá trình phát triển.
dj18

2
Ngoài ra, đào tạo đàn em thông qua đánh giá mã có thể có một khoản chi phí thời gian nhất định (như dj18 nói nên được tính đến thời hạn và ước tính của bạn dù sao) nhưng nó sẽ được hoàn trả trong khóa học nhiều lần vì nó giải phóng bạn để làm công việc ban đầu hơn. Nếu thời hạn của bạn quá chặt chẽ đến nỗi bạn không bao giờ có cơ hội để làm điều này, thì nó có mùi thay vì vòng xoáy tử thần ...
Julia Hayward

2
@JustinPaulson đừng hiểu sai ý tôi - thực tế là ai đó đã viết một số mã, không biến mã này thành "của mình". Một tuần sau, một số thành viên khác trong nhóm sẽ nhận được một nhiệm vụ yêu cầu cô ấy sửa đổi mã đó và cô ấy chắc chắn nên thay đổi mã theo nhu cầu của mình. Tuy nhiên, tôi không thấy trường hợp sử dụng trong đó ai đó nên 'dọn dẹp' mã của người khác để dọn dẹp, đặc biệt không phải là điều cuối cùng trong thời hạn chặt chẽ.
Uri Agassi

29

Tôi đã nói điều này trước đây và sẽ nói lại "mã làm việc có giá trị hơn mã đẹp".

Nếu bạn thay đổi mã, khả năng cao là bạn sẽ thay đổi hành vi của nó, nếu đây là mã được kiểm tra thì bạn đã vô hiệu hóa tất cả các nỗ lực kiểm tra và sẽ cần phải lặp lại các thử nghiệm.

Bằng mọi cách khuyến khích đàn em của bạn viết mã dễ hiểu, nhưng nếu bạn sẽ viết lại tất cả những gì họ viết thì bạn đang lãng phí tiền của chủ nhân nhiều lần. Họ phải trả tiền cho đàn em của bạn, sau đó trả tiền cho bạn để làm những gì họ đã trả cho đàn em của bạn để làm, và sau đó trả tiền cho bạn một lần nữa để làm công việc họ thực sự thuê bạn.


11
"nếu đây là mã được kiểm tra thì bạn vừa vô hiệu hóa tất cả các nỗ lực kiểm tra và sẽ cần phải lặp lại các thử nghiệm." Không, bạn đã không làm mất hiệu lực bất kỳ nỗ lực thử nghiệm. Bạn sẽ chỉ phải chạy lại các bài kiểm tra mà bạn nên làm cho mỗi lần xác nhận. Nếu quá lâu đến nỗi nó được coi là không khả thi thì các bài kiểm tra là tào lao và nên được sửa.
l0b0

7
Cần lưu ý rằng việc liên tục viết mã cẩu thả để "làm cho nó hoạt động" sẽ dẫn đến một quả bóng lớn . Sẽ tốt thôi nếu đó là một ngoại lệ, và không phải là quy tắc. Nếu nó trở thành quy tắc, bạn nên nói chuyện với sếp rằng thời hạn không phải là điều duy nhất cần xem xét.
Neil

20
Vấn đề là mã xấu xí nhanh chóng bị phá hủy thành mã bị hỏng.
Telastyn 17/03/2016

1
@ramhound - chắc chắn, nhưng OP (và hầu hết mọi người khác) không nói về mã chỉ đơn giản là sử dụng các tiêu chuẩn cũ - họ đang nói về mã lúng túng, không nhất quán, kém chất lượng.
Telastyn 17/03/2016

1
@JamesAnderson Đây là một viễn cảnh cực kỳ thiển cận. Mã được viết một lần nhưng nó được duy trì trong suốt vòng đời của sản phẩm. Hầu hết mã hóa là tái cấu trúc. Bạn thực sự viết mã trên một màn hình trống trong bao lâu trước khi bạn chỉnh nó và xem nó có chạy như mong đợi không? Do đó, bạn đang tái cấu trúc, ngay cả trong giờ đầu tiên sau khi bắt đầu một lớp học mới. Chi phí tái cấu trúc mã xấu trong các lần sửa lỗi và cải tiến tiếp theo sẽ vượt xa chi phí một chút thời gian dành cho việc đánh giá mã và đưa nhóm tiến tới một tiêu chuẩn rõ ràng.
Scott Shipp

16
  • Câu trả lời ngắn gọn là không. Khi khó khăn, đôi khi bạn chỉ cần gục đầu xuống và lấy viên đạn thẩm mỹ. ;)

  • Một câu trả lời thực tế hơn là hộp thời gian. Ngân sách một giờ để chạy qua và dọn sạch một khía cạnh cụ thể của mã. Sau đó kiểm tra nó và làm một số công việc thực sự. Nhưng hãy thành thật với chính mình về việc giữ cho nó bị hạn chế.

  • Đôi khi, mặc dù, một chút dọn dẹp làm cho công việc đi nhanh hơn. Ngay cả một số thay đổi loại tìm kiếm và thay thế nhanh chóng cũng khiến mọi thứ dễ tiếp cận hơn rất nhiều.

  • Hãy cảnh giác với các cuộc chiến phong cách. Đặc biệt là trong một tình huống có thời hạn chặt chẽ, nếu bạn sẽ hoàn tác một số sở thích phong cách mà lập trình viên khác sẽ làm lại, thì bạn nên chờ đợi cho đến khi bạn có thời gian để thực sự tìm ra cách bạn muốn giải quyết những điều đó vấn đề phong cách hợp tác. (Có nghĩa là một số cho và nhận.)

Nhưng có một giá trị phán đoán trong câu trả lời. Tôi sẽ nói "vừa phải" quan trọng. Mã sạch thực sự có thể làm cho công việc diễn ra nhanh hơn và chất lượng mã là, một phần của khả năng phân phối. Tôi không nghĩ rằng tôi có thể chạm vào mã (thậm chí là của riêng tôi) mà không mất một chút thời gian để dọn dẹp. Nhưng chắc chắn rằng nhặng xị với phong cách và định dạng, và chiến tranh phong cách, không trở thành nhiều quan trọng hơn là nhận được mã để sản xuất.


9

Khi sửa mã và có thời hạn, tôi thường sử dụng hai quy tắc:

Mã này rất tệ nhưng có thể tìm ra sự cố trong thời gian hợp lý và khắc phục nó

Tôi sửa một vấn đề và giữ nguyên phần còn lại .

Mã này rất lộn xộn đến nỗi thật khó để tìm ra một vấn đề ở đó. Sửa một cái gì đó gây ra phá vỡ ngay lập tức một cái gì đó khác. Có lẽ sẽ nhanh hơn để viết mã đó từ đầu hơn là sửa nó.

Sau đó, tôi không có lựa chọn nào khác ngoài viết lại / tái cấu trúc cho đến khi mã sẽ đủ sạch để bản địa hóa và sửa lỗi.

Các ranh giới trường hợp là:

Mã này lộn xộn và thực sự xấu. Vẫn có thể sửa lỗi trong thời gian hợp lý, nhưng cấu trúc mã sẽ khiến việc bảo trì thực sự khó khăn. Bất kỳ tính năng mới nào cũng rất có thể giới thiệu các lỗi mới hoặc làm giảm hiệu suất đáng kể.

Trong trường hợp đó, mã sẽ được sửa, nhưng chỉ khi các tính năng mới được triển khai, trong thời gian nhàn rỗi, không bao giờ trong thời gian sửa lỗi khi đến hạn chót!


Vấn đề với "trường hợp đường biên" là các mô-đun khác có xu hướng mọc lên sử dụng mã đó. Sau đó, nó trở nên rất rủi ro khi thay đổi vì các mô-đun khác hiện có thể dựa vào hành vi "không chính xác / không mong muốn". Vì vậy, bạn cuối cùng bị mắc kẹt với mã thực sự khó bảo trì khiến bạn co rúm mỗi khi nhìn thấy nó và khiến bạn muốn đi nơi khác để tìm việc làm. Ở mức tối thiểu, mã xấu cần được loại bỏ bởi một người biết họ đang làm gì. Bằng cách đó, nó có thể được sửa chữa sau đó mà không gặp nhiều rủi ro như chỉ để lại cho đến khi ai đó có thời gian để tiếp cận nó.
Dunk

6

Tôi sẽ quan tâm để biết tại thời điểm nào trong quá trình bạn đang tìm thấy vấn đề này?

Nói đúng ra, trong thế giới lý tưởng kỳ diệu mà không ai trong chúng ta sinh sống, tất cả các mã được quảng bá hoặc triển khai đều phải hoàn hảo. Đôi khi bạn phải thực dụng.

Tuy nhiên, nếu bạn có một quy trình xem xét mã, thì nên làm nổi bật điều này trước khi thử nghiệm. Nếu bạn liên tục vượt quá thời hạn, các vấn đề ước tính cho việc phân phối có nghĩa là một thành phần quan trọng của bất kỳ quy trình phát triển nào - tức là - xem xét mã - đang bị bóp nghẹt?

Các hậu bối của bạn sẽ không bao giờ học cách ngồi lại và tiếp thu những cách làm việc tốt hơn nếu bạn không dành thời gian để biến nó thành một phần trong quá trình phát triển của họ để học. Nghe có vẻ như bạn không làm điều đó.


4

Phụ thuộc vào văn hóa tổng thể. Nếu thời hạn chặt chẽ là lẻ tẻ, chấp nhận bạn sẽ phải dọn dẹp sau. Nếu chúng là hằng số, hơn là bạn đang xây dựng nợ kỹ thuật và bạn nên xử lý vấn đề với quản lý. Nếu họ không giải quyết mối quan tâm của bạn, tốt hơn hãy bắt đầu tìm kiếm cơ hội việc làm khác vì văn hóa công ty rất có thể sẽ đáp ứng các nguyên tắc của người darwin sớm.


3

Để giúp hạn chế vấn đề trong tương lai, hãy phát triển tài liệu Tiêu chuẩn và Thực hành Mã hóa nội bộ mà tất cả nhân viên phải tuân theo.

Đối với lô hiện tại, hãy dọn sạch mã theo tài liệu S & P khi bạn cấu trúc lại mã nhưng chỉ khi bạn cấu trúc lại.


Tôi đã làm việc cho một số công ty lớn, rất có định hướng quy trình, sẵn sàng chi tiêu vô số tiền để đảm bảo các tiêu chuẩn và thông lệ mã hóa được đáp ứng. HỌ KHÔNG BAO GIỜ ĐƯỢC cho đến khi các công cụ tự động bắt đầu thực thi chúng.
Dunk

@Dunk Quân đội Hoa Kỳ có được coi là "định hướng lớn và theo quy trình" không? Họ sử dụng S & Ps mọi lúc: stroustrup.com/JSF-AV-rules.pdf
Casey

Họ chắc chắn được coi là tiêu chuẩn vàng cho các tiêu chuẩn và thực hành mã hóa. Mọi hợp đồng đều yêu cầu họ. Tuy nhiên, cũng như các công ty cố gắng tuân thủ các tiêu chuẩn và thông lệ của họ, điều đó không xảy ra một cách đáng tin cậy và nhất quán. Có quá nhiều thứ đang diễn ra. Đó là lý do tại sao các công cụ tự động là cần thiết nếu bạn muốn bao gồm từ "phải" trong đề xuất của mình, như bạn đã làm. Bộ Quốc phòng đã công nhận việc không tuân thủ các tiêu chuẩn thông qua các phương tiện thủ công và đó là lý do tại sao quốc hội đã thông qua luật năm 2011 yêu cầu các nhà thầu quốc phòng bắt đầu sử dụng các công cụ tự động để thực hiện các kiểm tra này.
Dunk

BTW, tôi không nói rằng không cần phải có các tiêu chuẩn và thực hành mã hóa. Hoàn toàn có nhu cầu. Tôi chỉ có một cuộc tranh cãi với phần "tất cả nhân viên phải tuân theo", trừ khi bạn cũng đề cập đến điều gì đó về việc thực thi điều này thông qua các công cụ tự động.
Dunk

@Dunk Nhóm JSF-AV phải nhận ra điều này, tài liệu đặc biệt đề cập đến việc sử dụng các công cụ tự động như một cách để thực thi S & Ps (trở lại năm 2005)
Casey

2

Tôi khá thiếu kinh nghiệm với lập trình. Tuy nhiên, là một sinh viên, tôi thường cam kết đánh giá ngang hàng và hợp tác trong các dự án. Nếu có nhiều thời gian để hoàn thành một dự án, tôi sẽ tiếp tục và làm sạch mã của một thành viên trong nhóm để rõ ràng và dễ đọc hơn. Thường xuyên hơn không, tôi sẽ gặp khó khăn trong việc sàng lọc 100 dòng đầu tiên hoặc lâu hơn. Trong những trường hợp này, tôi rất sẵn lòng giúp đỡ để dạy cho một lập trình viên thói quen và mã hóa tốt hơn. Nếu không có đủ thời gian, tôi chỉ cần sao chép / dán và thực hiện các dự án của mình vào bức tranh lớn xử lý các giao diện kém của chúng. Sau đó, tôi chắc chắn sẽ cung cấp nhiều lời khuyên về kỹ thuật mã hóa. Khi nói đến đánh giá ngang hàng, những lời chỉ trích mang tính xây dựng (bất kể không mong muốn như thế nào) chỉ mang lại lợi ích cho cả anh ấy / cô ấy và bản thân tôi về lâu dài.

Nhìn chung, nếu bạn có thời gian rảnh rỗi, hãy dùng nó để dạy cho những người mới của bạn cách tiến hành công việc của họ để mọi người đều có lợi. Dành một phút và dạy họ những gì đã làm cho bạn, và những gì không. Nếu bây giờ bạn không có thời gian, hãy sẵn sàng với công việc của họ và chắc chắn sẽ quay lại với họ khi bạn có cơ hội. Hãy cho họ biết rằng có nhiều cách làm việc tốt hơn, đặc biệt là nếu bạn sẽ làm việc với họ trong tương lai.


2

Cải thiện chất lượng tổng thể vượt trội hơn rất nhiều so với việc sử dụng một người làm "bộ lọc" cho một nhóm lớn hơn. Trên lưu ý rằng:

  • Lập trình cặp hoạt động giống như một phiên bản cải tiến của đánh giá mã để hiểu cách phát triển - nó giống như sự khác biệt giữa đọc và làm, nói và hiển thị. Xem mã phát triển và nhanh chóng thảo luận về các thay đổi là vô cùng hữu ích để hiểu không chỉ cách thức mà còn lý do tại sao tái cấu trúc và mã tốt. Theo kinh nghiệm của tôi, nó nhanh hơn phát triển một mình, vì các ý tưởng được đưa ra liên tục, kết thúc với kết quả chất lượng cao hơn và hiểu rõ hơn về cả mã và suy nghĩ của người khác.
  • Các công cụ linting có thể xác minh rằng phong cách mã hóa đang được tuân theo. Điều này dạy cho mọi người cách định dạng mã và các lỗi sẽ được loại bỏ nhanh chóng sau khi các nhà phát triển nhớ tiêu chuẩn.
    • Làm cho các phần này của quá trình xây dựng để đảm bảo rằng nó đã được sửa trước khi cam kết.
    • Sử dụng các mẫu ngôn ngữ để đảm bảo rằng mã CSS, HTML, JavaScript và mã phía máy chủ của bạn có thể được kiểm tra riêng.
  • Các công cụ xác nhận có thể kiểm tra xem đầu ra được tạo ra có lành mạnh không. Đây cũng nên là một phần của quá trình xây dựng.

2

Cách thực hành tốt nhất là có một hướng dẫn về phong cách mã hóa và có các đánh giá thường xuyên, để khi bạn đến gần thời hạn, bạn sẽ không gặp phải vấn đề này.

Đề nghị của tôi là để bạn thể hiện khả năng lãnh đạo và đi đầu trong việc xem xét mã thường xuyên. Quản lý không được đẩy lên hàng đầu để đảm bảo rằng các đánh giá mã thường xuyên xảy ra, nhưng kinh nghiệm của tôi là họ sẽ bị ấn tượng khi lập trình viên bước lên lịch và tổ chức đánh giá mã thường xuyên.

Có nhiều lợi ích cho người của bạn, những người sẽ:

  • học phong cách tốt hơn
  • làm theo các thực hành tốt hơn
  • học cách nghiên cứu những gì họ đang làm

Và một số lợi ích cho chính bạn, bạn sẽ là:

  • hiệu quả hơn trong các lần sửa lỗi vào phút cuối (sẽ luôn xảy ra)
  • được công nhận bởi cả chuyên gia và nhà lãnh đạo bởi cả nhóm và quản lý của bạn

1
Vấn đề với hướng dẫn phong cách mã hóa là chúng có xu hướng biến thành sách. Hầu hết mọi người sẵn sàng học hỏi và tuân theo một bộ quy tắc khá khiêm tốn. Thật không may, tại một số điểm, các hướng dẫn này luôn phát triển vượt quá khả năng học hỏi và ghi nhớ tất cả các quy tắc của mọi người. Bạn cần một công cụ sẽ tự động kiểm tra kiểu, định kỳ. Đánh giá mã không nên để thực hiện kiểm tra ngữ pháp, chúng nên được tìm thấy lỗi và hiểu lầm.
Dunk

Là một lập trình viên Python và là người lãnh đạo đánh giá mã, tôi đã in ra PEP 8 và hướng dẫn về Phong cách Python của Google ít nhất một chục lần để được thông qua. Bất cứ điều gì lập trình viên sẽ không học hỏi từ họ sẽ thấy mình bị tụt lại phía sau những người làm. Điều đó nói rằng, tôi đồng ý rằng một trình kiểm tra phong cách cũng là một thực hành tốt nếu bạn có thể thực hiện nó.
Aaron Hall

Tôi không sử dụng Python, vì vậy tôi không biết các công cụ có sẵn, nhưng nếu bạn đang dựa vào đánh giá mã để thực thi các quy tắc phong cách của mình thì bạn đang lãng phí hàng trăm (nếu không phải hàng ngàn) mỗi năm cho một thứ gì đó mà bạn có thể được thực hiện cho bạn về cơ bản không có chi phí thời gian. Tôi chắc chắn sẽ không đi trước và thực hiện một phiên bản trồng tại nhà. Tôi sẽ chi tiền để mua một phiên bản thương mại sẽ CÁCH tốt hơn bất cứ thứ gì có thể được xây dựng trong thời gian rảnh. Ngay cả các công cụ đắt tiền sẽ tự trả tiền nhiều lần.
Dunk

Python, là một giác mạc mã nguồn mở, có tất cả các loại công cụ miễn phí (pylint, pep8, pyflakes), một số trong đó chúng tôi đã kết hợp và cải tiến, vì chúng tôi có hàng ngàn nhà phát triển, thực sự mở rộng quy mô.
Aaron Hall

1
: Tôi đã đề cập đến đoạn trích "nếu bạn có thể thực hiện nó". Nếu bạn có thể mua một trình kiểm tra phong cách thì đó là cách để đi. Nếu bạn có thể yêu cầu nhóm của bạn thực hiện một cái gì đó hữu ích như thế này trong một thời gian hợp lý thì phải có một công ty / nguồn mở đã thực hiện nó. Vì vậy, nó sẽ có hiệu quả chi phí hơn nhiều chỉ đơn giản là mua nó. Tôi chắc chắn rằng nó sẽ tốt hơn và cập nhật hơn so với phiên bản trồng tại nhà "không sản xuất". Nếu bạn có hàng ngàn nhà phát triển thì tôi đã đánh giá rất thấp số tiền tiết kiệm mà một công cụ kiểm tra bảo mật / kiểu tự động sẽ cung cấp.
Dunk

2

Tôi có thể thấy lý do trong câu trả lời "không sửa những gì đang hoạt động" và "đừng lãng phí thời gian của bạn vào những câu không quan trọng đối với khách hàng". Thủ tướng lo lắng về rủi ro và điều này là tốt.

Ngoài ra tôi hiểu rằng hầu hết mọi người không dùng loại sửa chữa này tốt. Tôi cũng hiểu điều này

Nói rằng, tôi tin rằng hầu hết thời hạn là nhân tạo. Các hệ thống thực sự sống hơn bao giờ hết thời hạn và thiết kế tồi tệ bạn làm hôm nay sẽ chống lại bạn mãi mãi. Mọi người chạy để cung cấp một cái gì đó trong một vài tháng và dành nhiều năm sau khi sửa chữa một số quyết định tồi tệ trong một mã đang được chạy trong sản xuất.

Nợ công nghệ là từ. Nó sẽ trở lại vào một ngày nào đó và ai đó sẽ trả tiền cho nó.

Vì vậy, IMO, tôi nghĩ rằng bạn đã sửa chữa thiết kế bị hỏng một cách đúng đắn và chuyên nghiệp (đặc biệt đối với đàn em) cũng có nghĩa là bạn phải biết cách phê bình và học hỏi từ nó, ngay cả khi nó không lịch sự. Trong thực tế, hầu hết cuộc sống là không lịch sự.


0

Bất kỳ câu trả lời thẳng sẽ là cực đoan. Rõ ràng có những trường hợp thời hạn quá chặt chẽ đến nỗi bạn phải sử dụng mã xấu, và có những trường hợp mã quá xấu đến nỗi đáng để bỏ lỡ thời hạn để cải thiện nó. Những gì bạn cần là các phương pháp để đánh giá xem bạn đang ở đâu và có lẽ các phương thức để đặt thời hạn thực tế cho phép thời gian viết mã tốt hơn.

Đừng lưu dọn dẹp sau này. Trừ khi bạn thường xuyên có những khoảng thời gian không có gì để làm ngoài việc tái cấu trúc, không có "sau này", bằng cách nào đó nó sẽ trở thành ưu tiên cao hơn để dọn dẹp mã so với hiện tại. Thói quen là "đỏ, xanh, tái cấu trúc", không phải "đỏ, xanh, làm một cái gì đó hoàn toàn khác trong hai tuần, tái cấu trúc". Thực tế, bạn sẽ không thay đổi mã cho đến lần tiếp theo bạn xem lại nó vì một số lý do khác và có lẽ bạn cũng sẽ đến hạn chót. Lựa chọn thực sự của bạn là sửa nó ngay bây giờ hoặc để nó.

Tất nhiên mã được tạo kiểu tốt sẽ tốt hơn mã có kiểu dáng xấu, giả sử bạn có kế hoạch đọc lại nó. Nếu bạn có kế hoạch không bao giờ đọc nó một lần nữa, thì đừng dọn dẹp nó . Vận chuyển điều đầu tiên vượt qua các bài kiểm tra. Nhưng đó là một kịch bản khá hiếm, đối với hầu hết các lập trình viên, điều đó xảy ra gần như không bao giờ. Bỏ qua trường hợp đó, chỉ có bạn có các chi tiết về trường hợp thực tế của bạn để đưa ra phán quyết chi phí sửa chữa là bao nhiêu so với chi phí bao nhiêu (trong bảo trì tăng trong tương lai) để không khắc phục.

Có một số điều không khó khắc phục tại thời điểm mã yêu cầu bảo trì, hơn là sửa lỗi ngay bây giờ. Chúng không thực sự mang lại lợi ích cho bạn nhiều để khắc phục ngay bây giờ. Rõ ràng nhất là sửa chữa tầm thường (lỗi khoảng trắng và tương tự) và vì vậy thật khó để tưởng tượng rằng bạn có thời gian để hỏi câu hỏi này nhưng không sửa chúng ;-) Đối với những câu hỏi không tầm thường và thuộc loại này thì OK , bạn có một số mã không lý tưởng nhưng bạn phải thực dụng. Nó hoạt động và bạn đang trên một thời hạn. Sử dụng nó.

Có một số điều dễ dàng hơn đáng kể để khắc phục ngay bây giờ so với sau này khi (a) chúng không còn mới mẻ trong tâm trí của mọi người; (b) những điều khác đã được viết dựa trên chúng hoặc bắt chước chúng. Đây là những giá trị hơn nhiều để sửa chữa bây giờ, vì vậy hãy ưu tiên chúng. Nếu bạn không có thời gian trong thời hạn để khắc phục những điều này, thì bạn cần phải cố gắng hết sức có thể trong thời hạn dài hơn, bởi vì bạn đang xây dựng nợ trong cơ sở mã của mình mà bạn có thể phải trả lần sau khi bạn truy cập mật mã.

Phương pháp sửa mã ưa thích là thông qua quy trình xem xét. Nhận xét về các vấn đề bạn gặp phải với nó, và gửi lại cho đàn em để thay đổi . Bạn có thể đưa ra ví dụ về ý nghĩa của bạn và rời khỏi đàn em để tìm tất cả các trường hợp trong mã mà họ áp dụng, nhưng đừng chỉ hoàn thành mã của họ cho họ. Nếu bạn làm thì bạn cho họ không có cách nào để cải thiện.

Bạn nên viết các vấn đề phổ biến lên thành một hướng dẫn phong cách có nội dung "không làm điều này, thay vào đó hãy làm điều này" và giải thích lý do tại sao. Cuối cùng, lý do được cho phép là "để làm cho mã của chúng tôi phù hợp về mặt thẩm mỹ", nhưng nếu bạn không chuẩn bị để viết ra các quy tắc của mình với một số biện minh thì có lẽ bạn cũng không nên thực thi chúng. Chỉ cần để mỗi lập trình viên tự do lựa chọn.

Cuối cùng, hãy cẩn thận với xu hướng điều chỉnh công cụ vô thời hạn. Lợi nhuận giảm dần và bạn cần học hỏi kinh nghiệm khi chúng vẫn còn tốt. Điều thực sự cần thiết là bạn hình thành một ý tưởng thực tế về những gì đủ tốt, nếu không bạn không thể có cuộc đàm phán mà bạn đảm bảo rằng thời hạn của bạn cho bạn thời gian để tạo mã "đủ tốt". Dành thời gian của bạn cho những thứ không đủ tốt.


0

Như rất nhiều người đã nói trước đây, bất cứ điều gì bạn ném lên không trung sẽ luôn quay trở lại. Tôi tin vào sự đồng nhất mạnh mẽ trên một cơ sở mã. Tất nhiên một số điều thực sự không quan trọng lắm. Các quy ước đặt tên cho các biến cục bộ trong một thủ tục chẳng hạn. Tuy nhiên, đối với bất kỳ cấu trúc nào, nó cần được sửa ngay lập tức, trước khi hợp nhất cuối cùng vào thân cây chính. Nó chỉ có thể hơi kém chất lượng khi bạn nhìn vào thủ tục hoặc lớp riêng lẻ, nhưng nếu mọi người đều thực hiện mã "hơi xấu", nó thực sự nhanh chóng trở nên thực sự xấu xí.

Mã xấu hoạt động thường hoạt động tốt 90% thời gian nhưng rơi ra ở các cạnh. Hãy chắc chắn rằng nó không đủ đơn giản bằng cách chỉ tuân theo một vài quy tắc đơn giản. Đầu tiên, nó là bắt buộc đối với mọi lập trình viên để xác định và ghi lại các ràng buộc chính xác cho mọi thủ tục hoặc khối chức năng mà họ tạo ra.

Thứ hai, đối với mọi thủ tục cần có một bài kiểm tra chống lại những ràng buộc đó. Đây phải là một bài kiểm tra đơn vị đơn giản mà lập trình viên có thể (và phải) chạy cục bộ theo quy trình của mình trước khi cam kết. Rõ ràng điều này dễ quản lý hơn với một bộ kiểm thử thích hợp, nhưng ngay cả khi không có kiểm tra nên được viết và có thể được cam kết trong một lớp một phần có thể được loại trừ khỏi bản dựng.

Thứ ba, một môi trường phát triển được chuẩn hóa với các công cụ được cấu hình sẵn là vô giá. Một máy chủ TS là tuyệt vời cho việc này. Mọi người đều có cùng các công cụ chính xác (và phiên bản), cùng cấu hình và các bản cập nhật giống nhau. Cài đặt công cụ tái cấu trúc như CodeRush hoặc Resharper, được cấu hình sẵn theo tiêu chuẩn của bạn và hướng dẫn cho các lập trình viên rằng bạn sẽ từ chối mọi cam kết vẫn còn cảnh báo. Giờ đây, bạn có thể sử dụng thời gian xem xét mã nhóm của mình để thực sự cải thiện quy tắc được đặt từ phản hồi của họ và nhóm của bạn vui vẻ tự sửa mà không cần phải liên tục dọn dẹp sau đó. Một lập trình viên cũng dễ dàng hơn nhiều trong việc phê bình mã từ một công cụ được cấu hình đúng so với từ đồng nghiệp hoặc sếp, nơi các tiêu chuẩn có thể được định nghĩa tùy ý hoặc không được hiểu đúng. Nếu IDE nói với bạn rằng mã của bạn kém chất lượng, không ai sẽ tranh luận với nó và nó sẽ được sửa chữa. Bạn sẽ thấy rằng chất lượng mã sẽ tăng lên đáng kể và toàn bộ nhóm sẽ dành ít thời gian hơn để tái cấu trúc và dọn dẹp sau một vài tuần. Các lập trình viên cũng sẽ quen với các quy tắc và ngừng viết mã tào lao.

Cuối cùng, cách khắc phục đơn giản ở đây chỉ đơn giản là cung cấp cho các lập trình viên một động lực để cải thiện. Lập trình viên theo định nghĩa cạnh tranh. Mọi người đều muốn có mã đẹp nhất hoặc nhanh nhất. Một cách tốt để thúc đẩy tất cả mọi người, cải thiện năng suất và tìm ra người bất tài là tính toán bảng điểm có trọng số hàng tuần cho mọi người, lấy điểm cho các cam kết bị từ chối và thời hạn bị phá vỡ chẳng hạn. Hiển thị N hàng đầu tại cuộc họp nhóm hàng tuần, thậm chí có thể trả bữa trưa cho bất cứ ai là người đầu tiên trong số trung bình của tháng.


0

Tôi đề nghị sử dụng một công cụ đánh giá. Nếu bạn có kho lưu trữ dựa trên Git, bạn có thể sử dụng công cụ đánh giá Gerrit . Sau một vài cam kết bị từ chối, nhóm sẽ tìm hiểu các tiêu chuẩn bạn muốn tuân theo và các cam kết trong tương lai sẽ không yêu cầu bất kỳ công việc bổ sung nào từ bạn.

Cam kết sẽ chờ sự chấp nhận của bạn. Nếu bạn thấy bất kỳ dòng nào cần được viết lại, bạn có thể viết bình luận và đồng đội của bạn có thể tự sửa mã dựa trên yêu cầu của bạn. Đó thực sự là một cách tốt để tìm hiểu các tiêu chuẩn mã hóa của các thành viên trong nhóm .

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.