Làm thế nào để chuyển đổi một lập trình sao chép / dán / spaghetti để nhìn thấy ánh sáng?

Câu hỏi này được lấy cảm hứng từ câu hỏi này . Trong khi câu hỏi khác được coi là cục bộ, tôi tin rằng vấn đề tiềm ẩn là một điều cực kỳ phổ biến trong ngành công nghiệp của chúng tôi. Tôi biết có một số nhà phát triển, những người sẽ đọc nó và nghĩ rằng tôi đang tạo ra thứ này và sau đó họ có thể trả lời cách mọi người quan tâm đến công việc của họ và muốn tìm hiểu, nhưng chỉ nhìn vào các bài đăng khác của Lập trình viên SE ( trường hợp cụ thể ), Tôi biết điều đó không đúng.

Vì vậy, giả sử bạn có ai đó trong nhóm của mình (hoặc có thể là đa số), quy trình vận hành tiêu chuẩn là sao chép / dán và ai tin rằng mọi thứ đều có thể được giải quyết nếu bạn chỉ thêm đủ các lệnh gọi và biến. Người này chưa bao giờ nghe về TDD, DRY hoặc RẮN và ngoài 40 giờ làm việc khi họ bận làm việc, họ không bao giờ đọc một cuốn sách phương pháp / phương pháp / thiết kế duy nhất.

Trước đây tôi (và những người khác) đã từng hỏi, làm thế nào để bạn dạy cho 3M . Nhưng bây giờ tôi nghĩ đó không phải là câu hỏi đúng. Câu hỏi thực sự là làm thế nào để bạn tiếp cận một người / nhóm như vậy và khiến họ tò mò về cách làm việc tốt hơn? Làm thế nào để bạn truyền cảm hứng cho họ để học? Không có điều đó, dường như tất cả các bài giảng, các cuộc họp, bài giảng, các cuộc thảo luận đều vô ích nếu họ hoàn toàn hạnh phúc khi trở lại bàn làm việc và làm những việc họ luôn làm.

Tôi làm việc với một nhóm người như vậy. Họ thực sự là những cá nhân khá sáng dạ, nhưng tôi ghét khi tôi nghe, "Tôi đã viết mã xong, chỉ cần cấu trúc lại và chia thành nhiều lớp để làm cho DXM hạnh phúc". Họ không tái cấu trúc để mã sạch hơn, dễ đọc hơn, có thể duy trì được, nhưng chỉ vì nếu không họ sẽ bị mắng. Tôi biết họ có khả năng học hỏi, dường như thiếu động lực chung.

Khi tôi phân phối công việc, nó thường có ít lỗi hơn và công việc tôi sở hữu không bao giờ trở thành quái vật 5000 dòng của một lớp. Những người khác sẽ đưa ra nhận xét như "mã của bạn sạch hơn và dễ đọc hơn nội dung của chúng tôi", vì vậy họ thấy sự khác biệt. Nhưng đồng thời, tôi cảm thấy như họ tin rằng họ được trả tiền trong 40 giờ bất kể họ làm gì, vì vậy họ thực sự không phiền nếu họ dành trọn 3 ngày trong QA để tìm kiếm một lỗi không nên được giới thiệu nơi đầu tiên Hoặc họ mất một tuần để sửa đổi một lớp vì có quá nhiều phụ thuộc mà cuối cùng họ chạm vào. Mặc dù, "có lẽ lớp đó nên được viết khác đi" dường như không bao giờ bật lên.

Có thể làm bất cứ điều gì trong những tình huống này? Có ai thành công chưa? Hoặc là tốt nhất để cô lập tư duy như vậy cho các phần không quan trọng của dự án và giảm thiểu thiệt hại?

LƯU Ý: Khi tôi nói "thiếu động lực". Tôi không nghĩ rằng nó thiếu động lực để làm việc hoặc làm một công việc tốt bởi vì họ chỉ đơn giản là ngừng quan tâm. Hầu hết các nhóm của chúng tôi thực sự hoàn toàn ngược lại. Họ chắc chắn quan tâm đến sản phẩm. Chúng tôi có những người sẽ làm việc đêm và cuối tuần. Phần tôi đang cố gắng vượt qua là với những thói quen và kỹ năng được cải thiện, họ thực sự sẽ không phải làm việc nhiều. Tôi đoán rằng điều "40 giờ" làm cho bài đăng này nghe có vẻ hơi tiêu cực.

