Tôi có nên theo một phong cách mã hóa xấu chỉ để tuân theo các quy ước đã được thiết lập tại nơi làm việc của tôi không?

102

Tôi đã làm việc trong khoảng một năm. Tôi chủ yếu làm việc trong giao diện GUI của chúng tôi, sử dụng các phương thức từ phụ trợ C, nhưng tôi thường không phải xử lý chúng ngoại trừ các giá trị trả về. GUI của chúng tôi được cấu trúc khá hợp lý, với những hạn chế của chúng tôi.

Tôi đã được giao nhiệm vụ thêm một chức năng vào phần dòng lệnh của chương trình. Hầu hết các chức năng này giống như 300 dòng dài và khó sử dụng. Tôi đang cố gắng thu thập các mẩu của chúng để có được thông tin báo động cụ thể và tôi gặp khó khăn trong việc tổ chức. Tôi biết rằng tôi đang làm cho thử nghiệm của mình phức tạp hơn bằng cách thực hiện nó trong một chức năng dài duy nhất.

Tôi có nên giữ mọi thứ trong một chức năng lớn theo kiểu của các chức năng hiện có hay tôi nên gói gọn các báo động trong các chức năng của chúng?

Tôi không chắc liệu nó có phù hợp để đi ngược lại các quy ước mã hóa hiện tại hay không, liệu tôi có nên cắn viên đạn và làm cho mã khó hiểu hơn một chút để tự viết.

Tóm lại, tôi đang so sánh

showAlarms(){
    // tons of code
}

chống lại

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDIT: Cảm ơn lời khuyên của mọi người, tôi quyết định rằng tôi sẽ thiết kế mã của mình, sau đó hỏi họ muốn gì, và nếu họ muốn tất cả trong một, tôi có thể cắt từ mã được bao thanh toán của mình và biến nó thành 1 chức năng lớn. Điều này sẽ cho phép tôi viết nó và kiểm tra nó dễ dàng hơn ngay cả khi họ muốn tất cả mã trong một định nghĩa duy nhất.

CẬP NHẬT: Họ cuối cùng đã hài lòng với mã được bao thanh toán và hơn một người đã cảm ơn tôi vì đã thiết lập tiền lệ này.

coding-style conventions

— Justin
nguồn

117

Điều đáng nghi ngờ là công ty bạn làm việc đảm nhận chức năng của bạn phải dài 300 dòng vì "đó là cách chúng tôi luôn làm." Đó không phải là "quy ước kiểu mã hóa;" đó chỉ là phong cách xấu.

— Robert Harvey

64

Đây là điều bạn nên thảo luận với các thành viên khác trong nhóm của mình, để tìm ra những thực tiễn bạn thấy là những quy ước mà họ cho là quan trọng để mọi người tuân theo và những điều mà ai đó đã làm một lần và bạn không làm Cần thi đua. Sẽ không có nghi ngờ gì về số lượng của cả hai.

— Phục vụ

17

@beginnerBinx Điều đó chỉ liên quan đến cách bạn diễn đạt nó. Đừng nói cụm từ đó là "X đang làm điều gì đó thực sự ngu ngốc, tôi cũng phải làm điều ngu ngốc đó." nhưng đúng hơn là, "Tôi nhận thấy rằng X đang làm điều này, có một lý do cụ thể nào đó xảy ra như vậy không, có phải là vấn đề nếu tôi không làm điều tương tự khi viết Y không?" Sau đó, quyết định của họ là có nên bash mã cũ hay giải thích lý do tại sao họ phải làm theo cách đó (cho dù đó là miễn cưỡng hay nhiệt tình).

— Phục vụ

11

Phong cách tốt hay xấu thường được tranh luận và không thường xuyên đồng ý. Dạy học đại học là các chức năng nên ngắn nhưng nếu điều này che khuất ý nghĩa, đừng làm điều đó. Bài kiểm tra phải rõ ràng, thay vì không suy nghĩ theo một bộ quy tắc.

— quick_now

9

Những người ngẫu nhiên trên internet không thể đọc được đồng đội của bạn, vì vậy tất cả các câu trả lời bạn nhận được ở đây chỉ là sở thích cá nhân. Bạn nên nói chuyện với nhóm của bạn. Là chức năng dài một nguyên tắc thiết kế có chủ ý? Họ có muốn bạn tiếp tục phong cách của chức năng dài hay họ muốn bạn viết những gì bạn cho là sạch nhất?

