Vào cuối sợi dây của tôi [đóng]


17

Tôi là một nhà thầu cho một công ty lớn. Hiện tại, có ba nhà phát triển trong dự án, bao gồm cả tôi.

Vấn đề là 2 nhà phát triển khác không thực sự hiểu nó. "Nó" tôi có nghĩa là như sau:

  • Họ không hiểu các thực tiễn tốt nhất cho công nghệ chúng tôi đang sử dụng. Sau 6 tháng tôi và những người khác đưa ra ví dụ cho họ, có những kiểu chống khủng khiếp đang được sử dụng.
  • Họ là những "lập trình viên và sao chép" sản xuất mã spaghetti chủ yếu.
  • Họ liên tục phá vỡ mọi thứ, thực hiện các thay đổi nhưng không thực hiện kiểm tra khói cơ bản để xem tất cả có tốt không
  • Họ từ chối / hiếm khi yêu cầu đánh giá mã.
  • Họ từ chối / hiếm khi làm những việc cơ bản như định dạng mã.
  • Không có tài liệu về bất kỳ lớp học nào (jsdocs)
  • Sợ xóa mã mà không làm gì cả
  • Để lại các khối mã nhận xét ở khắp mọi nơi mặc dù chúng tôi có kiểm soát phiên bản.

Tôi thấy mình ngày càng thất vọng hơn khi tôi định dạng mã người khác, sửa lỗi, khám phá chức năng bị hỏng và tạo ra sự trừu tượng để loại bỏ spaghetti.

Tôi thật sự không biết phải làm gì. Tôi cố gắng để không nản lòng, nhưng đó chỉ là một mớ hỗn độn. Tôi thích những người này như mọi người, nhưng tôi cảm thấy tình hình mã hóa tệ đến mức tôi có thể di chuyển nhanh hơn nếu họ chỉ đơn giản duyệt web cả ngày.

Sẽ là không phù hợp để yêu cầu người quản lý của chúng tôi xem xét quyền truy cập cam kết svn khác; cam kết chỉ có thể được thực hiện sau khi xem xét bởi một người am hiểu về những gì chúng ta đang làm? Là một nhà thầu, tôi không chắc đó có phải là động thái tốt nhất hay không.

Có một cách tinh tế / không quá tinh tế để làm cho nó rõ ràng có bao nhiêu điều tôi đang sửa chữa?


1
Tôi đã mở một câu hỏi để trả lời cho câu hỏi này, mà tôi nghĩ rằng khái quát hóa vấn đề thực sự mà nhóm của bạn đang gặp phải: lập trình viên.stackexchange.com/ questions/127117 / Lỗi . Theo như giới thiệu các bài kiểm tra tự động, tôi hoàn toàn đồng ý với bài đăng của Martin Blore: martinblore.wordpress.com/2010/06/02/ Ấn - không có nguyên tắc và nền tảng tốt, nỗ lực TDD sẽ bị lãng phí rất nhiều. Tôi đã cố gắng không tham gia vào nền tảng đó trong bài viết của mình vì tôi cũng tò mò.
DXM

vấn đề tôi có là các bài kiểm tra chỉ xác minh chức năng đang hoạt động. Họ không giải quyết 7 mục khác tôi liệt kê.
hvgotcodes

1
Bạn đã thử lập trình cặp với những người này? họ sẽ thấy quan điểm của bạn và bạn sẽ thấy quan điểm của họ nếu bạn ngồi trên một máy duy nhất và phát triển một chức năng duy nhất. Làm điều đó trong một tháng, 3 ngày một tuần, 3 giờ một ngày. Nó có thể giúp. Cũng thiết lập CI và xuất bản phạm vi bảo hiểm mã và số liệu tỷ lệ vượt qua trường hợp thử nghiệm. Hãy để việc xây dựng thất bại nếu bất kỳ ai trong số đó bị vi phạm.

Câu trả lời:


7

Tôi đang có một cái gì đó như thế này trong đội của tôi. Tôi đã cố gắng hết sức để khiến mọi người làm điều đúng đắn và nó không hoạt động như mong đợi nên tôi chuyển sang một giải pháp khác.

