Làm thế nào để thuyết phục đồng đội của tôi tuân theo một số quy tắc cơ bản

Tôi có một vấn đề với các đồng đội của tôi. Câu chuyện dài: Chúng tôi là ba sinh viên làm việc tại một dự án cho một cuộc thi. Dự án bao gồm 2 ứng dụng riêng biệt: một cho Windows (mà tôi phát triển) và một cho Android (các đồng nghiệp của tôi chịu trách nhiệm phát triển nó). Các cơ sở mã của chúng tôi sẽ không bao giờ giao nhau, các ứng dụng sẽ giao tiếp thông qua các công cụ của bên thứ ba.

Vấn đề như sau: Tôi có một số kinh nghiệm làm việc trong các nhóm khi tôi thực tập tại một công ty lớn vào năm ngoái và tôi cố gắng thực thi một số tiêu chuẩn mã hóa cho mã của chúng tôi. Tôi cũng thiết lập một kho lưu trữ git / wiki / phần mềm cộng tác mà chúng ta có thể sử dụng để đẩy mã / viết ý tưởng, giao thức tài liệu, nhưng có vẻ như tôi là người duy nhất sử dụng các công cụ này.

Tôi đã cố gắng nói với họ rằng viết mã chất lượng và ghi lại từng bước sẽ có lợi cho chúng ta về lâu dài, nhưng dường như họ không thấy được lợi thế của nó. Ngoài ra tôi đã suy nghĩ để thêm một số thử nghiệm tích hợp nhưng từ những gì tôi có thể thấy, miễn là họ không sử dụng các công cụ hiện tại để làm cho cuộc sống của họ dễ dàng hơn, tôi không nghĩ rằng tôi có thể thuyết phục họ về tính hữu ích của các thử nghiệm tích hợp.

Hầu hết các mã của đồng nghiệp cư trú trên máy tính của họ, họ không chia sẻ cơ sở mã chung và như tôi phát hiện ra, họ đã tích hợp các phần của họ bằng cách gặp gỡ và chia sẻ mã qua thẻ nhớ USB.

Câu hỏi của tôi là: tôi có quá khắc nghiệt về vấn đề này không? Tôi có thực thi một số quy tắc vô lý? Hãy nhớ rằng đây là một dự án nhỏ, các yêu cầu rất rõ ràng (tôi đã tạo tài liệu chỉ định các ứng dụng nên làm gì), ba nhà phát triển lành nghề có thể làm điều này trong 3-4 ngày, vì vậy họ có thể không thấy sự phức tạp thêm của chất lượng viết mã miễn là phương thức hiện tại của họ chỉ hoạt động.

Có cách nào để tôi có thể chỉ cho họ lợi ích của việc viết mã, sử dụng git không?

Câu hỏi của tôi là: tôi có quá khắc nghiệt về vấn đề này không?

Bạn có thể dẫn một con ngựa xuống nước, nhưng bạn không thể bắt nó uống.

Thật khó để nói liệu bạn có "quá khắc nghiệt" hay không, nhưng có thể không thực tế khi mong đợi các đồng đội của bạn chấp nhận tất cả các cơ sở hạ tầng mà bạn hy vọng. Và thực sự, nếu nhóm làm việc tốt với nhau, sử dụng wiki để liên lạc giữa ba người có lẽ là quá mức cần thiết.

Thu nhỏ lại mong đợi của bạn và tìm cách để đạt được một số mục tiêu của bạn mà không yêu cầu họ bắt đầu sử dụng các công cụ mà họ không biết. Nếu họ không biết cách sử dụng git, có lẽ họ sẽ không nhận được nhiều lợi ích từ nó trong mọi trường hợp. Tuy nhiên, bạn vẫn muốn đảm bảo rằng tất cả mã được sao lưu trong trường hợp hỏng ổ cứng hoặc thảm họa khác, vì vậy hãy yêu cầu họ sao chép định kỳ thư mục dự án của họ sang Google Drive, Dropbox hoặc dịch vụ chia sẻ tệp trực tuyến tương tự. Hãy chắc chắn rằng bạn làm như vậy.

Thái độ của tôi là nếu bạn có thể học cách làm những điều này trong các dự án nhỏ, bạn sẽ được chuẩn bị khi các dự án lớn xuất hiện.

Nếu họ tuân theo thực tiễn phát triển tốt với dự án này, họ sẽ có mã để giới thiệu cho các nhà tuyển dụng trong tương lai và họ sẽ có kinh nghiệm làm cho họ có giá trị như nhân viên.