— JacquesB

102

Đây thực sự là giữa bạn và đồng đội của bạn. Không ai khác có thể cho bạn câu trả lời đúng. Tuy nhiên, nếu tôi có thể dám đọc giữa các dòng, thực tế là bạn gọi phong cách này là "xấu" sẽ cung cấp một số thông tin cho thấy tốt hơn là nên chậm lại. Rất ít phong cách mã hóa thực sự là "xấu". Có những cái tôi sẽ không sử dụng, bản thân tôi, nhưng chúng luôn có một vần điệu hoặc lý do cho chúng. Điều này cho thấy, với tôi, có nhiều câu chuyện hơn bạn đã thấy cho đến nay. Hỏi xung quanh sẽ là một cuộc gọi rất khôn ngoan. Ai đó có thể biết một cái gì đó bạn không.

Cá nhân tôi đã gặp phải điều này, trong bước đột phá đầu tiên của tôi vào mã hóa nhiệm vụ quan trọng trong thời gian thực. Tôi thấy mã như thế này:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Là nhà phát triển OO C ++ sáng sủa và sáng bóng, tôi đã ngay lập tức gọi họ về các rủi ro lỗi mà họ gặp phải bằng cách khóa và mở khóa các mutexes bằng tay, thay vì sử dụng RAII . Tôi nhấn mạnh rằng điều này là tốt hơn:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Đơn giản hơn nhiều và an toàn hơn, phải không?! Tại sao yêu cầu các nhà phát triển nhớ mở khóa các mutexes của họ trên tất cả đường dẫn luồng điều khiển khi trình biên dịch có thể làm điều đó cho bạn!

Vâng, những gì tôi phát hiện ra sau đó là có một lý do thủ tục cho việc này. Chúng tôi phải xác nhận rằng, đúng vậy, phần mềm hoạt động chính xác và có một danh sách hữu hạn các công cụ chúng tôi được phép sử dụng. Cách tiếp cận của tôi có thể tốt hơn trong một môi trường khác, nhưng trong môi trường tôi đang làm việc, cách tiếp cận của tôi sẽ dễ dàng nhân số lượng công việc liên quan đến việc xác minh thuật toán gấp mười lần vì tôi chỉ đưa khái niệm RAII của C ++ vào một phần mã điều đó đã được tuân theo các tiêu chuẩn thực sự phù hợp hơn với suy nghĩ theo kiểu C.

Vì vậy, những gì trông giống như xấu, hết sức nguy hiểm, phong cách mã hóa đối với tôi thực sự được cân nhắc kỹ và giải pháp "tốt" của tôi thực sự là giải pháp nguy hiểm sẽ gây ra vấn đề trên đường.

Vậy hãy hỏi xung quanh. Chắc chắn có một nhà phát triển cao cấp có thể làm việc với bạn để hiểu lý do tại sao họ làm theo cách này. Hoặc, có một nhà phát triển cao cấp có thể giúp bạn hiểu chi phí và lợi ích của một công cụ tái cấu trúc trong phần này của mã. Dù bằng cách nào, hãy hỏi xung quanh!

— Corton
nguồn

60

Có thể cho rằng phần nguy hiểm hơn của ví dụ về mutex là thiếu nhận xét mã rõ ràng giải thích lý do tại sao nó không thể sử dụng RAII. Cấp, nếu khóa / mở khóa rõ ràng này là tất cả trên cơ sở mã, có thể khó sử dụng để thêm nhận xét cho mỗi trường hợp. Trong trường hợp đó, có lẽ nên viết một tài liệu mồi mà các nhà phát triển mới bắt buộc phải làm quen.

— Kelvin

10

Chắc chắn, nói chuyện với một cấp cao luôn tốt, và tái cấu trúc phải được thực hiện một cách cẩn thận (và với thử nghiệm). Và tất nhiên, đồng thời / mutexes là một con thú đặc biệt của riêng họ. Nhưng khi thấy các chức năng có> 300 dòng, tôi sẽ không đầu tư quá nhiều thời gian vào việc tìm kiếm một "lý do kỹ thuật ẩn" tại sao các chức năng này quá lớn. Lý do tại sao các chức năng trở nên quá dài luôn giống nhau và chúng không mang tính kỹ thuật.

