Tiêu chuẩn mã hóa Python so với năng suất


18

Tôi làm việc cho một tổ chức nhân đạo lớn, trên một phần mềm xây dựng dự án có thể giúp cứu sống những trường hợp khẩn cấp bằng cách tăng tốc độ phân phối thực phẩm. Nhiều tổ chức phi chính phủ rất cần phần mềm của chúng tôi và chúng tôi chậm tiến độ vài tuần.

Một điều khiến tôi lo lắng trong dự án này là điều tôi nghĩ là sự tập trung quá mức vào các tiêu chuẩn mã hóa. Chúng tôi viết bằng python / django và sử dụng phiên bản PEP0008, với nhiều sửa đổi khác nhau, ví dụ: độ dài dòng có thể lên tới 160 ký tự và tất cả các dòng sẽ dài đến mức có thể, không có dòng trống nào giữa các lần nhập, quy tắc gói dòng chỉ áp dụng cho một số loại nhất định của các lớp, rất nhiều mẫu mà chúng ta phải sử dụng, ngay cả khi chúng không phải là cách tốt nhất để giải quyết vấn đề, v.v.

Một nhà phát triển cốt lõi đã dành một tuần để viết lại một phần chính của hệ thống để đáp ứng các tiêu chuẩn mã hóa mới sau đó, loại bỏ một số bộ thử nghiệm trong quy trình, vì việc viết lại có nghĩa là chúng "không hợp lệ". Chúng tôi đã dành hai tuần để viết lại tất cả các chức năng đã bị mất và sửa lỗi. Anh ấy là người dẫn đầu và lời nói của anh ấy có trọng lượng, vì vậy anh ấy đã thuyết phục người quản lý dự án rằng những tiêu chuẩn này là cần thiết. Các dev nhỏ làm như họ được nói. Tôi cảm thấy rằng người quản lý dự án có một cảm giác mạnh mẽ về sự bất đồng về nhận thức về tất cả những điều này nhưng vẫn đồng ý với nó một cách kịch liệt khi anh ta cảm thấy không biết phải làm gì khác.

Hôm nay tôi gặp rắc rối nghiêm trọng vì tôi đã quên đặt một số khoảng trắng sau dấu phẩy trong một đối số từ khóa. Tôi đã bị hai nhà phát triển khác và người quản lý dự án hét lên theo nghĩa đen trong một cuộc gọi Skype. Cá nhân tôi nghĩ rằng các tiêu chuẩn mã hóa là quan trọng nhưng cũng nghĩ rằng chúng ta đang lãng phí rất nhiều thời gian để ám ảnh với chúng, và khi tôi kiểm chứng bằng lời này, nó đã gây ra cơn thịnh nộ. Tôi được xem như một kẻ gây rối trong đội, một đội đang tìm kiếm vật tế thần cho những thất bại của nó. Kể từ khi giới thiệu các tiêu chuẩn mã hóa, năng suất của nhóm đã giảm mạnh, tuy nhiên điều này chỉ củng cố nỗi ám ảnh, tức là nhà phát triển chính chỉ đơn giản đổ lỗi cho việc chúng tôi không tuân thủ các tiêu chuẩn vì thiếu tiến bộ. Anh ấy tin rằng chúng tôi không thể đọc mã của nhau nếu chúng tôi không tuân thủ các quy ước.

Điều này đang bắt đầu để dính. Bây giờ tôi đang cố gắng sửa đổi các tập lệnh khác nhau, autopep8, pep8ify và PythonTidy để cố gắng khớp với các quy ước. Chúng tôi cũng chạy pep8 chống lại mã nguồn nhưng có rất nhiều sửa đổi ngầm đối với tiêu chuẩn của chúng tôi đến nỗi khó có thể theo dõi tất cả. Người dẫn đầu đơn giản chọn những lỗi mà tập lệnh pep8 không nhận và hét vào chúng tôi trong cuộc họp độc lập tiếp theo. Mỗi tuần có những bổ sung mới cho các tiêu chuẩn mã hóa buộc chúng ta phải viết lại mã đã được thử nghiệm, đang hoạt động. Cảm ơn trời, chúng tôi vẫn có các bài kiểm tra, (tôi đã hoàn nguyên một số cam kết và sửa một loạt các lỗi mà anh ấy đã xóa).