Bạn tìm cho mình lý do: "Tôi biết họ có khả năng học hỏi, dường như là thiếu động lực chung."

Có những người đam mê công việc của họ. Và có những người khác, đôi khi đủ năng lực, đang làm việc chỉ vì tiền . Họ biết công cụ của họ, nhưng họ không thích công việc của họ. Họ sẽ không dành thêm thời gian để thực hiện tái cấu trúc bổ sung để làm cho mã có thể đọc được hoặc giải quyết vấn đề hấp dẫn khi một bản hack nhanh và xấu có thể thực hiện công việc.

Hiện tượng này tồn tại trong mọi công việc. Chỉ là một số công việc không thú vị lắm (bạn có thấy một kế toán yêu thích công việc của mình và mơ về nó khi còn nhỏ không?), Nhưng trong lập trình, có rất nhiều người thực sự yêu thích những gì họ đang làm (nếu không Lập trình viên.SE sẽ khá trống rỗng). Điều này có nghĩa là với tư cách là những nhà phát triển đam mê, nói chuyện hàng ngày với các nhà phát triển đam mê khác, chúng ta có nhiều cơ hội hơn để ngạc nhiên khi thấy một người làm lập trình chỉ vì tiền.

Chúng ta có thể làm gì? Không quá nhiều. Trong mọi trường hợp, điều đó không phải với bạn, mà là với nguồn nhân lực để chọn những người thực sự có động lực¹. Và sa thải những người không.

Bạn có thể cố gắng tự động viên đồng nghiệp của mình, nhưng điều đó cực kỳ khó khăn. Nếu bạn cho họ đọc sách, họ sẽ trả lại chúng chưa mở một vài tuần sau đó. Nếu bạn cho họ một lời khuyên, họ sẽ không lắng nghe, vì họ không quan tâm².

Bạn có thể:

• Thuyết phục sếp của bạn thiết lập một số quy tắc nghiêm ngặt trong công ty của bạn: hướng dẫn về phong cách , v.v ... Điều này sẽ không thúc đẩy những người đó làm việc tốt hơn, nhưng ít nhất họ sẽ không thể cam kết mã nguồn không phù hợp với yêu cầu .

• Làm việc theo yêu cầu, đặc biệt là yêu cầu phi chức năng . Điều gì về một yêu cầu cho biết rằng một dự án cụ thể phải chứa ít hơn 5.000 dòng mã IL (không, tôi không nói về LỘC vô nghĩa ) ³? Điều gì về yêu cầu để có được kết quả cụ thể ở độ phức tạp chu kỳ hoặc khớp nối lớp ?

• Tăng số giờ bạn dành cho công ty của bạn để thực hiện đánh giá mã . Chỉ định nội dung được đánh giá: nếu bạn có danh sách kiểm tra, hãy thêm các điểm liên quan đến tái cấu trúc, khả năng đọc, nhận xét rõ ràng và hữu ích, v.v. Nếu bạn không có danh sách kiểm tra, bạn phải.

• Sử dụng [thêm] lập trình cặp . Nó có thể giúp cải thiện chất lượng mã và thúc đẩy các đồng nghiệp ít động lực hơn.

• Sử dụng hệ thống bù tương tự như những gì được sử dụng tại Fog Creek.

^{Đó là những gì các cuộc phỏng vấn nói về: trước khi tuyển dụng bạn, nguồn nhân lực không chỉ là tài sản kỹ thuật của bạn, mà còn là động lực của bạn . Đáng buồn thay, một số công ty quên đi phần thứ hai của cuộc phỏng vấn này và thuê những người không thích lập trình quá nhiều. Hạnh phúc, trong hầu hết các trường hợp, công việc trong các công ty đó không bao giờ thú vị, và thử nghiệm Joel hiếm khi vượt quá 2.}