— Doc Brown

8

@DocBrown Chỉ vì họ không có kỹ thuật không có nghĩa là họ không phải là lý do. Điều quan trọng là các nhà phát triển phải nhớ rằng chúng là một phần của một cỗ máy lớn hơn. (Tôi không thể đếm số lần tôi phải học lại bài học đó)

— Cort Ammon

4

@DocBrown Dù bằng cách nào, đó là nhà phát triển cấp cao mà người ta nên nói chuyện. Tôi đã chọn ví dụ mà tôi đã làm bởi vì nó dễ dàng tìm thấy vô số đối số cho lý do tại sao mã ngu ngốc là ngu ngốc. Tìm các đối số cho lý do tại sao mã trông ngu ngốc thực sự không ngu ngốc là khó hơn.

— Cort Ammon

3

@DocBrown Từ ý kiến và câu trả lời của bạn, tôi nghĩ rằng tôi có thể nói rằng sự khác biệt của ý kiến của chúng tôi là bạn đang bắt đầu từ giả định rằng mã đã "xấu", dựa trên những bằng chứng bạn đã đưa ra, trong khi tôi muốn thực hiện các đường dẫn khám phá xem mã có "xấu" trước hay không.

— Cort Ammon

84

Thành thật mà nói, bạn có tin rằng có các chức năng khó sử dụng, với 300 dòng, chỉ là vấn đề của phong cách? Vì vậy, theo gương xấu có thể giữ cho chương trình tổng thể ở trạng thái tốt hơn vì tính nhất quán? Tôi đoán bạn không tin như vậy, nếu không bạn sẽ không hỏi câu hỏi này ở đây.

Tôi đoán là các chức năng này rất dài bởi vì trong kinh doanh của chúng tôi có rất nhiều lập trình viên tầm thường, chỉ chồng chất lên các tính năng, không quan tâm đến khả năng đọc, chất lượng mã, đặt tên thích hợp, kiểm tra đơn vị, tái cấu trúc và họ chưa bao giờ học cách tạo ra sự trừu tượng thích hợp . Bạn phải tự quyết định nếu bạn muốn theo đàn đó, hoặc nếu bạn muốn trở thành một lập trình viên tốt hơn.

Phụ lục, do các ý kiến: "300 dòng" và "khó sử dụng" là những dấu hiệu mạnh mẽ của IMHO cho mã xấu. Theo kinh nghiệm của tôi, rất khó có thể có một số "lý do kỹ thuật ẩn" tại sao mã đó không thể được thực hiện theo cách dễ đọc hơn, có thể so sánh với ví dụ về câu trả lời của Cort Ammon. Tuy nhiên, tôi đồng ý với Cort, bạn nên thảo luận vấn đề này với các phản hồi trong nhóm - không tìm thấy lý do mơ hồ tại sao mã hoặc "kiểu kiểu" này không thể thay đổi, nhưng để tìm hiểu cách mã có thể được tái cấu trúc một cách an toàn mà không phá vỡ mọi thứ .

— Bác sĩ Brown
nguồn

127

Ngay cả các lập trình viên có thẩm quyền cũng phạm những tội ác này khi có thời hạn chặt chẽ.

— vườn

13

@gardenhead, tôi có thể hiểu không tái cấu trúc hàm 300 dòng để tiết kiệm thời gian, nhưng không có cách nào có thể viết hàm 300 dòng sẽ giúp bạn tiết kiệm thời gian.

— Dangph

39

@gardenhead: khi tôi đến bác sĩ phẫu thuật vì tôi cần sự giúp đỡ khẩn cấp, tôi vẫn mong anh ấy dành thời gian để rửa tay trước khi bắt đầu thực hiện với tôi. Đây là điều mà nhiều người phải học hỏi trong kinh doanh của chúng tôi để đạt được năng lực thực sự : luôn để lại mã ở trạng thái tốt hơn so với trước đây và điều này cũng sẽ cải thiện khả năng giữ thời hạn. Các hàm 300 dòng thường phát triển từng ngày, bởi những người không quan tâm và họ sẽ luôn sử dụng "thời hạn" làm lý do.