Tất cả trong khi có áp lực ngày càng tăng để đáp ứng thời hạn.

Tôi tin rằng một vấn đề cơ bản là nhà phát triển chính và nhà phát triển cốt lõi khác từ chối tin tưởng các nhà phát triển khác để thực hiện công việc của họ. Nhưng làm thế nào để đối phó với điều đó? Chúng tôi không thể làm công việc của mình vì chúng tôi quá bận rộn để viết lại mọi thứ.

Tôi chưa bao giờ gặp phải động lực này trong một nhóm kỹ thuật phần mềm. Tôi có sai khi đặt câu hỏi về việc tuân thủ các tiêu chuẩn mã hóa của họ không? Có ai khác đã trải qua một tình huống tương tự và làm thế nào họ đã giải quyết nó thành công? (Tôi không tìm kiếm một cuộc thảo luận chỉ là giải pháp thực tế mà mọi người đã tìm thấy)


4
Hãy nhớ rằng các tiêu chuẩn mã hóa được dự định để tăng năng suất dài hạn. Điều này có chi phí năng suất ngắn hạn nếu dự án hiện tại không tuân theo bất kỳ tiêu chuẩn nào trong một thời gian dài.
Arseni Mourzenko

1
Chỉ cần lập trình Eclipse và PyDev để tự động định dạng mã của bạn theo các tiêu chuẩn mã hóa. Đó là vấn đề điền vào một vài hộp thoại.
dùng16764

1
@D bohBrecht - Các tiêu chuẩn mã hóa hợp tác được xác định và đồng ý bởi tất cả các lập trình viên một điều tốt và có thể cải thiện năng suất dài hạn. Tiêu chuẩn mã hóa độc đoán, áp đặt từ bên trên mà không mua vào từ đội ngũ là một sự lãng phí rất lớn thời gian và có thể làm hỏng một dự án để đình trệ hoặc thậm chí hồi quy, như được minh chứng bởi cái gọi là nhà phát triển chính đã bỏ qua các bài kiểm tra vì mã được xác nhận lại tiêu chuẩn mới đã thất bại trong các thử nghiệm. Trung thực WTF?
Đánh dấu gian hàng

1
@MarkBooth: Bạn không thể làm hài lòng tất cả mọi người. Tôi đồng ý rằng nếu chỉ đơn giản là áp đặt từ phía trên thì việc mua từ các thành viên khác sẽ khó khăn hơn, nhưng nó vẫn không phải là một "sự lãng phí thời gian lớn". Khi có các tiêu chuẩn tại chỗ, mã phải nhất quán hơn nhiều và do đó bạn sẽ gặp ít sự đa dạng hơn về mã trong toàn dự án, điều này làm tăng khả năng đọc. Nhưng vâng .. Vứt bỏ các bài kiểm tra do các tiêu chuẩn sẽ khiến tôi tin rằng có những vấn đề lớn hơn dưới mui xe.
Demian Brecht

1
@Dppy Brecht: Tôi chắc chắn rằng điểm cơ bản trong câu hỏi này không phải là tiêu chuẩn mã hóa như vậy, nhưng thực tế là các vấn đề thẩm mỹ với mã được ưu tiên cao hơn, về cơ bản hơn bất kỳ điều gì khác trong một dự án bị trễ và có tầm quan trọng cao .
Buhb

Câu trả lời:


27