Đầu tiên, tôi đã đi đến người quản lý của mình và chúng tôi đã tìm ra một thỏa thuận, không có mã nào được đưa vào kiểm soát nguồn trừ khi nó được bao phủ bởi các bài kiểm tra đơn vị. Nếu mã được đưa vào mà không có kiểm tra đơn vị, tôi có quyền phủ quyết để hoàn tác cam kết ngay lập tức và ping bất kỳ ai chịu trách nhiệm họ có thể làm việc trên các thử nghiệm và sau đó đẩy mã.

Với quy định này tại chỗ, tôi thường xuyên chạy các công cụ bảo hiểm mã (trong trường hợp này, jacoco trong chúng tôi SBT xây dựng) để đảm bảo phần được bảo hiểm một cách chính xác và tôi cũng đang làm phép tái cấu trúc và mã số nhận xét liên tục trong bất kỳ mã đẩy bởi chúng. Vì đây là một dự án JavaScala, tôi có rất nhiều công cụ để giúp tôi nắm bắt những thứ không nên có hoặc không hoạt động theo cách chúng tôi nghĩ, không chắc bạn có thể làm như thế nào với JavaScript nhưng có lẽ có một giải pháp.

Điều chính tôi tin là giúp tôi theo kịp điều này là tôi có một cái nhìn rõ ràng về những gì tôi mong đợi của dự án và kiến ​​trúc chính của nó, vì vậy bất cứ khi nào tôi thấy một cái gì đó không phản ánh quan điểm này, tôi có thể đến đó và sửa nó. Bạn cũng nên làm như vậy, xác định quan điểm của mình, các mẫu nên được sử dụng, cách viết mã và giữ bản thân trên hết, luôn để họ (và quản lý của bạn) biết điều gì đang xảy ra và điều gì khiến dự án tiếp tục nhanh hơn

Chắc chắn sẽ có lúc họ từ bỏ và làm điều đúng đắn hoặc ban quản lý nhận được thông điệp và xóa họ khỏi dự án.


5
vấn đề ở đây (và tôi không chắc câu hỏi này có quá cục bộ không vì nguyên nhân cơ bản mà tôi nghĩ là rất phổ biến) là làm thế nào để bạn truyền cảm hứng cho các nhà phát triển học hỏi và phát triển thay vì dựa vào các thực hành sao chép "đúng và thử" của họ / dán và giữ cho spaghetti'ing mọi thứ lên. Nếu OP chuyển sang vai trò giám sát / người đánh giá / người phê duyệt, nó sẽ cắt giảm đáng kể thời gian của anh ta. Đồng thời, những người viết mã xấu, viết các bài kiểm tra đơn vị thậm chí còn tồi tệ hơn. Họ sẽ đi chậm hơn, viết các bài kiểm tra không thể nhận ra, và sau đó họ sẽ chỉ ra rằng kiểm tra đơn vị không hoạt động và đổ lỗi cho bạn vì đã gợi ý
DXM

dxm, vâng, đây là một vấn đề. Quan điểm của câu hỏi của tôi là làm thế nào để đưa vấn đề này đến quản lý, mặc dù tôi thừa nhận rằng có lẽ không rõ ràng lắm.
hvgotcodes

2
Tôi nghĩ rằng lựa chọn tốt nhất để đưa điều này đến quản lý là cho thấy số lượng mã mà họ yêu cầu làm lại và mức độ lãng phí đang bị lãng phí trong việc này.
Maurício Linhares

7

Tôi chắc chắn bây giờ bạn đã thấy những bình luận của tôi và bài đăng khác của tôi, vì vậy tôi sẽ không giả vờ rằng tôi thực sự biết câu trả lời. Điều tốt nhất tôi có thể cung cấp là một bản tóm tắt về những gì tôi đã nghe / đọc từ người khác và thêm một số kinh nghiệm của riêng tôi vào hỗn hợp.