^{² Họ thực sự không quan tâm, ngay cả khi họ kiếm được ít tiền hơn. Tôi khá thân với một trong những khách hàng của mình (tôi là một freelancer) tin rằng công việc của anh ấy là phát triển trang web cho chính khách hàng của mình. Ông cũng có một nhà thiết kế. Tôi đã nói với họ nhiều lần về những cách họ có thể tăng năng suất lên 2 hoặc nhiều hơn. Nếu họ chỉ thuê một người có năng lực, họ sẽ tăng doanh thu của họ ít nhất là 3. Nhưng họ có đủ tiền và không quan tâm đến chất lượng hoặc chi phí cho những khách hàng không biết gì, so với ai đó làm việc hiệu quả.}

^{Ý tôi là số dòng mã IL mà bạn thấy trong Mã số liệu trong Visual Studio , số liệu thực sự có nghĩa là gì đó. Các thực LỘC không quan trọng và bạn không cần phải đo lường nó; đó là một trong những số liệu ngu ngốc nhất Thực thi các dòng mã IL có nghĩa là các nhà phát triển sẽ buộc phải thực sự cấu trúc lại mã, và không chỉ thu gọn mười dòng mã trong một dòng không thể đọc được.}

"Tôi đã viết mã xong, chỉ cần cấu trúc lại và chia thành nhiều lớp để làm cho DXM hạnh phúc".

Dòng suy nghĩ đó đúng là có một căn bệnh ung thư đối với bất kỳ đội nào và sẽ giết chết động lực của toàn đội nếu không được chăm sóc ngay lập tức. Tất nhiên tôi đang đề cập đến thực tế là bằng thâm niên và / hoặc bằng khen, bạn tình cờ ở vị trí của cơ quan kỹ thuật, cho bạn sức mạnh để giúp ảnh hưởng và mang lại những thông lệ tốt cho nhóm của bạn.

Đây là tất cả tốt và tốt, tuy nhiên nếu nhóm của bạn được bán rõ ràng trên các quy trình này, họ sẽ không đưa bạn ra những tuyên bố như thế này cho thấy rõ sự thiếu tôn trọng quy trình và thiếu tôn trọng bạn. Họ vẫn xem những thực tiễn tốt nhất này là một trở ngại do bạn gây ra và không phải là một quá trình thuộc sở hữu của nhóm mà nhóm của bạn sẽ bảo vệ công trạng của chính mình.

Bạn đề cập trong các ý kiến ​​trước đây rằng các thành viên khác trong nhóm thực sự tuân theo các thực tiễn và tiêu chuẩn này và áp dụng chúng một cách chính xác. Tập trung chú ý đầu tiên vào việc hỗ trợ từ họ, hỏi họ những gì hoạt động, những gì không hoạt động, những gì họ thích và những gì họ muốn thấy đã thay đổi. Nếu bạn làm điều này và xem trọng ý kiến ​​của họ, họ sẽ cảm thấy rất khác về các tiêu chuẩn như thể họ là một quyết định của cộng đồng thay vì một thủ tục được trao cho họ từ cấp trên.

Bạn tăng cường hỗ trợ cho các thực tiễn và tiêu chuẩn tốt nhất bằng cách chỉ ra cho nhóm cách họ đã cải thiện quy trình phát triển phần mềm hoặc chất lượng của phần mềm.

Giữ một cuộc bỏ phiếu về các vấn đề để thảo luận và ghi lại kết quả, lý tưởng là mọi quyết định nên được nhất trí vì tính hợp pháp nhưng nếu bạn đang đối phó với những người cản trở đường lối cứng rắn thì điều này có thể là không thể và chỉ có thể trì hoãn mọi vấn đề. Sử dụng một phiếu bầu đa số trong tình huống này. Nếu đa số chống lại các tiêu chuẩn và thực tiễn đề xuất của bạn thì bạn đã mất phòng rồi, chỉ cần từ bỏ nó vào thời điểm đó.

Họ sẽ sở hữu những tiêu chuẩn và quy trình đó và sẽ thực thi chúng để bạn không phải làm vậy. Là một nhà lãnh đạo công nghệ, bạn không cần phải tuyên bố sắc lệnh và nghị định, đó là một cách kém để trở thành một nhà lãnh đạo.

Một khi nhóm cảm thấy như thể họ sở hữu các quy trình thì các thành viên của nhóm bắt đầu gắn nhãn bạn với các quy trình nhất định và các thực tiễn tốt nhất sẽ là bất hợp pháp khi nghĩ như vậy. Nhóm của bạn sẽ giúp điều chỉnh thái độ này ở những người khác.