— Doc Brown

17

@Dangph nó tiết kiệm thời gian khi bạn chỉ thêm 5 dòng vào hàm thay vì tái cấu trúc nó. Chúng thường phát triển khi hàm ban đầu dài (hơn 30 dòng) và lập trình viên tiếp theo nghĩ rằng "đây không phải là mã của tôi, tôi sẽ không tái cấu trúc để không phá vỡ nó, chỉ cần thêm một vài dòng ở đây và ở đó".

— Džuris

7

@Juris, theo tôi hiểu, câu hỏi là về việc tạo một hàm mới, không tái cấu trúc các hàm hiện có. Nếu bạn đang viết một chức năng mới, bạn sẽ không tiết kiệm thời gian bằng cách biến nó thành một chức năng quái vật duy nhất.

— Dangph

42

Không.

Trong cuốn sách Lập trình viên thực dụng , tác giả nói về Lý thuyết cửa sổ vỡ .

Lý thuyết này nêu rõ:

Hãy xem xét một tòa nhà với một vài cửa sổ bị phá vỡ. Nếu các cửa sổ không được sửa chữa, xu hướng phá hoại sẽ phá vỡ thêm một vài cửa sổ. Cuối cùng, họ thậm chí có thể đột nhập vào tòa nhà, và nếu nó không có người, có lẽ sẽ trở thành những kẻ nhổ hoặc đốt lửa bên trong.

Hoặc xem xét một vỉa hè. Một số rác tích lũy. Chẳng mấy chốc, nhiều rác tích lũy. Cuối cùng, mọi người thậm chí bắt đầu để lại những túi rác từ các nhà hàng mang ra khỏi đó hoặc thậm chí đột nhập vào ô tô.

Trong cuốn sách tác giả viết song song giữa lý thuyết và mã này. Khi bạn tìm thấy một mã như thế này, bạn dừng lại và tự đặt câu hỏi cho chính câu hỏi đó.

Và câu trả lời là không.

Khi bạn rời khỏi cửa sổ bị hỏng này - trong trường hợp của chúng tôi, mã xấu - điều này sẽ tạo ra hiệu ứng mà mọi người sẽ để lại các cửa sổ bị hỏng phía sau.

Và một ngày mã sẽ colapse.

Đưa một bản sao của Clean Code và Clean Coder cho mọi người.

Và trong khi bạn ở trong môn học, một bản sao của TDD cũng là một bản hay.

— linuxunil
nguồn

6

Điều gì xảy ra nếu codebase là một nhà kính không có gì ngoài cửa sổ bị vỡ?

— Alan Shutko

8

@AlanShutko Sau đó, đảm bảo hồ sơ của bạn là hiện tại? Tìm một chủ nhân khác bây giờ .

— David Montgomery

12

Mã hiếm khi "sụp đổ". Việc thêm các tính năng mới ngày càng khó hơn, mất nhiều thời gian hơn và các ước tính để làm sạch mã sẽ tăng lên - điều đó có nghĩa là càng khó hơn để có được ngân sách thời gian cho việc dọn dẹp cần thiết.

— Doc Brown

8

Wow, thật là một sự tương tự tùy tiện, lý thuyết "cửa sổ vỡ" dường như là vậy.

— Samthere

4

TDD không có gì để làm với điều đó. Cho dù bạn đang đi thiết kế trình điều khiển Business / Domain / Test / nothingness mà không thay đổi bất cứ điều gì về việc tuân theo các điều cơ bản của mã sạch. Xin lỗi nhưng thật sự mệt mỏi khi thấy 'TDD' được trích dẫn ở mọi nơi mà thậm chí không có trong chủ đề

— Walfrat

25

Vâng, đi cho nó. Cấu trúc! = Phong cách

Bạn đang nói về cấu trúc, không phải phong cách. Hướng dẫn về phong cách không (thường) quy định cấu trúc, vì cấu trúc thường được chọn vì sự phù hợp của nó đối với một vấn đề cụ thể, không phù hợp với một tổ chức.

Hãy cẩn thận

Chỉ cần chắc chắn rằng bạn không gây ra hậu quả tiêu cực trong các lĩnh vực khác có thể không xảy ra với bạn. Ví dụ,