Nếu bạn muốn có thêm tài liệu để thuyết phục họ, tôi sẽ tham khảo Lập trình viên thực dụng hoặc Hoàn thành mã .

Mặt khác, xem xét cắt giảm một số chùng. Nếu dự án là một bằng chứng về khái niệm đang bị cấm ngay sau cuộc thi, thì bạn nên xem xét chỉ để họ làm theo ý mình. Họ có thể đang vật lộn chỉ để viết mã ở nơi đầu tiên, mà không có chi phí tinh thần của các thực hành tốt.

Tôi sợ các quy tắc bạn mô tả không cơ bản chút nào.

Nhiệm vụ đơn giản nhất IMO là thuyết phục đồng đội của bạn sử dụng một số tiêu chuẩn mã hóa. Và một cách đơn giản để đạt được điều này là chỉ cho họ đoạn mã giống nhau một khi được định dạng tốt và sau đó có kiểu dáng kém, yêu cầu họ đọc mã, hiểu những gì nó làm và để họ tự phán đoán.

Điều gì đến với việc sử dụng một kho lưu trữ git, điều này có thể là một nỗi đau cho người mới. Khi tôi làm việc trong một nhóm gồm 3 người trong một dự án Android, ban đầu chúng tôi gặp nhiều rắc rối với hệ thống kiểm soát phiên bản của chúng tôi. Vì vậy, tôi mong các đồng đội của bạn cũng sẽ gặp rắc rối.

Bạn đã đề cập rằng sẽ mất 3-4 ngày để nhà phát triển có kinh nghiệm hoàn thành dự án (tôi cho rằng điều đó sẽ khiến nhóm của bạn mất gấp 2-3 lần). Đây là một khoảng thời gian rất ngắn, do đó, lập luận rằng sử dụng các công cụ mới sẽ giúp ích về lâu dài đơn giản là không hoạt động.

Những gì bạn có thể làm là tạo ra các bản demo ngắn và đơn giản để hiển thị cách các công cụ đó được sử dụng. Bao gồm các chức năng cơ bản nhất lúc đầu, ngồi bên cạnh họ và giúp họ sử dụng các công cụ. Hãy chuẩn bị để thực hiện tất cả các tác vụ như cấu hình git, tạo cấu trúc trang wiki, v.v.

Chỉnh sửa : Trả lời nhận xét, tôi nghĩ rằng việc thiết lập các nhiệm vụ, ước tính và thời hạn rõ ràng và theo dõi thời gian sử dụng là quan trọng hơn so với sử dụng git hoặc các công cụ tương tự. Nếu bạn dự định làm việc trên ứng dụng sau này, điều rất quan trọng là phải theo dõi những gì đã được thực hiện và mỗi tính năng mất bao lâu. Vì vậy, tôi khuyên bạn nên bắt đầu từ quản lý tác vụ, sau đó tiến hành các công cụ bạn muốn sử dụng.

Tôi thực sự thích những suy nghĩ của Joel Spolsky về nó, khi anh ấy trình bày trong Bắt đầu mọi thứ khi bạn chỉ là một người lẩm cẩm . Để tóm tắt:

1. Chỉ cần làm điều đó - Viết tệp tạo tệp , tạo máy chủ xây dựng hàng ngày, v.v.
2. Không ai sử dụng kiểm soát nguồn hoặc cơ sở dữ liệu lỗi? Bắt đầu sử dụng chúng cho mình. Nếu ai đó báo cáo lỗi chống lại công việc của bạn, hãy yêu cầu họ lịch sự sử dụng cơ sở dữ liệu lỗi để báo cáo lỗi cho bạn để bạn có thể theo dõi chúng; nếu không bạn sẽ không thể giữ chúng thẳng trong đầu và sửa chúng. Trong bất kỳ dự án không tầm thường nào, sẽ có một tình huống chỉ có thể giải quyết được với kiểm soát nguồn: tự mình sử dụng kiểm soát nguồn cho mã và đột nhập vào để cứu ngày khi tình huống đó xảy ra. Một khi điều này xảy ra một vài lần, họ sẽ bị thuyết phục
3. Tạo một túi xuất sắc - Hãy làm những điều đúng đắn cho bản thân: suy đoán, lên lịch, v.v. Vì đây không giống như một dự án công việc, nên có vẻ như bạn không thể thực hiện lời khuyên này bằng mọi cách, vì bạn không thể thuê thành viên nhóm mới tin vào tin nhắn của bạn
4. Trở nên vô giá - Chứng tỏ rằng bạn là người đóng góp rất lớn để củng cố tầm ảnh hưởng của bạn trong nhóm. Mặt khác, bạn có nguy cơ trở thành người được biết đến như một người coi trọng quá trình và công cụ hơn kết quả