Câu hỏi hay! Tôi nghĩ câu trả lời phụ thuộc vào lý do tại sao mọi người không muốn cải thiện kỹ năng của họ. Câu trả lời có thể là:

• Họ nghĩ rằng họ quá bận rộn để học một cái gì đó mới hoặc họ nghĩ rằng cách làm mới (như viết tất cả các bài kiểm tra đó) sẽ khiến họ mất nhiều thời gian hơn và họ không có thời gian cho việc đó. Sau đó, câu trả lời rõ ràng sẽ là: cho họ thêm thời gian. Học cái gì đó hoặc cố gắng một cái gì đó giống như TDD khi bạn đã điều luôn làm khác đi sẽ mất nhiều thời gian hơn các cặp vợ chồng đầu tiên của thời đại. Nếu lập trình viên của bạn không có thời gian đó, bạn không thể đổ lỗi cho họ vì đã không cố gắng.
• Họ có một nhận thức khác nhau về các kỹ năng của chính họ, tức là họ nghĩ rằng họ là những lập trình viên rất giỏi sản xuất mã chất lượng cao. Đây là địa hình tâm lý khó khăn, bởi vì phá vỡ niềm tin đó có thể rất mất thẩm mĩ. Có lẽ một số loại cạnh tranh không chính thức có thể giúp ích (ai tạo ra ít lỗi / tính năng nhất? Mã ngắn nhất? Ít WTF nhất / phút trong đánh giá mã?).
• Có thể có một vấn đề động lực thực sự (tức là họ chỉ muốn "làm thời gian của họ và để lại một mình" cho đến khi đóng cửa). May mắn thay, điều này quá chung chung / không liên quan đến lập trình, bởi vì tôi thực sự không có câu trả lời cho điều đó.
• Họ là người mới bắt đầu và họ không biết rõ hơn. Trong trường hợp đó, đào tạo, đánh giá mã có thể giúp ích hoặc một "câu lạc bộ sách" nơi một thành viên trong nhóm phải thảo luận về một cuốn sách kỹ thuật mới mỗi tháng.
• Họ đã từng thấy những viên đạn bạc trước đó, (và thất vọng cay đắng) và họ nghĩ bất cứ điều gì bạn đang cố gắng bán chúng chỉ là một từ thông dụng mới nghe có vẻ hay trên lý thuyết và ít được sử dụng trong thực tế. Trong trường hợp đó, việc chứng minh các lợi thế trong quá trình đánh giá mã và các phiên lập trình cặp có thể hoạt động. Cố gắng không trở thành một người biết tất cả khi bạn làm điều đó.

Giải pháp tốt nhất thực sự phụ thuộc vào vấn đề gốc: Ví dụ: hướng dẫn, số liệu và đánh giá mã hóa chính thức có thể có hiệu quả cho người mới bắt đầu, nhưng những người trong "nhận thức sai về kỹ năng của chính họ" -crowd có thể đấu tranh chống lại họ hoặc chơi các số liệu vì họ thấy họ như những trở ngại quan liêu phản tác dụng để hoàn thành công việc của họ.

Câu hỏi thực sự là làm thế nào để bạn tiếp cận một người / nhóm như vậy và khiến họ tò mò về cách làm việc tốt hơn? Làm thế nào để bạn truyền cảm hứng cho họ để học? Không có điều đó, dường như tất cả các bài giảng, các cuộc họp, bài giảng, các cuộc thảo luận đều vô ích nếu họ hoàn toàn hạnh phúc khi trở lại bàn làm việc và làm những việc họ luôn làm.

Đó là nó! Đây thực sự là một câu hỏi thực sự.

Để cung cấp một số thông tin, chúng tôi đơn giản là không có thời gian để đào tạo chính quy - nhưng đôi khi nếu tôi làm - nó vẫn không thấy sáng. Tôi cũng là một phần của các công ty nơi đào tạo chính quy trở thành một quá trình nhưng và tôi thường là một nhân chứng đến nỗi họ hầu như không dạy họ cách suy nghĩ.

Vì vậy, câu hỏi mà tôi đặt ra cho họ không phải là làm thế nào để dạy họ - mà là làm thế nào để họ học? Sự khác biệt là tinh tế nhưng đó là những gì sẽ làm cho tất cả sự khác biệt.