Hãy chắc chắn rằng bạn không làm phức tạp các khác biệt hoặc hợp nhất mã bởi vì bạn đã xóa sạch mọi sự tương đồng với mã hiện có.
Hãy chắc chắn rằng các luồng ngoại lệ nổi lên chính xác và dấu vết ngăn xếp không bị ô nhiễm với một đống vô nghĩa không thể đọc được.
Hãy chắc chắn rằng bạn không vô tình để lộ các điểm vào công cộng sẽ gây ra vấn đề nếu được gọi trực tiếp (không đặt chúng trên bản đồ và / hoặc không xuất chúng).
Không làm lộn xộn không gian tên toàn cầu, ví dụ: nếu tất cả các hàm nhỏ hơn của bạn yêu cầu một số loại bối cảnh toàn cầu đã được khai báo trước đó trong phạm vi hàm cục bộ.
Hãy chắc chắn xem bất kỳ nhật ký nào và tự hỏi liệu bạn có thuộc nhóm hỗ trợ nếu các nhật ký được tạo bởi mã của bạn sẽ gây nhầm lẫn khi nhìn thấy đan xen với nhật ký từ bất kỳ mã nào bạn không chạm vào.
Hãy chắc chắn rằng bạn làm tuân theo phong cách hiện có, ví dụ như ngay cả khi họ đang sử dụng cũ-trường Hungary ký hiệu và nó làm cho đôi mắt của bạn chảy máu, lại phù hợp với cơ sở mã chung. Điều duy nhất đau đớn hơn việc đọc ký hiệu Hungary là đọc mã sử dụng hàng tá loại ký hiệu khác nhau tùy thuộc vào người đã viết gì.

Hãy nhẹ nhàng

Hãy nhớ rằng bạn là một phần của một nhóm và trong khi mã tốt là quan trọng, thì điều rất quan trọng là các thành viên trong nhóm của bạn có thể duy trì nội dung mà bạn đã viết khi bạn đi nghỉ. Cố gắng bám vào một dòng chảy sẽ có ý nghĩa với những người đã quen với phong cách cũ. Chỉ vì bạn là người thông minh nhất trong phòng không có nghĩa là bạn nên nói chuyện trên đầu mọi người!

— John Wu
nguồn

"Hãy cố gắng bám vào một dòng chảy sẽ có ý nghĩa với những người đã quen với phong cách cũ." - vì vậy, lời khuyên của bạn là lập trình theo cách tương tự như bất kỳ chú hề bất tài nào đã làm trước đây? Thêm chức năng 300 dòng sẽ không làm cho nó dễ dàng.

— BЈовић

11

Tôi đã không nói để dính vào một dòng chảy tương tự. Tôi nói dính vào một dòng chảy mà họ sẽ hiểu.

— John Wu

2

Lời khuyên tốt. Khi tôi tái cấu trúc một lệnh đơn thành 5 hàm trong câu trả lời này, tôi đã thay đổi một cách tinh tế ngữ nghĩa bằng các giá trị tiền điện toán bên trong một biểu thức logic ban đầu chỉ được tính toán có điều kiện. Các nhà phê bình đã bắt được nó mặc dù ;-). Lời khuyên nghiêm túc là xem xét và kiểm tra kỹ lưỡng. Mỗi thay đổi có thể đưa ra các lỗi và đó có thể là lý do chính khiến không ai thực hiện chúng.

— Peter A. Schneider

6

Tôi không thấy đây là một quy ước mã. Tôi thấy đây là một người không hiểu cách viết mã duy trì dễ hiểu. Tôi sẽ chia mã của bạn thành các chức năng khác nhau khi bạn đề xuất và giáo dục nhóm của bạn về lợi ích của việc này trong khi cố gắng hiểu lý do tại sao họ cảm thấy các hàm 300 dòng có thể chấp nhận được. Tôi rất muốn nghe lý do của họ.

— Bernard
nguồn

1

" Không có lý do, đó chỉ là chính sách của chúng tôi. "

5

Câu trả lời là trong phần đánh giá mã.

Câu hỏi thực sự là nếu bạn bật mã được bao thanh toán tốt, bạn sẽ là người duy nhất sẵn sàng làm việc với nó chứ?