Các tiêu chuẩn mã hóa không phải là vấn đề. Vấn đề là quản lý không thể tìm ra vấn đề là gì. Điều này dẫn đến "Làm gì đó mà bất cứ điều gì!" chế độ. Bạn đang tìm kiếm một giải pháp hợp lý, nhưng đó là một vấn đề phi lý. Điều tốt nhất bạn có thể làm là:

  • Đưa ra những lời chỉ trích mang tính xây dựng về ý tưởng của họ, nhưng một khi quyết định được đưa ra, đừng liên tục than vãn về nó.
  • Làm bất cứ điều gì bạn có thể để làm cho việc viết lại dễ dàng hơn.
  • Đừng căng thẳng nữa. Hạn chót bỏ lỡ là vấn đề của quản lý, không phải của bạn. Cố gắng hết sức, nhưng đừng nhận trách nhiệm cho những quyết định tồi tệ của họ.
  • Nếu bạn biết điều gì đó có thể giúp đỡ, hãy nói với họ. Việc bạn đề cập đến các phần nổi bật có vẻ như bạn đang cố gắng thực hiện nhanh nhẹn, nhưng phần còn lại không có vẻ rất nhanh. Xem nếu bạn có thể cung cấp chức năng hạn chế sớm hơn thay vì cố gắng đáp ứng một thời hạn lớn với mọi thứ. Tạo các câu chuyện của người dùng để viết lại để rõ ràng họ đang tác động đến việc tồn đọng như thế nào.
  • Bắt đầu tìm kiếm một công việc khác. Nghiêm túc. Các công ty ở một tiểu bang như vậy không còn xa mới bắt đầu sa thải người dân.
  • Nhận một số áo phông "nói với bạn như vậy" được in lên :-)

Điểm tốt. Trên thực tế, tôi không chống lại các tiêu chuẩn mã hóa, ví dụ, sự bổ sung mới cho các tiêu chuẩn trong cuộc họp trước là để bắt buộc các tài liệu về mọi lớp và chức năng, điều này có ý nghĩa với tôi, và dù sao tôi cũng làm điều đó. Tiền là cách quá tốt để tìm kiếm một công việc khác. Tôi đã thử các trình cải cách mã, mặc dù tôi đã gợi ý cho nhóm phát triển chính cấm sử dụng. Tôi làm việc từ xa và quy tắc này không thể được thi hành, vì vậy tôi thấy pep8ify là thứ được sử dụng vì nó làm cho mã chỉ vượt qua tiêu chuẩn, vì vậy nó trông giống như các chỉnh sửa của con người. Tức là nó không sửa đổi tối thiểu.
Shneummeister

1
Tôi sẽ thêm rằng thời hạn sẽ bị bỏ lỡ, gần như chắc chắn. Đây là một cuộc tuần hành chết chóc và ai đó sẽ cố gắng đổ lỗi cho bạn. Chỉ cần chắc chắn rằng bạn ghi lại tất cả mọi thứ: theo dõi thời gian bạn dành cho mỗi nhiệm vụ, lưu trữ tất cả thư và / hoặc nhật ký trò chuyện để bạn có thể tự bảo vệ mình.
coredump

7

Ai đó cần phải quyết định xem việc vận chuyển hay tuân thủ các tiêu chuẩn mã hóa là ưu tiên thực sự. Tôi biết sở thích của tôi sẽ là gì; Nếu nó vượt qua các bài kiểm tra đơn vị và chấp nhận, tôi nói tàu. Sau khi xuất xưởng, công ty có thể quyết định có dành thời gian và tiền bạc để khắc phục nợ kỹ thuật hay không.

Các vấn đề với khoảng trắng sau dấu phẩy được giải quyết dễ dàng bằng công cụ chỉnh sửa mã. Tìm một công cụ thực thi tất cả các quy ước mã hóa của bạn và chạy công cụ đó trên tất cả các mã được sửa đổi trước khi quá trình xây dựng và thử nghiệm diễn ra. IDE Decent đã làm điều này, trong khi bạn đang viết mã.


Tôi đã tìm thấy pep8ify hữu ích cho việc định dạng lại này. Nó dường như thực hiện sửa đổi tối thiểu để đáp ứng các tiêu chuẩn và mã rất dễ sửa đổi, mặc dù cấu hình dòng lệnh có phần hạn chế.
Shneummeister

4

Tôi có sai khi đặt câu hỏi về việc tuân thủ các tiêu chuẩn mã hóa của họ không?

Nó phụ thuộc vào nhóm. Cá nhân , tôi nghĩ rằng mọi thứ nên được đặt câu hỏi. Một số người coi câu hỏi đó là một mối quan hệ; rằng tôi không tin tưởng họ.

