Truyền cảm hứng cho một đồng nghiệp để áp dụng thực hành mã hóa tốt hơn?

Trong phần Xử lý câu hỏi đồng nghiệp cũ của tôi , nhiều người đã thảo luận các chiến lược đối phó với đồng nghiệp, những người không muốn tích hợp quy trình làm việc của họ với nhóm.

Nếu tôi có thể, muốn học một số chiến lược để "dạy" một đồng nghiệp chỉ đơn thuần là không biết gì về các kỹ thuật và công cụ hiện đại, và có thể hơi thờ ơ.

Tôi đã bắt đầu làm việc với một lập trình viên cho đến gần đây đã làm việc trong sự cô lập tương đối, trong một phần khác của công ty. Anh ấy có kiến ​​thức về lĩnh vực rộng lớn và quan trọng nhất là anh ấy đã thể hiện các kỹ năng giải quyết vấn đề tốt , điều mà nhiều ứng viên dường như còn thiếu.

Tuy nhiên, mã (C #) thực tế mà tôi đã thấy là một sự trở lại với VB6 ngày. Cấu trúc thủ tục, ký hiệu Hungary, biến toàn cục (lạm dụng static), không giao diện, không kiểm tra, không sử dụng Generics, ném System.Exception... bạn có ý tưởng.

Lập trình viên này lớn hơn tôi một chút và, ít nhất là bằng những ấn tượng đầu tiên, không chủ động tìm kiếm sự thay đổi tích cực. Tôi sẽ không nói chống lại sự thay đổi, bởi vì tôi nghĩ đó phần lớn là vấn đề làm thế nào để chủ đề được giới thiệu và tôi muốn được chuẩn bị.

Các lập trình viên có xu hướng trở thành những người bướng bỉnh, và tham gia vào các cuộc đấu súng và thực hiện các đánh giá mã rip-it-to-shreds và các chính sách được thi hành nghiêm ngặt rất có thể sẽ không tạo ra kết quả cuối cùng mà tôi muốn. Nếu đây là một người thuê mới, một lập trình viên cơ sở, tôi sẽ không nghĩ hai lần về việc giữ lập trường "người cố vấn", nhưng tôi cực kỳ cảnh giác đối xử với một nhân viên có kinh nghiệm như một người mới không biết gì (mà anh ta không - anh ta đã không theo kịp với những tiến bộ nhất định trong lĩnh vực này).

Làm thế nào tôi có thể đi về việc nâng cao tiêu chuẩn chất lượng mã của nhà phát triển này theo cách Dale Carnegie, thông qua sự thuyết phục nhẹ nhàng và khuyến khích phi vật chất? Điều gì sẽ là chiến lược tốt nhất để thực hiện các thay đổi tinh tế, dần dần, mà không tạo ra một tình huống bất lợi?

Có những người khác - đặc biệt là các nhà phát triển chính - đã ở trong tình huống này trước đây? Những chiến lược nào đã thành công trong việc kích thích sự quan tâm và tạo ra một nhóm năng động tích cực? Những chiến lược nào không thành công và sẽ tốt hơn để tránh?

Làm rõ:

Tôi thực sự cảm thấy rằng một số người đang trả lời dựa trên cảm xúc cá nhân mà không thực sự đọc tất cả các chi tiết của câu hỏi. Xin lưu ý những điều sau, đáng lẽ phải được ngụ ý nhưng hiện tại tôi đang nói rõ:

• Đồng nghiệp này chỉ là "tiền bối" của tôi theo độ tuổi. Tôi chưa bao giờ nói rằng danh hiệu, phạm vi ảnh hưởng của anh ta, hoặc số năm ở tổ chức vượt quá tôi, và trên thực tế, không có điều nào trong số đó là đúng. Anh ấy là một lập trình viên LOB, người đã bị cuốn hút vào cửa hàng phát triển chính. Đó là nó.

• Tôi không phải là một người thuê mới, lập trình viên cơ sở, hoặc một tên ngốc ngây thơ khác với những kế hoạch lớn để chuyển đổi công ty chỉ sau một đêm. Về cơ bản, tôi chịu trách nhiệm về quy trình phần mềm, nhưng như nhiều người từng làm "lãnh đạo" sẽ biết, trách nhiệm không phải lúc nào cũng tương quan chính xác với biểu đồ tổ chức.

• Tôi không hỏi mọi người làm thế nào để có được con đường của tôi, đến địa ngục hay nước cao . Tôi có thể làm điều đó nếu tôi muốn, với kết quả cuối cùng là người này sẽ trở nên bực bội và / hoặc bỏ cuộc. Hãy cố gắng hiểu rằng tôi đang tìm kiếm một phương pháp xã hội , hợp tác để thay đổi lái xe.

• Việc đề cập đến "... các biến toàn cầu ... không có thử nghiệm ... ném System.Exception" nhằm mục đích chứng minh rằng các vấn đề không chỉ là bề ngoài hay thẩm mỹ . Thực tiễn có thể hoạt động cho các ứng dụng CRUD tương đối nhỏ không nhất thiết phải hoạt động cho các ứng dụng doanh nghiệp lớn và trên thực tế, cho đến nay, không có mã nào thực sự vượt qua các bài kiểm tra tích hợp.

Xin vui lòng, cố gắng đặt câu hỏi theo mệnh giá, chấp nhận rằng tôi thực sự biết những gì tôi đang nói và trả lời câu hỏi mà tôi thực sự hỏi hoặc tiếp tục.

PS Lòng biết ơn chân thành nhất của tôi đối với những người - đưa ra lời khuyên mang tính xây dựng hơn là tranh luận với tiền đề. Tôi sẽ để điều này mở ra một thời gian nữa vì tôi hy vọng được nghe nhiều hơn theo cách trải nghiệm trong thế giới thực.

Điểm khởi đầu là biết khán giả của bạn . Bạn dường như đã hiểu điều này bởi vì bạn biết sự khác biệt giữa cố vấn cho đồng nghiệp cấp dưới và ảnh hưởng đến đồng nghiệp cấp cao.

Bạn vẫn cần phải tìm ra những gì sẽ thúc đẩy cá nhân cụ thể này. Những gì hoạt động trên một geezer cũ (như tôi), có thể không hoạt động cho geezer cũ của bạn.

Nếu anh ấy thích cố vấn / dạy người khác, bạn có thể tiếp cận một vấn đề bằng cách đặt câu hỏi như "tại sao bạn làm theo cách này?" Điều đó có thể nhận được một hộp thoại đi đến nơi bạn có thể yêu cầu anh ta đánh giá các phương pháp mới hơn và đưa ra ý kiến ​​của mình.

Nếu điều đó không hiệu quả, bạn có thể chỉ ra các lỗi có thể tránh được bằng cách sử dụng các thực tiễn hoặc phong cách mà bạn muốn anh ấy áp dụng. Điều này tốn nhiều công sức hơn vì bạn phải tìm ra lỗi và chỉ ra cách các hành vi bạn muốn khuyến khích sẽ giúp ích.

Nếu anh ấy có vẻ sẵn lòng giúp đỡ người khác, bạn có thể kêu gọi anh ấy muốn giúp đỡ người mới . Giải thích rằng "trẻ em ngày nay" không quen nhìn thấy phong cách mã hóa của anh ấy và sẽ có nhiều khả năng phá vỡ mã của anh ấy vì điều đó.

Đôi khi bạn có thể phải đối mặt với anh ấy và buộc vấn đề. Bạn cần chọn những trận chiến này một cách cẩn thận. Hãy chắc chắn rằng bạn bắt đầu với một chủ đề mà bạn biết bạn có thể chứng minh với anh ấy rằng bạn có cách tốt hơn.

Tôi nghĩ rằng bạn có thái độ đúng đắn. Chỉ cần đảm bảo chỉ ra để nói tất cả những điều tốt đẹp mà bạn đã nói - Kỹ năng giải quyết vấn đề tuyệt vời, nắm bắt công việc kinh doanh, v.v. và chỉ cần yêu cầu anh ấy dành một chút thời gian để cho anh ấy thấy các tiêu chuẩn hiện tại của nhóm sử dụng và cho anh ta một cơ hội để hỏi một số câu hỏi về họ.

Khi bạn cùng nhau mang cho anh ấy một ly cà phê hoặc thứ gì đó, và cho anh ấy biết rằng làm việc theo tiêu chuẩn sẽ có lợi cho anh ấy bằng cách giúp anh ấy dễ dàng hỗ trợ mã hiện tại của bạn và cũng giúp ai đó có thể giúp anh ấy dễ dàng hơn nếu anh ấy được bảo vệ trong công việc (một điểm cộng lớn cho ai đó đang làm việc cô lập), v.v.

Hãy chắc chắn rằng anh ấy đã tham gia và nhận được những lời giải thích tốt về lý do tại sao bạn làm những việc bạn làm và không tập trung vào lý do tại sao anh ấy không nên làm những việc anh ấy đang làm, mang đến cho người khác nếu bạn phải làm và giải thích cho bạn. Làm cho bản thân sẵn sàng sau đó nếu anh ta có bất kỳ câu hỏi và theo dõi với một vài nơi anh ta có thể tham khảo cho các ví dụ về tiêu chuẩn của bạn.

Nếu sau đó anh ấy không quan tâm thì bạn có thể tham khảo câu hỏi đầu tiên mà bạn liên kết.

Đó thực sự là công việc quản lý của bạn để

1. Nhận ra rằng công ty phải có một tiêu chuẩn mã hóa. Mỗi công ty hơi chuyên nghiệp đều có điều này, bất kể quy mô công ty.
2. Khiến mọi người ngồi lại với nhau và bắt đầu xây dựng một tiêu chuẩn. Bằng cách đó, mọi người đều có thể có tiếng nói của mình, và sau đó họ sẽ có động lực hơn để tuân theo tiêu chuẩn.

Nếu người quản lý của bạn không nhận ra điều này bởi chính họ, họ sẽ không đủ điều kiện cho công việc của họ. Và nếu vậy, bạn nên cung cấp cho họ một số ảnh khỏa thân ở trên hai. Những lợi thế của việc có một tiêu chuẩn mã hóa là rất nhiều, thực sự không có lập luận chống lại việc có một tiêu chuẩn. (Nếu một số lập trình viên cảm thấy rằng họ là "nghệ sĩ" và không nên bị giới hạn bởi giới hạn của tính chuyên nghiệp, họ nên kiếm một công việc làm mỹ thuật thay thế.)

Bản thân tiêu chuẩn mã hóa nên tập trung đầu tiên và quan trọng nhất vào việc cấm thực hành nguy hiểm và các chức năng thư viện nguy hiểm. Làm việc hướng tới một tập hợp con an toàn hơn và tinh khiết hơn của ngôn ngữ bạn đang sử dụng. Giữ tiêu chuẩn mã hóa không có "kiểu mã hóa", bởi vì kiểu mã hóa khó đồng ý hơn nhiều và gần như không quan trọng. Điều khá cổ điển là một công ty quyết định tạo ra một tiêu chuẩn mã hóa và ngay lập tức bị mắc kẹt trong một cuộc thảo luận vô nghĩa sôi nổi về nơi đặt niềng răng {}.

Để tham khảo, hãy xem cách viết tiêu chuẩn MISRA-C / C ++ và CERT C / C ++ / Java.

Trước hết bạn cần làm rõ TẠI SAO bạn muốn thay đổi cách làm việc của người này. Nếu chỉ vì lý do thẩm mỹ, tôi nghĩ bạn nên xem xét lại, bởi vì người này đã chứng minh rằng cách làm việc của anh ta thực sự hiệu quả.

Tuy nhiên, nếu có một lý do kỹ thuật cho nó, thì bạn nên xem xét việc tiếp cận người đã nói với một cái gì đó như:

Tôi có một gợi ý về cách bạn có thể tiết kiệm thời gian tẻ nhạt cho bạn và tiền cho công ty. Bạn có hứng thú không?

Xin lưu ý rằng đây phải là loại trái cây treo thấp vì rất có thể chúng sẽ yêu cầu thay đổi thói quen hiện tại luôn đòi hỏi nỗ lực thêm.

Ngay cả khi bạn có những gợi ý, chỉ cần chọn một hoặc hai, và chứng minh rằng đó sẽ là một sự thay đổi tốt hơn.

Điều này sẽ hoạt động, và bạn sẽ được hỏi nếu bạn có thêm đề xuất, hoặc nó sẽ không và sau đó thiệt hại được giới hạn ở một hoặc hai đề xuất.

Lưu ý rằng điều rất quan trọng là nó sẽ trở thành một thành công và thực hiện nhanh chóng.

Ngoài ra bạn cần cẩn thận. Có thể có những lý do rất tốt để làm mọi thứ theo cách chúng được thực hiện, nhưng bạn còn quá mới để thấy lý do tại sao. Do đó, hãy tôn trọng người lớn tuổi của bạn và hỏi trước khi bạn cho rằng đề nghị của bạn tốt hơn. Bạn có thể học một hoặc hai điều.

Tôi rất muốn ngăn cản bạn vào mặt anh ta vì điều này sẽ khiến tình hình trở nên tồi tệ rất nhanh. Tôi nhận ra rằng nó đã được đưa lên như một biện pháp cuối cùng nhưng theo kinh nghiệm của tôi, tại thời điểm này, nhà phát triển đã ngừng tham gia.

Buộc vấn đề có thể biến cá nhân thành kẻ thù nơi họ đang chiến đấu với mọi hành động của bạn. Điều đó thực sự sẽ có tác động nhóm tiêu cực và nó không kết thúc cho đến khi ai đó thoát hoặc bị sa thải.

Nếu cá nhân này thực sự có kiến ​​thức về miền mà bạn cần / muốn thì hãy nhờ họ ghi lại kiến ​​thức đó.

Bắt đầu bằng việc phá vỡ nó với anh ấy một cách nhẹ nhàng: Tôi không biết bạn có kinh nghiệm và thông thạo như thế nào trong việc đưa ra phản hồi. Bạn cũng có thể đã biết, sử dụng, hoặc thậm chí đã từ chối những điều sau đây, nhưng dù sao đi nữa. Có một số hướng dẫn về việc đưa ra phản hồi khi bạn muốn thay đổi hành vi của ai đó. Cấu trúc cuộc hội thoại mà tôi đã nghĩ và vẫn cố gắng sử dụng trong các tình huống mà tôi muốn đưa ra phản hồi (vì chúng hoạt động) như sau:

1. Mô tả hành vi bạn nhìn thấy. Đây phải là hành vi cụ thể. Ví dụ: "Tôi thấy rằng bạn đang sử dụng rất nhiều biến tĩnh trong mã của mình"
2. Mô tả làm thế nào điều đó tác động đến bạn / nhóm của bạn. Ví dụ: "Tôi thấy mã như vậy khó duy trì"
3. Đưa ra một giải pháp hợp lý . (các giải pháp khả thi được đề cập trong các câu trả lời khác và tôi sẽ tự tìm hiểu câu trả lời này sau.)
4. Cung cấp cho anh ta cơ hội để thảo luận về giải pháp. Hỏi anh ấy nghĩ gì về giải pháp. Lấy phản ứng của anh ấy theo mệnh giá. Bạn đã cho anh ấy ý kiến ​​của bạn, và anh ấy có thể tự do chấp nhận hay không. *

Ví dụ, một nguồn tài nguyên nhanh về phản hồi có thể được tìm thấy tại http://manlerhelp.org/cransplyskills/feedback.htmlm (mặc dù có rất nhiều loại công cụ này trên web)

Bây giờ về phần giải pháp, từ những gì tôi đang đọc trong câu trả lời của bạn, tôi tập hợp anh ấy rất thông minh, và có suy nghĩ đúng đắn, nhưng anh ấy chỉ đứng sau trong các thực hành tốt hiện đại. Những người đòi hỏi thời gian và nỗ lực để thành thạo, ngoài việc tìm hiểu thực tế về họ ở nơi đầu tiên, vì vậy bạn sẽ phải cung cấp cho anh ta cơ hội để làm điều đó. Điều đó có thể có nghĩa là thu thập các tài nguyên học tập (web, tạp chí, sách, bất cứ thứ gì) làm điểm khởi đầu và cung cấp cho anh ta thời gian rảnh để nghiên cứu chúng. Tôi có thể tưởng tượng việc cho anh ta vào mỗi chiều thứ sáu để mở rộng tầm nhìn về phong cách lập trình, nơi anh ta có thể làm bất cứ điều gì anh ta tin tưởng để đạt được những mục tiêu đó. Mọi người vốn dĩ muốn cải thiện bản thân. Cung cấp các tài liệu và thời gian, và họ sẽ sử dụng nó tốt.

Có thể quan trọng nhất, đừng mong đợi sự thay đổi qua đêm. Anh ấy đã làm mọi thứ theo cách của mình trong một thời gian dài, và có lẽ đã nhận được khá tốt về nó. Sẽ mất một thời gian để trở nên tốt hơn trong cách làm việc mới, và trong một thời gian, anh ta có lẽ sẽ không thấy nhiều giá trị theo những cách mới, bởi vì ban đầu, không có gì. Cách cũ của anh ấy có thể sẽ hiệu quả hơn trong một thời gian.

* Lưu ý: điều buồn cười về các cuộc hội thoại là chúng rất khó để mô hình hóa. Họ có một cuộc sống của riêng mình, vì vậy mặc dù nó trông rất đẹp trên giấy, nhưng nó có xu hướng lầy lội lên một chút.

Giải thích cách bạn muốn mọi thứ được thực hiện và cho anh ấy thấy nó hoạt động như thế nào với các lựa chọn thiết kế và kiến ​​trúc bạn đã thực hiện cho dự án khi bắt đầu dự án mà bạn sẽ làm cho anh ấy làm việc. Ngồi xuống từng người một (và riêng tư) và giải thích các vấn đề bạn đã thấy trong mã hóa trước đây của anh ấy và lý do tại sao chúng là một vấn đề cho dự án này. Hỏi anh ta những gì anh ta cần phải có để tốt hơn, nhưng làm rõ rằng không trở nên tốt hơn không phải là một lựa chọn.

Sau đó sử dụng xem lại mã như một công cụ để giúp anh ta điều chỉnh phương pháp làm việc của mình. Lên kế hoạch một thời gian dài cho người đầu tiên và thực sự nói về lý do tại sao bạn thích điều này hơn và để anh ta giải thích lý do của mình. Hãy chắc chắn để thực sự nghe thấy anh ấy, mọi người sẽ dễ dàng thay đổi hơn khi họ cảm thấy mối quan tâm của họ đã được giải quyết. Mong đợi trong kế hoạch của bạn (nhưng đừng nói với anh ấy điều đó) để làm lại nhiệm vụ đầu tiên và không chấp nhận nó cho đến khi nó đáp ứng các tiêu chuẩn của nhóm của bạn. Một khi anh ấy biết những gì bạn mong đợi và rằng bạn sẽ không để nó trôi theo lợi ích của thời gian, anh ấy có thể sẽ quay lại với cách làm việc của bạn. Nhưng bạn có thể sử dụng đánh giá mã như một công cụ giáo dục cho một số lần lặp. Bạn không phải khó chịu về việc không chấp nhận công việc cho đến khi nó đáp ứng các tiêu chuẩn của bạn, nhưng bạn phải kiên quyết với nó và nhất quán. Đừng '

Câu hỏi $ 64.000 là nếu anh ấy giao dự án của mình đúng thời hạn và đáp ứng các yêu cầu chức năng. Nếu vậy, anh ấy đang làm đúng. Không có mục tiêu đúng hay sai trong phát triển phần mềm. Cuối cùng, về việc giải quyết vấn đề. Và nếu các vấn đề được giải quyết cho sự hài lòng của khách hàng / khách hàng, thì theo định nghĩa , việc phát triển phần mềm đang được thực hiện một cách chính xác.

Tất nhiên nó trở thành một vấn đề hoàn toàn khác nếu dự án của anh không được hoàn thành. Tại thời điểm đó, những thay đổi cần phải được thực hiện bởi người giám sát của bạn, có lẽ với đầu vào của bạn. Nhưng chỉ vì anh ta vi phạm ý thức cá nhân về mã hóa hoặc trí tuệ thông thường ngày nay không có nghĩa là những gì anh ta làm là 'sai'. Bạn không phải là trọng tài của định nghĩa 'mã tốt'. Rốt cuộc, anh ta có thể có ý kiến ​​thấp về mã của bạn.

Vì vậy, trừ khi thực sự có vấn đề với công việc của anh ấy (mà bạn chưa chỉ ra là có), đừng làm gì cả. Một phần của việc trở thành một nhà phát triển thành công là học cách hợp nhất mã của bạn với các kiểu nhà phát triển khác.

Rốt cuộc, anh ta có thể đến đây và đăng một câu hỏi tương tự về việc đối phó với một nhà phát triển ít kinh nghiệm hơn, những người quan tâm đến việc theo kịp mốt hơn là hoàn thành các dự án. Đó là tất cả về quan điểm.

Là một nhà phát triển cơ sở nói chuyện với một nhà phát triển cấp cao, việc bạn thử và tiếp cận anh ta với những ý tưởng tốt hơn so với chính anh ta là quá rủi ro.

Cách tốt nhất để giải quyết vấn đề này là cố gắng thuyết phục sếp của bạn thực hành tốt hơn và xem liệu anh ta có đưa ra một nghị định rằng tất cả các mã phải tuân theo các tiêu chuẩn cụ thể và được thực thi theo các tiêu chuẩn đó thông qua đánh giá mã ngang hàng.

Một phần khá lớn của mọi người là (ngay cả khi ở cấp độ tiềm thức) mang tính thù hận, tự cao tự đại và phòng thủ, ngay cả khi họ hoàn toàn không biết về động cơ tiềm thức của chính mình, họ sẽ phạm tội nếu bạn cố gắng thay đổi hoặc ngụ ý rằng họ sai dù sao.

Chuỗi chỉ huy là cách an toàn nhất để đi vì anh ta đã lắng nghe ông chủ của mình, anh ta cũng không phải thích anh ta. Hãy để ông chủ là kẻ xấu, đó là những gì anh ta đang ở đó.

Nếu bạn không thể bán ông chủ hoặc ông ta là ông chủ thì hãy xử lý các lỗi của ông ta nhưng dẫn dụ bằng mã của BẠN.

Bạn không thể.

Bạn không thể truyền cảm hứng cho mọi người để làm những việc mà họ không biết trong phát triển phần mềm. Tôi nói từ kinh nghiệm khi tôi đã cố gắng làm điều này thường xuyên trong sự nghiệp của mình và mỗi khi kết quả cuối cùng là tình trạng của chính tôi giảm dần trong mắt công ty; Tôi thậm chí đã bị sa thải hoặc bỏ cuộc trong sự thất vọng sau khi không có gì xảy ra, chỉ đơn giản là cố gắng cải thiện văn hóa phát triển xung quanh tôi thành các thực tiễn hiện đại.

Nếu đồng nghiệp của bạn không biết gì, bạn có thể chỉ cho họ. Tuy nhiên, vì họ không có gì bạn có thể làm vì họ không có khả năng hoặc không đủ quan tâm đến kỹ năng chế tạo phần mềm để cố gắng áp dụng các thực tiễn mã hóa tốt hơn. Rất có thể nếu bạn cố gắng, họ sẽ bỏ qua nó hoặc lẩm bẩm mà không thực sự hiểu, mà từ âm thanh của nó là những gì họ đã làm ("Phát triển thử và lỗi" tức là chỉ hack trong mã cho đến khi lỗi dừng) .