Tôi, giống như hầu hết mọi người ở đây, tin rằng các hàm 300 dòng là một sự gớm ghiếc. Tuy nhiên, đưa Windex đến bãi rác sẽ không có tác dụng gì nhiều. Vấn đề không phải là mã, đó là các lập trình viên.

Chỉ đúng là không đủ. Bạn cần bán người theo phong cách này. Ít nhất là về việc đọc nó. Nếu bạn không kết thúc như anh chàng tội nghiệp này: bị sa thải vì kỹ năng của bạn quá xa so với đồng nghiệp của bạn

Khởi đầu nhỏ. Hỏi xung quanh và tìm hiểu xem có ai khác thích các chức năng nhỏ hơn không. Tốt hơn là rình mò xung quanh cơ sở mã và xem liệu bạn có thể tìm ra ai viết những cái nhỏ nhất không (bạn có thể thấy rằng mã xấu nhất là mã cũ nhất và các lập trình viên hiện tại đang viết mã tốt hơn). Nói chuyện với họ về điều này và xem nếu bạn có một đồng minh. Hỏi xem họ có biết ai khác cũng cảm thấy như vậy không. Hỏi xem họ có biết ai ghét chức năng nhỏ không.

Tập hợp nhóm nhỏ này và nói về việc thay đổi. Chỉ cho họ loại mã bạn muốn viết. Hãy chắc chắn rằng họ có thể đọc nó. Hãy phản đối nghiêm túc. Thực hiện các thay đổi. Nhận mã của bạn được phê duyệt. Bây giờ bạn có sức mạnh của một cuộc họp phía sau bạn. Một vài trong số này và bạn có thể tạo một tài liệu một trang rõ ràng chấp nhận kiểu mới mà bạn đã giới thiệu.

Các cuộc họp là những điều mạnh mẽ đáng ngạc nhiên. Họ có thể tạo ra ảnh hưởng. Clout là những gì bạn sẽ sử dụng để chống lại những người chống lại phong trào này. Và đó là những gì tại thời điểm này. Một bước chuyển. Bạn đang đấu tranh cho quyền cải thiện hiện trạng. Mọi người sợ thay đổi. Bạn sẽ cần nói chuyện ngọt ngào, vỗ về, và prod. Nhưng với một chút may mắn, bạn sẽ biến thành quyền được chấp nhận.

— candied_orange
nguồn

5

Nếu cần nhiều xã hội hóa và nhiều cuộc họp để thuyết phục các nhà phát triển rằng phương pháp 300 dòng là quá dài, thì tôi không nghĩ rằng việc nói chuyện sẽ có ích. Vấn đề với cách tiếp cận trên là nếu bạn xin phép viết mã tốt, bạn sẽ phòng thủ. Nhưng nếu bạn chỉ viết mã tốt và dành thời gian để cấu trúc lại mã hiện có, thì bất kỳ ai phản đối sẽ giải thích tại sao phương pháp 300 dòng là tốt và để biện minh cho việc dành thời gian đưa nó trở lại.

— Brandon

3

Tôi có thể nói với bạn rằng nếu tôi được mời tham gia một loạt các cuộc họp để thảo luận về các dòng mã theo giới hạn chức năng, tôi sẽ tìm cách thoát khỏi các cuộc họp như vậy. Không có con số chính xác và bạn sẽ không bao giờ khiến mọi người đồng ý. Đôi khi, mọi người cần được chỉ ra một cách tốt hơn.

— Brandon