Có ai khác đã trải qua một tình huống tương tự và làm thế nào họ đã giải quyết nó thành công?

Tôi hỏi làm thế nào những tiêu chuẩn này cải thiện năng suất. Tôi đã đo thời gian tôi dành cho việc vặn vẹo với các tiêu chuẩn so với "hoàn thành công việc". Cuối cùng, quyền hạn được quyết định gắn bó với các tiêu chuẩn. Nó xảy ra. Tôi phàn nàn về họ to hơn bình thường khi họ là nguyên nhân khiến tôi không hoàn thành công việc, nhưng nếu không thì tập trung vào việc hoàn thành công việc của tôi. Chiến đấu về những thứ liên tục không tốt cho năng suất ...

Nếu, như bạn nói, mọi thứ tồi tệ hơn do các tiêu chuẩn, thì việc tuân thủ các tiêu chuẩn sẽ làm mất hiệu lực đối số của khách hàng tiềm năng và để lại cho bạn. Nếu mọi người không thể thấy rằng (phần lớn) mối tương quan khách quan giữa việc thực hiện tiêu chuẩn và giảm năng suất, thì bạn sẽ không thể làm gì nhiều hơn nữa. Học cách đối phó với nó, và nếu bạn không thể, hãy tìm một nơi nào đó ít quan liêu hơn.


3

Các tiêu chuẩn là một cái gì đó không nên được đưa vào dự án muộn với thời hạn sắp tới. Đó là một cái gì đó nên được đưa vào vị trí sớm trong dự án hoặc khi có thời gian để dành thời gian trong lịch trình dự án (tốt nhất là gửi tàu ban đầu) cho (có khả năng) tái cấu trúc mã vi phạm lớn.

Nếu điều này thực tế được đưa vào cuối dự án, thì đó là một sai lầm do khách hàng tiềm năng của bạn (IMHO).

Tuy nhiên , điều này không có nghĩa là nếu bạn không đồng ý với sự dẫn dắt của mình, bạn chỉ nên tiến lên phía trước với cuộc binh biến. Đây là bạn công việc . Bạn làm việc như một đội . Bạn có một khách hàng tiềm năng . Chắc chắn phải có một số mức độ dân chủ trong đội, nhưng cuối cùng, người dẫn đầu là nhà độc tài. Nếu anh ấy nói để làm một cái gì đó, bạn làm điều đó.

Cuối cùng, khi tuân thủ các yêu cầu và tiêu chuẩn của anh ấy, bạn không cung cấp cho anh ấy / cô ấy một vật tế thần dễ dàng cho những thời hạn bị bỏ lỡ.

Ngoài ra, tôi là một người ủng hộ rất lớn cho các tiêu chuẩn mã hóa (đặc biệt là khi quy mô của một nhóm phát triển), nhưng chúng nên được thực hiện khi nó có ý nghĩa.


1

Câu hỏi của bạn là "Tôi có sai khi đặt câu hỏi về việc tuân thủ các tiêu chuẩn mã hóa của họ không?". http://c0x.coding-guferences.com/Int sinhtion.pdf (đối với ngôn ngữ lập trình C) có một số nghiên cứu tham khảo về giá trị của các hướng dẫn mã hóa. Xem phần 9 bắt đầu từ trang 39.

Các tiêu chuẩn mã hóa được thực hiện vì một lý do. Một điều dường như còn thiếu từ câu hỏi ban đầu là một sự hiểu biết về lý do cho các tiêu chuẩn cụ thể này về dự án cụ thể (hoặc trong tổ chức cụ thể). Quyết định thực hiện chúng trên mã hiện có được dựa trên một số logic. Không biết logic, thật khó để nhận xét về 'lòng tốt' của quyết định đó.

Tôi sẽ thứ hai những gì ai đó nói rằng các tiêu chuẩn được thực hiện cho 'năng suất dài hạn' - các vấn đề như khả năng duy trì của mã. Có thể một số sự kiện đã xảy ra khiến dự án trở lại nghiêm trọng vì nhầm lẫn và giải thích sai.