Tôi không biết mình có đúng không; nhưng thường thì tôi tin vào một hộp thoại của Ma trận bộ phim - "Đó là câu hỏi thúc đẩy chúng tôi!" Điều quan trọng nhất là khiến họ suy nghĩ, khiến họ hỏi tại sao! Và tất nhiên, hầu hết những người nghĩ rằng họ đã biết tất cả mọi thứ về một số mẫu thiết kế bởi vì họ đạt điểm cao trong các khóa học đại học - là khó khăn nhất ở đó.

Làm thế nào để bạn có được làm cho họ những câu hỏi như vậy? Cách tiếp cận chung của tôi là "ném chúng xuống ao nếu bạn muốn chúng học bơi" . Tôi đồng ý rằng mọi người có thể không đồng ý; và tôi sẽ vui lòng đồng ý không đồng ý với họ. Khi bạn ném chúng xuống ao - chúng thực sự không học bơi tự động; nhưng nó phát ra một bản năng sinh tồn khiến họ phải suy nghĩ - một khi điều đó xảy ra, họ sẽ tự nhiên nghĩ về CÁCH và TẠI SAO.

Một ví dụ thực tế tôi đưa ra cho mọi người là đưa họ vào một dự án phức tạp đáng kể so với những gì họ đã hy vọng có được trên đó và để họ chiến đấu với trận chiến của chính họ. Khi họ bắt đầu làm sáng tỏ mã và thấy khó theo dõi nó - bạn nhận ra họ bắt đầu hỏi câu hỏi hay.

Điều này nghe có vẻ hơi cực đoan, điều này nghe có vẻ lãng phí tài nguyên . Và tôi chắc chắn, có nhiều người khác sẽ cho tôi lời khuyên không nên làm điều này. Nhưng điều này đã làm việc cho tôi!

Bất kể gói trả tiền và thẻ nhân sự nào bạn chỉ định, nó sẽ không giải quyết được vấn đề động lực cơ bản . Vì con đường duy nhất là họ bị thử thách; Nếu bạn châm ngòi cho tinh thần con người cơ bản này - mọi thứ khác đều hoạt động. Nếu bạn không thể là một trò chơi lỏng lẻo.

PS: Chỉ là tình cờ tôi đã đăng một câu trả lời ở đây https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - và tôi đã nhận được tất cả chủ yếu là hầu hết mọi người tin rằng bằng cách nào đó các doanh nghiệp không thể lãng phí tài nguyên! Tôi chắc chắn, câu trả lời này có thể được điều trị tương tự ở đây. Nhưng sự thật là, làm cho mọi người làm việc và khiến họ tin vào việc làm tốt là một chủ đề của tâm lý con người về cách chế tạo các giáo trình của khóa học.

Dù sao, nhiệm vụ mà bạn đang mô tả ở đây có nghĩa là bỏ qua niềm đam mê bên trong để làm thay đổi lớn. Và hệ thống càng lớn thì càng khó. Bắt đầu với những người trẻ tuổi hơn, những người vẫn được xây dựng với tinh thần làm việc tốt và thách thức hiện trạng.

Như bạn chỉ ra, động lực của nó. Đừng nhầm họ không quan tâm đến họ không biết. Họ biết rõ phải làm gì. Họ chỉ không quan tâm . Nếu đó là trường hợp, câu hỏi thực sự ở đây là ... quản lý của bạn đang làm gì sai khiến họ không có động lực? Bạn có phải là thành viên mới nhất của đội không? Có lẽ họ đã trải qua tất cả những điều này trước đây, với nó chỉ dẫn đến các vấn đề từ quản lý của họ. Vì vậy, họ chỉ cố gắng thực hiện số lượng công việc thấp nhất cần thiết để duy trì công việc của mình vì họ không nghĩ làm nhiều hơn sẽ được nhà tuyển dụng đáp ứng.

Dường như với tôi rằng đây là vấn đề về quản lý và lãnh đạo - nếu nhóm của bạn thì bạn có thể làm việc để cải thiện (cá nhân và mã) một thuộc tính cốt lõi của nhóm của bạn, câu hỏi sẽ được quản lý của bạn hỗ trợ - bởi vì bạn sẽ muốn làm những việc sẽ mất thời gian (họ sẽ có được một chiến thắng ròng vì bạn nên giảm nợ kỹ thuật mới và sẽ trả được nợ kỹ thuật hiện có).