Đôi khi, tách ra một chức năng khổng lồ (và đặt tên cho mọi thứ tốt hơn và thêm nhận xét và tài liệu khi tôi tìm ra nó là bước đầu tiên cần thiết trước khi thực hiện một thay đổi một cách rõ ràng.

— JDługosz

@Brandon Có lẽ bạn không có ý nói theo cách này nhưng điều tôi nghe được là bạn đúng và mọi người khác chỉ có thể giải quyết. Miễn là mã của bạn hoạt động thì không vấn đề gì nếu những người còn lại trong nhóm không hiểu nó. Nó chắc chắn không đáng để bạn phải bận tâm dạy chúng bất cứ điều gì. Bạn hoàn toàn vui khi thấy họ tiếp tục tạo ra 300 hàm dòng trong khi bạn viết mã theo cách riêng của mình.

— candied_orange

1

@CandiedOrange Tôi chắc chắn không có ý chống lại đội. Điều tôi muốn nói là một số chủ đề được học tốt nhất bằng cách xem chúng hoạt động, nhưng cố gắng để một nhóm đưa ra quyết định dân chủ về phong cách sẽ không hiệu quả. Tôi đã thấy tính nhất quán được sử dụng như một cái cớ để viết mã không thể đọc được. Kết quả? Nhiều mã không thể đọc được. Tôi có thể thiết lập một loạt các cuộc họp để nói về nó, hoặc tôi chỉ có thể sửa nó, và sau đó cho mọi người thấy kết quả.

— Brandon

3

Đôi khi bạn phải đi với dòng chảy.

Giống như bạn đã nói, bạn đã được giao nhiệm vụ triển khai một chức năng trong một cơ sở mã hoạt động hiện có.

Bất kể lộn xộn, và tôi hiểu nó là cám dỗ để làm sạch nó. nhưng trong thế giới kinh doanh, bạn không phải lúc nào cũng có cơ hội tái cấu trúc mã.

Tôi sẽ nói chỉ cần làm những gì bạn đã được yêu cầu và tiếp tục.

Nếu bạn cảm thấy nó đáng để tái cấu trúc hoặc viết lại hơn bạn cần đưa nó lên để thảo luận với nhóm.

— trung gian
nguồn

2

Nếu bạn xin phép trên mỗi lần tái cấu trúc nhỏ, bạn sẽ mãi mãi có mã không thể nhầm lẫn, điều này gây nguy hiểm cho doanh nghiệp. Các nhà quản lý chỉ nhìn vào chi phí của một sự thay đổi, nhưng hiếm khi nhìn vào chi phí của việc không thay đổi.

— Brandon

5

OP đã được yêu cầu viết một hàm không sửa đổi hàng trăm dòng mã

— meda

2

@meda chính xác! Tôi đang ở trong tình trạng rất giống nhau. Tôi đang phát triển các mô-đun mới cho mạng nội bộ của công ty và tôi đang tìm thấy những gì có thể được mô tả là "năm bỏ bê ngoài sửa chữa", với phần mềm máy chủ và thư viện hoàn toàn không được cập nhật kể từ năm 2006. Tôi không có nghĩa vụ phải dọn dẹp mớ hỗn độn này , nhưng tôi mất nhiều thời gian hơn để viết mã vì những hạn chế. (Hãy tưởng tượng MySQl 5.2, MySQL 5.0). Tôi không thể cập nhật bất cứ điều gì vì có lẽ mã hiện tại sẽ không chạy trên các phiên bản mới hơn do mã không dùng nữa.

— roetnig

3

"Nếu nó không bị hỏng, đừng sửa nó." Tôi có một chiếc xe 20 tuổi bị rò rỉ một chút dầu. Đáng chi tiền vào? Không đáng tin cậy? Đúng.

3

Trước khi đưa ra tuyên bố rằng các thực tiễn là xấu, trước tiên tôi sẽ thực hiện một bước để hiểu lý do cho các phương pháp lớn và các thực tiễn khác có thể gặp phải là xấu.

Sau đó, bạn sẽ cần đảm bảo phạm vi kiểm tra khá cao hoặc thực sự cao (theo như bạn có thể thực hiện mà không cần tái cấu trúc lớn). Nếu không, tôi sẽ hướng tới việc bảo hiểm thực sự cao mặc dù bạn không viết mã. Điều này giúp xây dựng mối quan hệ và nhóm mới của bạn sẽ đưa bạn nghiêm túc hơn.

Một khi bạn có những căn cứ này, không ai trong tâm trí của họ sẽ thách thức bạn. Là một phần thưởng, hãy thực hiện một số điểm chuẩn vi mô và điều đó sẽ thực sự bổ sung vào trường hợp của bạn.

Thông thường, cách bạn từ nó đi một chặng đường dài hướng tới thay đổi văn hóa mã. Dẫn bằng ví dụ. Hoặc thậm chí tốt hơn, chờ đợi một đoạn mã bạn có thể viết - tái cấu trúc và đơn vị kiểm tra địa ngục của nó và viola - bạn sẽ được nghe.

— bỏ qua
nguồn

Tôi không tái cấu trúc mã hiện tại, tôi chỉ đang viết một hàm mới, không chắc là tôi có nên tuân theo 'quy ước' không và mã hóa nó trong hơn 300 dòng quái vật hoặc chia nó thành các đoạn logic như tôi thường làm nhưng có không được thực hiện trong phần này của cơ sở mã.

— Justin

1

họ có các quy tắc để đảm bảo bạn viết các phương thức mới trong hơn 300 dòng không? nếu không, tôi sẽ viết nó đúng cách. nhưng tôi chắc chắn sẽ tránh đường để đảm bảo tôi kiểm tra chúng bao gồm cả các nhánh. Tôi đã trải qua những kinh nghiệm tương tự và thường thì bạn sẽ chiến thắng chúng. mẹo là làm theo thời gian và xây dựng mối quan hệ.

— bỏ qua

3

Loại câu hỏi này về cơ bản là " xin vui lòng đọc các đồng đội của tôi ". Những người ngẫu nhiên trên internet không thể làm điều đó, vì vậy tất cả các câu trả lời bạn sẽ nhận được chỉ là những ý kiến cá nhân về phong cách mã hóa. Sự đồng thuận là phương pháp ngắn hơn là thích hợp hơn, nhưng dường như bạn đã tự nghĩ như vậy, vì vậy không cần phải khôi phục điều đó.

Vì vậy, cơ sở mã hiện tại dường như sử dụng một kiểu mã hóa khác mà kiểu bạn thích. Những gì bạn nên làm? Trước tiên, bạn cần phải tìm ra:

Đây có phải là một quyết định thiết kế có chủ ý được hỗ trợ bởi nhóm hiện tại của bạn?
Họ có muốn bạn theo phong cách này?

Chỉ có một cách để tìm hiểu. Hỏi .

Có thể có nhiều lý do để có chức năng dài. Có thể là do nhóm tin rằng các chức năng dài tốt hơn nhiều chức năng ngắn. Nó cũng có thể là vì đó là mã kế thừa và nhóm thích mã mới theo thiết kế sạch hơn. Vì vậy, một trong hai lựa chọn có thể khiến bạn gặp rắc rối với tư cách là một nhà phát triển, nếu bạn không nói chuyện với nhóm và hiểu lý do của họ.

— JacquesB
nguồn

1

Tôi hoàn toàn đồng ý và thêm vào, "Bạn có thể bị sa thải hoặc gặp rắc rối vì không làm theo những gì người khác đã làm không?" Vậy thì câu trả lời là có! Theo sau mọi điều xấu công ty yêu cầu bạn phải làm và đối phó với nó.

— Cướp

1

Có nhiều cấp độ khác nhau của "phong cách".

Ở một cấp độ, thường là một phần của quy ước mã hóa, điều này có nghĩa là nơi đặt các khoảng trắng, dòng trống, dấu ngoặc và cách đặt tên các thứ (trường hợp hỗn hợp, dấu gạch dưới, v.v.).

Ở một cấp độ khác là mô hình lập trình, đôi khi những thứ như tránh thống kê hoặc sử dụng giao diện trên các lớp trừu tượng, làm thế nào để phơi bày sự phụ thuộc, thậm chí có thể tránh một số tính năng ngôn ngữ bí truyền.

Sau đó, có các thư viện và khung được sử dụng bởi dự án.

Đôi khi sẽ có một giới hạn tối đa về kích thước chức năng. Nhưng hiếm khi có giới hạn tối thiểu! Vì vậy, bạn nên tìm ra những điều trong số những quyền hạn được coi là quan trọng và cố gắng tôn trọng điều đó.

Bạn cần tìm hiểu xem nhóm có bất lợi trong việc tái cấu trúc mã hiện có hay không, việc này cần được thực hiện độc lập với việc thêm mã mới khi có thể.

Tuy nhiên, ngay cả khi họ không muốn cấu trúc lại mã hiện có, bạn có thể giới thiệu một số lớp trừu tượng cho mã mới mà bạn thêm, nghĩa là theo thời gian bạn có thể phát triển cơ sở mã tốt hơn và có thể di chuyển mã cũ như bảo trì của nó gọi cho.

— Erik Eidt
nguồn