Tài liệu, Wiki, phần mềm phiên bản, phương pháp, vv là những kinh nghiệm và bài học kinh nghiệm theo thời gian; làm việc của một số dự án và có thể qua một số đội. Và nó thường gắn bó với những người đã làm việc hoặc những người coi trọng ngành công nghiệp của họ. Họ là sinh viên, vì vậy lợi ích của họ có lẽ bị hạn chế trong những gì xảy ra trong tương lai. :)

Nhưng để thử và trả lời câu hỏi của bạn:

Nếu bạn ở trong một nhóm với họ, bạn sẽ cần phải áp dụng những gì bạn nghĩ là quan trọng theo cách có lợi cho lợi ích của họ. Ví dụ: họ có nên phàn nàn về việc mã của họ bị phá vỡ nhiều khi usb chia sẻ nó không? Sau đó, có lẽ cung cấp cho họ một cách đơn giản (không phức tạp) bằng cách sử dụng SVN (chứ không phải git) làm công cụ tạo phiên bản.

Tôi cũng đồng ý với nhận xét từ arnaud.

Bạn đã thấy lợi ích của tất cả các công cụ này khi bạn làm việc với chúng và đó là cách bạn thấy giá trị của chúng và lý do tại sao bạn hiểu cách sử dụng chúng. Nếu đồng đội của bạn không thấy giá trị gia tăng trong cách họ hiện đang làm, thì họ sẽ không áp dụng nó. Và điều đáng buồn là điều này thậm chí còn được tính cho các đội được tạo thành từ những người có bất kỳ mức độ kinh nghiệm nào.

Cách tiếp cận có vấn đề:

1. Cách tiếp cận của bạn không đối xứng. Các thành viên khác trong nhóm của bạn cần thay đổi, nhưng bạn không học được các thực hành tốt của họ. Thực thi các quy tắc trong tình huống như thế này là khó khăn. Cách tiếp cận tốt hơn sẽ là thu thập các quy tắc và thực hành tốt từ tất cả các thành viên của nhóm và sau đó mọi người chỉ cần đọc tài liệu kết quả.

2. Học rất khó. Các quy tắc của người khác chỉ không có ý nghĩa vì các quy tắc đó không có cấu trúc logic mà các lập trình viên của bạn đang mong đợi. Thực thi các quy tắc không có ý nghĩa không phải là hoạt động hữu ích.

3. Mọi người đều học những điều khác nhau. Thật tự nhiên khi các lập trình viên đến từ các nền tảng khác nhau đã học được những điều khác nhau. Điểm mạnh của họ là khác nhau, và phong cách viết mã khác nhau. Các công cụ họ sử dụng là khác nhau. Việc thực thi một bộ quy tắc / công cụ / phong cách sẽ là cơn ác mộng bởi vì những hạn chế đang làm mất đi sức mạnh mà các nhà phát triển đã dành nhiều năm học hỏi.
4. Thay đổi cần có thời gian. Trong khi người phát minh ra các quy tắc bạn thực thi có thời gian khá dễ dàng để tuân theo các quy tắc, mọi người khác đều đau khổ và dành thời gian tìm hiểu các quy tắc mới. Đây là một lý do tại sao mọi người trong nhóm sẽ có thể thay đổi các quy tắc.
5. Chọn công cụ / quy ước mã hóa hoặc phong cách cho cả nhóm là một hoạt động khó khăn . Nó chỉ có thể được thực hiện từ từ theo thời gian, kiểm tra những thứ hoạt động và những gì không hoạt động. Đưa ra một nhóm 2 tuần để bắt đầu tuân theo 50 quy tắc sẽ không hiệu quả.

Tôi đã tìm thấy vấn đề này rất nhiều ở trường đại học. Nhiều người chỉ đơn giản là không sẵn sàng học một cách làm việc khác (và có thể chuyên nghiệp hơn).

Tuy nhiên, nếu bạn có hệ thống và giải thích cách sử dụng hệ thống thì nhiều người sẵn sàng dùng thử. Tôi cũng nghĩ rằng các kho lưu trữ rất dưới các công cụ được sử dụng và mọi người thường sẽ chỉ sử dụng một cái gì đó như dropbox.