Vì vậy, bạn khẳng định rằng bạn muốn nhóm cải thiện, bạn đồng ý rằng đây là một điều tốt (rằng toàn bộ nhóm, hoạt động để cải thiện chất lượng mã của nó) và sau đó bạn bắt đầu một chương trình để thực hiện điều này xảy ra - nghe có vẻ dễ dàng ... Tôi biết là không!

Tôi nghĩ có hai phần trong vấn đề này - giáo dục và thực hành làm việc.

• Giáo dục bạn có thể bắt đầu một giờ ăn trưa mỗi tuần - mọi người ăn cùng nhau, bạn chạy một bài thuyết trình 20 ~ 30 phút với Hỏi & Đáp. Bạn bắt đầu với những điều cơ bản bạn muốn - RẮN có thể chiếm 2 ~ 4 tuần đầu tiên - theo thời gian bạn sẽ khiến nhóm phát biểu luân phiên và bạn có thể tìm ra cách quyết định ai sẽ nói về vấn đề gì giữa bạn. Cho phép người nói một số thời gian chuẩn bị trong công việc. Ngoài ra, khuyến khích sự tham dự của các nhóm người dùng địa phương (bằng cách làm cho nó ít nhất là một phần xã hội nếu có thể)
• Thực hành làm việc ... tốt, nó phụ thuộc vào những gì bạn làm bây giờ và công cụ bạn đã có, nhưng bạn có thể muốn xem xét các tiêu chuẩn mã hóa đồng ý, giới thiệu đánh giá mã ngang hàng (có chắc chắn không), kiểm tra đơn vị (không nhất thiết phải kiểm tra trước) , chạy một máy chủ tích hợp liên tục và xem xét thử nghiệm tự động hơn (ngoài các thử nghiệm đơn vị). Nhưng những điều này về cơ bản sẽ được giới thiệu với sự đồng ý / thỏa thuận (không phải máy chủ xây dựng / CI!) Và bạn phải muốn hướng tới chất lượng như một đội. Luôn có những thứ người ta có thể cải thiện (Kaizen)

Nó cũng đáng để xem Kanban (được xem như là một trình điều khiển để thay đổi / cải tiến).

Một suy nghĩ cuối cùng - Tôi là một lập trình viên dạy nghề và tôi muốn nhóm của mình giống nhau nhưng làm việc hơn 40 giờ một tuần không thực sự là một điều tốt vì vậy mục tiêu của một người là phải có một nhóm hoàn thành công việc của mình hiệu quả và tốt trong tuần làm việc bình thường và đối với điều này, lập luận để cải thiện thực hành làm việc là rất có thể, ví dụ: thêm các bài kiểm tra đơn vị để chứng minh trường hợp thất bại khi (trước) sửa lỗi giúp bạn tự tin rằng đó làđã sửa; có một máy chủ xây dựng giúp bạn tự tin vào khả năng xây dựng các giải pháp của mình một cách sạch sẽ - nếu bản dựng đó cũng tạo ra các gói triển khai, điều đó có nghĩa là việc triển khai được đơn giản hóa đáng kể; Mã RẮN, theo định nghĩa, dễ sửa đổi hơn; và trên toàn hội đồng, khoản nợ kỹ thuật càng ít bạn phải trả càng ít ...

Tôi đã rơi vào lập trình một cách tình cờ ~ 30 năm trước. Tôi đã có động lực để học các nguyên tắc kỹ thuật phần mềm cơ bản bằng cách được chỉ định để duy trì / hỗ trợ mã của người khác. Trong các bài tập này, tôi đã học được cách một trình đọc mã trải nghiệm mã - cách đồng cảm với trình đọc mã. Tôi không muốn gây ra nỗi đau về mã viết kém của mình cho người khác!

Cách thực hành này để giao cho các lập trình viên mới duy trì / hỗ trợ mã người khác không phải là một viên đạn ma thuật và dường như nó cung cấp động lực để học cách tạo ra mã rắn thường xuyên hơn không.