Đầu tiên, tôi muốn nói rằng cách đây ít lâu tôi đã bắt gặp một blog thuộc về một trong những thành viên SE lập trình viên của chúng ta, Martin Blore và IMO bài đăng cụ thể này về tự thực hiện TDD là rất chính xác. TDD là cấp độ cuối cùng, cao nhất gắn kết mọi thứ lại với nhau nhưng không có cấp độ trước đó, đặc biệt là cấp độ lớn nhất, các nguyên tắc và thực tiễn sản xuất mã rõ ràng và dễ đọc, sẽ rất khó nếu không thể làm cho TDD hoạt động.

Trong công ty của tôi, cả Agile và TDD đều bị quản lý áp đặt lên chúng tôi, và lúc đầu, chúng tôi chỉ đơn giản làm điều đó vì chúng tôi đã nói (điều ngược lại với nhanh nhẹn). Chúng tôi đã thử TDD hai lần và trong khi tôi là người đề xuất sử dụng các bài kiểm tra tự động rất lớn, cá nhân tôi đã loại bỏ tất cả những bài mà nhóm đã tát vào nhau trong bản phát hành trước. Chúng mỏng manh, khổng lồ, sao chép / dán wazoo và đánh đố với những lời tuyên bố về giấc ngủ khiến chúng chạy rất chậm và không thể đoán trước. Lời khuyên của tôi cho nhóm của bạn: ĐỪNG LÀM TDD ... chưa.

Tôi không biết tình huống của bạn là gì vì bạn đã đề cập rằng bạn đã ở với công ty chỉ 6 tháng và bạn là một nhà thầu. Mục tiêu dài hạn của bạn là ở lại với công ty này hay hợp đồng sẽ hết hạn? Tôi đang hỏi bởi vì ngay cả khi bạn làm điều gì đó, có thể sẽ mất khá nhiều thời gian để thực sự thấy kết quả.

Ngoài ra khi bạn tham gia vào một nhóm, thường sẽ mất thời gian trước khi bạn có đủ uy tín và sự tôn trọng của nhóm của bạn, nơi họ (nhà phát triển và quản lý) thậm chí sẽ xem xét bất cứ điều gì bạn đề xuất. Theo kinh nghiệm của tôi, sẽ hữu ích nếu bạn dập tắt được vài đám cháy và chứng minh rằng bạn có những kỹ năng và kiến ​​thức mà người khác có thể phụ thuộc. Không chắc 6 tháng là đủ. Rất thường xuyên một người mới, tham vọng sẽ tham gia nhóm, sau đó tạo một bài đăng ở đây để hỏi làm thế nào họ có thể thay đổi thế giới. Thực tế đáng buồn là họ chỉ đơn giản là không thể.

Vì vậy, giả sử bạn có sự tôn trọng và chú ý của nhóm của bạn. Giờ thì sao?

Đầu tiên, cả quản lý và nhà phát triển cần nhận thức được rằng có vấn đề. Các biện pháp quản lý kết quả về mặt công việc được giao. Nếu họ hài lòng với số lượng và chất lượng tính năng hiện tại, thì thực tế đáng buồn là họ sẽ không lắng nghe. Như những người khác đã chỉ ra, nếu không có sự hỗ trợ của ban quản lý, sẽ rất khó để đưa ra bất kỳ loại thay đổi nào.