Có vẻ như có rất nhiều cảm xúc ở cả hai phía - hãy cố gắng để có được cuộc thảo luận hợp lý.


1

Như bạn có thể thấy bởi các câu trả lời và nhận xét khác, dự án của bạn có vấn đề lớn, vì vậy những gì tôi sẽ đề xuất không có cơ hội thành công lớn, nhưng đó là điều bạn có thể thử mà không gặp rủi ro quá lớn liên quan đến làn da của chính bạn.

Yêu cầu một cuộc họp giữa bốn mắt với nhà phát triển chính của bạn. Nói rằng bạn quan tâm đến việc tìm hiểu kỹ lưỡng những lợi ích của việc nghiêm ngặt với tiêu chuẩn mã hóa và tại sao codebase lại có hình dạng xấu như vậy trước khi giới thiệu chúng. Điều rất quan trọng là bạn giữ một thái độ rất cởi mở và "Tôi đang cố gắng học hỏi" trong cuộc thảo luận này. Nhà phát triển chính của bạn có lẽ đã căng thẳng hơn bạn hoặc bất kỳ ai khác trong nhóm của bạn, và có lẽ sẽ rất phòng thủ ngay khi anh ta ngửi thấy một số bệnh viêm phổi.

Cố gắng thúc đẩy cuộc thảo luận theo hướng cố gắng tìm ra cách để đáp ứng mục tiêu chung của bạn; cung cấp phần mềm làm việc và bảo trì kịp thời.

Ví dụ, một số trái cây treo thấp là không thêm bất cứ điều gì vào hướng dẫn mã hóa. Mỗi khi điều đó xảy ra, mã trước đó tuân thủ các nguyên tắc không còn nữa và điều này dẫn đến việc bạn cần phải viết lại các đoạn mã. Hy vọng rằng nhà phát triển chính của bạn có thể thấy rằng ngay cả khi quy tắc được thêm vào có giá trị (theo quan điểm của anh ấy), nó có thể không làm tốt như việc thúc đẩy việc viết lại trong giai đoạn này của dự án đã muộn.

Nếu điều này hoạt động, bạn có thể cố gắng yêu cầu anh ta loại bỏ các quy tắc tùy ý hơn mà không thể tự động định dạng bằng một số công cụ.


-2

Tiêu chuẩn mã hóa là tốt. Thay đổi các tiêu chuẩn mã hóa là tốn kém (tốt, sẽ tốn kém nếu bạn làm cho chúng ít được phép hơn; nếu thay đổi đối với tiêu chuẩn khiến tất cả các mã hiện tại vẫn tuân thủ, thì đó không phải là vấn đề), vì vậy chỉ nên thực hiện khi cần thiết.

Một điều cần làm, có lẽ là phải kiểm tra tất cả mã trước khi cam kết / hợp nhất / bất cứ điều gì để đảm bảo nó tuân thủ tiêu chuẩn, vì rõ ràng chuỗi công cụ hiện tại dường như không thể tự động kiểm tra nó.


-3

phần mềm có thể giúp cứu sống những trường hợp khẩn cấp bằng cách tăng tốc độ phân phối thực phẩm

Tôi tin vào các tiêu chuẩn mã hóa tốt, nhưng tôi cũng tin rằng việc cứu sống quan trọng hơn nhiều.

Ưu tiên lớn nhất của bạn phải là cứu người . Hãy tưởng tượng nếu phần mềm này đang phân phối thực phẩm cho gia đình hoặc nhóm của bạn. Bất cứ điều gì khác có thể đến tiếp theo.

Tin tốt: bạn có bài kiểm tra. Các thử nghiệm sẽ giúp bạn tuân thủ các tiêu chuẩn mã hóa của bạn mà không phá vỡ chức năng, nhưng điều này sẽ xảy ra sau khi vận chuyển , không phải trước đó.


1
Điều gì sẽ xảy ra sau khi vận chuyển? Tuân thủ các tiêu chuẩn mã hóa mà không phá vỡ chức năng? Có xét nghiệm?
Martijn Pieters

Sau khi vận chuyển, anh ta nên làm việc theo tiêu chuẩn mã hóa.
Mohammad Tayseer
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.