Khi bạn nhận được hỗ trợ quản lý, bước tiếp theo là đào sâu và xác định nguyên nhân gốc rễ tại sao nhóm vận hành theo cách đó. Chủ đề tiếp theo này là một cái gì đó là một nhiệm vụ cá nhân của tôi bây giờ. Cho đến nay, đây là hành trình của tôi:

  1. Một khi bạn có sự hỗ trợ của ban quản lý. Bạn có thể bắt đầu giới thiệu rất nhiều thực tiễn / quy trình được tập trung vào chính mà MainMa đề xuất để trả lời câu hỏi của tôi . Chúng tôi đã thực hiện rất nhiều trong số họ (ngoại trừ lập trình được ghép nối) và bạn chắc chắn thấy được lợi ích. Đánh giá mã đặc biệt giúp tiêu chuẩn hóa về kiểu dáng, tài liệu và cũng cho phép chúng tôi chia sẻ kiến ​​thức / kỹ thuật giữa các nhóm. Mặc dù, các đánh giá mã đã được ra lệnh, nhóm thực sự thích chúng và chúng tôi xem xét mọi phần chức năng được kiểm tra. Tuy nhiên ...
  2. Bạn nhận thấy rằng mã thường được viết vẫn còn quá ghép, thiết kế xấu hoặc hoàn toàn thiếu. Đánh giá mã bắt được một số trong số đó, nhưng chỉ có rất nhiều bạn có thể viết lại. Tại sao thiết kế xấu ở nơi đầu tiên? - Rất nhiều nhà phát triển chưa bao giờ được giới thiệu về các thực tiễn tốt và không bao giờ được chính thức giảng dạy về 3M ngay từ đầu. Rất nhiều người "đơn giản mã hóa" bất cứ nhiệm vụ nào họ được giao.
  3. Với sự hỗ trợ của ban quản lý, bạn có thể giới thiệu nhiều quy trình hơn, chẳng hạn như thảo luận về thiết kế trước khi bất kỳ mã hóa nào diễn ra. Nhưng bạn chỉ là một người và dường như ngay khi bạn không chú ý, nhóm sẽ quay trở lại với những gì họ đã luôn làm. Tại sao?
  4. Những thói quen hay thói quen tốt hơn có thể được giới thiệu và dạy để bạn không phải thường xuyên theo dõi không? - Hóa ra phần này không dễ như vậy.
  5. Tại sao các thành viên khác trong nhóm không muốn học hỏi và tiếp thu các thực tiễn mới và tại sao họ lại chống lại RẮN hoặc KHÔ khi nó được viết rất nhiều trong tài liệu phương pháp phần mềm hiện đại? Với tất cả những thay đổi tích cực, chúng tôi đã có trong đội của tôi, 2 tuần trước, tôi đã có một cuộc tranh cãi là tôi refactored 2 chức năng mà có giống hệt nhau 15 dòng mã và các nhà phê bình gọi nó là anh hùng, nỗ lực không cần thiết vì không có gì sai với sao chép / dán các chỉ 15 dòng. Tôi hoàn toàn không đồng ý với những quan điểm như vậy nhưng hiện tại chúng tôi đã quyết định đồng ý không đồng ý. -- Thế bây giờ thì thế nào? Bây giờ chúng tôi đã đạt đến chủ đề của bài viết khác của tôi .
  6. Như maple_shaftnikie đã chỉ ra trong câu trả lời của họ (xin lỗi, MainMa , bạn đã nhận được nhiều phiếu bầu nhất, nhưng bạn chậm 5 bước :)), bạn đã đạt đến một giai đoạn mà "quá trình" không còn có thể giúp bạn và không ai trên diễn đàn này có thể cho bạn biết "sửa chữa" là gì. Bước tiếp theo là tiếp cận các cá nhân, có thể từng người một, có thể là một nhóm, có thể cả lúc này hay lúc khác và nói chuyện với họ. Hỏi họ, cái gì hiệu quả và cái gì không. Cách duy nhất để xác định nguyên nhân gốc rễ của những gì thúc đẩy họ bây giờ là nói chuyện riêng với họ và tìm ra điều đó. Là một phần của bước này, gần đây tôi đã gặp một vấn đề nhóm hoàn toàn khác, nhưng tôi nghĩ câu trả lời của Joel ở đây, rất chi tiết và sâu sắc, cũng sẽ áp dụng cho trường hợp này. Tóm lại, trong khi sử dụng quản lý như "dây xích ngắn" là một cách tiếp cận khả thi đối với bất cứ điều gì, chúng ta cần nhớ rằng chúng ta đang đối phó với con người để thực sự hiểu động cơ chúng ta phải vượt qua phân tâm học hơn là quản lý thuần túy hoặc lãnh đạo kỹ thuật.
  7. Vì vậy, bây giờ bạn đang nói chuyện với đồng đội của bạn? Bạn hỏi họ điều gì? Tôi không chắc về phần tiếp theo này vì tôi chưa bao giờ đến đây. Đây là một kịch bản có thể xảy ra: Q: Tại sao không có RẮN? A: Tôi không cần nó. Q: Nó có thể giúp. A: Tôi vẫn ổn. - bằng cách nào đó bạn cần tạo ra một loạt âm thanh rời khỏi miệng và khiến người nghe nhận ra rằng mọi thứ có thể tốt hơn nếu họ cho bất cứ điều gì bạn đang bán hàng một cơ hội. Nếu bạn thất bại ở đây, họ sẽ không bao giờ bị thuyết phục rằng bất cứ "quy trình" nào khiến họ thực sự có giá trị. Mặt khác, nếu bạn vượt qua điểm này, có lẽ bạn sẽ thấy bạn thậm chí không cần "quá trình" nữa.
  8. IMO tận gốc, đồng đội của bạn sẽ không học nếu họ không thấy có gì sai với thói quen / thói quen hiện tại của họ. Vì vậy, có lẽ bước tiếp theo trong tất cả những điều này là tìm cách minh họa, làm nổi bật các vấn đề và làm cho chúng rõ ràng. Rốt cuộc, chúng tôi không viết mã có thể đọc được, sử dụng các nguyên tắc RẮN / DRY hoặc duy trì tài liệu chỉ vì nó mang lại cho chúng tôi cảm giác ấm áp và mờ nhạt. Chúng tôi làm điều đó bởi vì nó tạo ra mã chất lượng tốt hơn và thẳng thắn làm cho chúng tôi mã nhanh hơn. Điều đó có thể được đo? Có lẽ đây là nơi mà số liệu phần mềm đi vào?
  9. Đây là một ý tưởng điên rồ và tôi không biết nó có thực sự hoạt động hay không (nó có thể là một thông lệ công nghiệp tiêu chuẩn, hoặc nó có thể hoàn toàn không hợp lệ. Tôi chỉ thực hiện nó trong 24 giờ qua), nhưng tôi rất muốn mang nó đến bàn ngay khi năm tới bắt đầu:
    • Chống lại ý kiến ​​của nhiều người khác , giới thiệu ý tưởng của Tác giả / Chủ sở hữu cho tất cả các tệp nguồn. Như Lập trình viên thực dụng cho thấy điều này sẽ mang lại ý thức về quyền sở hữu và trách nhiệm cho một người duy nhất sẽ chịu trách nhiệm cho một đoạn mã nguồn. Điều đó không có nghĩa là những người khác không thể sửa đổi mã, tất cả chúng ta đều làm việc theo nhóm, nhưng vào cuối ngày, người sở hữu mã có trách nhiệm xem xét các thay đổi.
    • Tạo trình kích hoạt kho lưu trữ nguồn theo dõi tất cả các đăng ký và đặc biệt tìm kiếm các bản sửa lỗi. Làm cho nó trở thành một quy trình để mọi sửa lỗi đều có một định danh tham chiếu ngay trước phần mô tả đăng ký. Bây giờ hãy viết một tập lệnh phân tích danh sách các tệp đã được thay đổi và loại bỏ "Tác giả" khỏi khối nhận xét tiêu đề tệp. Tạo cơ sở dữ liệu SQL theo dõi # lỗi được kiểm tra trên mỗi tệp / mỗi dự án / mỗi tác giả.
    • Khi bạn có đủ số liệu thống kê, hy vọng bạn sẽ nhận thấy rằng mã của bạn có ít lỗi / thay đổi hơn so với một số mã khác. Đây là dữ liệu cứng bạn có thể sử dụng. Nếu một dự án duy nhất có tỷ lệ lỗi trung bình cao hơn đáng kể, hãy đưa nó lên làm ứng cử viên cho nỗ lực làm sạch / tái cấu trúc tiếp theo để trả lại một số khoản nợ kỹ thuật.
    • Nếu một dự án hoặc tệp có tỷ lệ lỗi trung bình cao hơn đáng kể và nó có một chủ sở hữu, hãy nói chuyện trực tiếp với người đó. Hỏi họ, rất lịch sự, không đối đầu những gì họ có thể làm để giải quyết vấn đề này. Vì họ là chủ sở hữu, họ nên thúc đẩy thay đổi, nhưng cung cấp bất kỳ và tất cả sự giúp đỡ từ phía bạn. Hy vọng, chủ sở hữu sẽ theo dõi rất nhiều nguyên nhân dẫn đến mã spaghetti của riêng họ và ngay khi họ yêu cầu trợ giúp, đó là khi bạn hành động và đặt ra một số RẮN.

1
Điều này thật tuyệt vời, cảm ơn bạn. Tôi đã thử trước một số kỹ thuật này (Jen *, tại sao bạn không thay đổi định dạng mã của mình thành x, y, z, phải mất 2 phút) trước đó và tôi luôn nhận được dịch vụ môi và không có gì xảy ra. Ngoài ra, một trong những đồng nghiệp của tôi rõ ràng mạnh hơn người kia; trên dòng nơi cô ấy có thể rất tốt, nhưng không thực hiện được. Tôi nghe cô ấy nói về chất lượng mã mọi lúc, nhưng cũng sắp xếp lại thành một cái vỏ khi đến lúc phải hành động: "chúng tôi chỉ có 5 tuần để phát hành, tôi không muốn cấu trúc lại bất cứ điều gì ngay bây giờ". Và tôi facepalm. * tên đã thay đổi
hvgotcodes

nếu bạn không tập trung vào trình định dạng mã (hoặc bất cứ điều gì cụ thể khác). Thay vào đó chỉ nói chuyện với Jen và đưa ra một số vấn đề như các vấn đề của nhóm (ví dụ: "Tôi nhận thấy một số mã của chúng tôi không dễ đọc, tôi nghĩ rằng điều đó khiến chúng tôi mắc phải những sai lầm có thể tránh được"). Đừng đề xuất bất cứ điều gì, nhưng hãy để Jen chỉ nghĩ về các giải pháp có thể. Ngoài ra tôi thấy rằng nó hữu ích khi bạn sao lưu các đề xuất của bạn với các nguồn. Thay vì nói: "Tôi nghĩ rằng chúng ta cần phải làm việc để đặt tên biến tốt hơn", nếu bạn nói, "Tôi đã đọc Clean Code và tôi nghĩ rằng tác giả có một điểm rất tốt, hãy thử ..." Để tranh luận ...
DXM

... Với điều đó, Jen sẽ phải tìm một cuốn sách gợi ý việc đặt tên không quan trọng. Và tôi biết ý của bạn về việc mọi người quay trở lại, đó là điều tự nhiên và lý do là khi bạn bị áp lực, bạn quay trở lại vùng thoải mái của mình để giải phóng nỗ lực cho những việc "quan trọng". Ngay cả khi bạn đưa nhóm của mình lên tàu với việc cải thiện chất lượng và học tập, sẽ có một vài bản phát hành trước khi họ bắt đầu trở lại thói quen tốt. Chỉ cần kiên nhẫn, chọn các trận đánh của bạn và để một số thứ trượt
DXM

2

Tôi đề nghị bạn nên nói chuyện với người quản lý của mình về vấn đề này, nhưng anh ấy gần như chắc chắn sẽ không muốn xem xét mỗi lần đăng ký.

Thay vào đó, tôi khuyên bạn nên đề xuất một bộ các bài kiểm tra đơn vị / hồi quy, được nối vào SVN và chạy cho mỗi lần đăng ký. Điều đó ít nhất sẽ giúp bạn tránh các bản dựng bị hỏng. Bạn có thể dần dần đề xuất các thực hành tốt nhất khác.

Nếu anh ta tỏ ra hoàn toàn không thể chấp nhận được, có lẽ bạn nên đi qua đầu anh ta. Nếu bạn quyết định làm điều đó, bạn sẽ cần phải mang trò chơi tốt nhất của bạn. Về cơ bản, bạn sẽ được quản lý để được tuyển dụng ở cấp cao hơn nếu bạn làm điều đó.


1
tôi đã không đề cập rằng đây là công việc phía khách hàng. kiểm tra chức năng tự động là đường ống, nhưng chúng không phải là kiểm tra đơn vị nên phản hồi sẽ là hàng ngày, không phải ngay lập tức.
hvgotcodes

2
@hvgotcodes: Tôi không thấy lý do tại sao điều đó ngăn bạn tạo các bài kiểm tra đơn vị để chạy trên mỗi lần đăng ký.
Marcin
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.