Phải làm gì khi đồng nghiệp làm việc của bạn không hiểu thiết kế đang cố gắng duy trì [đóng]


8

Một dự án phần mềm mà tôi đang làm việc liên quan đến tôi và một lập trình viên khác. Dự án liên quan đến một phụ trợ động cơ với một giao diện người dùng MVC. Ban đầu tôi đã thực hiện rất nhiều công việc trong dự án và do đó thiết lập một số phương pháp thiết kế đơn giản chủ yếu xoay quanh sự trừu tượng hóa và chiến lược mẫu.

Trong một thời gian dài, tôi đã tắt phần phụ trợ động cơ và làm việc trên trang web. Tuy nhiên tôi vẫn duy trì mối quan tâm đến động cơ vì tôi được thông báo rằng tôi có thể sẽ quay lại với nó vào một lúc nào đó.

Dự án đang trong một thời hạn rất chặt chẽ, vì vậy tất cả chúng ta đang gấp rút thực hiện để hoàn thành nó ở cả mặt trước và mặt sau.

Tôi không coi mình là một lập trình viên tuyệt vời và vì vậy tôi không bao giờ thử và áp dụng bất kỳ thiết kế hay bộ phương pháp cụ thể nào cho mọi người vì tôi không luôn chắc chắn rằng mình đúng và muốn người khác đưa ra ý kiến ​​của mình để thử và đưa ra giải pháp tốt hơn Tuy nhiên tôi đã nhận thấy những thay đổi được thực hiện đối với mã công cụ này thực sự bắt đầu làm phiền tôi. Khi tôi đối mặt với nhà phát triển để đề nghị anh ta thực hiện công việc theo cách khác, anh ta nói rằng anh ta không nhìn thấy điểm vì dường như có rất ít lợi ích khi xem xét thời hạn chặt chẽ.

Tôi đã phải cố gắng và giải thích rằng haack anh ấy đã đưa vào có thể có nghĩa là phát triển hơn nữa sau khi phát hành và tôi đã không nghĩ rằng thật công bằng khi bắt người khác chùn bước khi chúng tôi có thể sửa chữa nó ngay bây giờ. Tôi đã dành khoảng 30 phút để trải qua những gì tôi đã làm và cuối cùng, anh ấy yêu cầu tôi viết mã khá nhiều để anh ấy có thể sao chép nó.

Cơ sở của những gì tôi đã thiết lập ban đầu là:

  • Một lớp trừu tượng x
  • Một lớp nhà máy trừu tượng để tạo các thể hiện cụ thể của x

Điều đã xảy ra là anh ta đã đặt một vài câu lệnh if có thể dễ dàng được đặt thành phương thức ảo / trừu tượng trên lớp trừu tượng và sau đó được thực hiện theo đó là thay đổi mới tuân theo nguyên tắc tương tự của các phương thức khác trên lớp trừu tượng.

Điều này có vẻ tầm thường đối với tôi, tuy nhiên anh ta thậm chí không thể nắm bắt được điều này ngay cả khi tôi chỉ cho anh ta các lớp học liên quan.

Bây giờ câu hỏi của tôi là:

  1. Đây có phải là không công bằng khi cho rằng anh ta nên nắm bắt khái niệm này. Tôi nhận ra rằng chúng tôi đang trong thời hạn chặt chẽ nhưng tôi nghĩ đó là chuyện nhỏ. Lập trình viên được cho là ít nhất là một trình độ trung cấp.
  2. Điều này đã xảy ra ở một số nơi và tôi đã liên tục cố gắng để anh ấy thay đổi nhưng dường như anh ấy không làm thế. Tôi có nên bỏ qua nó?
  3. Tôi có nên nêu vấn đề này ở nơi khác không, hay chỉ là vấn đề và khi tôi quay lại dự án, hãy thay đổi tất cả những điều này.

Phần dự án của anh ấy sẽ không được hoàn thành, đó là lý do tại sao tôi sẽ phải quay lại và giúp anh ấy ra ngoài. Tôi thực sự không muốn, vì anh ấy đã thực hiện một dự án không tuyệt vời, nhưng kiến ​​trúc ok và thực sự đưa vào rất nhiều mã lộn xộn mà thường không tuân theo những gì đang cố gắng đạt được.

Nếu câu hỏi quá mơ hồ hoặc khó hiểu, xin vui lòng cho tôi biết và tôi sẽ thử và chỉnh sửa cho phù hợp.

EDITED: Dự án dự kiến ​​sẽ tiếp tục sau thời hạn ban đầu vì đã có kế hoạch theo dõi và công việc mà chúng tôi không phù hợp và đã được đồng ý thực hiện sau đó.


Bạn không đơn độc ... Đôi khi tôi muốn chia sẻ một thiết kế mới mà tôi đã thấy và cuối cùng tôi phải giải thích nó theo thuật ngữ của giáo dân ... Không còn thú vị nữa.
wleao

Tôi sẽ không phiền nếu anh ta là một lập trình viên cơ sở nhưng anh ta đã được trao một phần rất quan trọng của dự án vì anh ta được cho là một trình độ trung cấp. Tôi đã cố gắng thảo luận nhiều lần về thiết kế, tại sao chúng tôi lại làm gì đó nhưng anh ấy chỉ nhìn tôi chằm chằm. Chỉ không chắc chắn những gì tôi có thể làm để tiến hành từ đây thực sự.
dreza

Điều này có ảnh hưởng đến công việc của bạn không? Kết quả của dự án? Dự án này có một khách hàng? Một ông chủ? Nếu câu trả lời cho tất cả những câu hỏi đó là Có Có Có Có ... Sau đó, bạn nên bắt đầu nghĩ đến việc thảo luận với đồng nghiệp và sếp của bạn.
wleao

4
Tôi đang bỏ phiếu để đóng câu hỏi này ngoài chủ đề vì không phải về lập trình, mà là về việc tương tác với mọi người ở nơi làm việc.
Ixrec

1
Tôi sẽ đi với gia súc ... nhưng tôi nghĩ nơi làm việc. Tôi sẽ xem xét việc thực hành tồi đó.
James Snell

Câu trả lời:


9

Từ việc giám sát có thể lên tới 200 nhà phát triển trong 25 năm qua, tôi cho rằng - tỷ lệ các nhà phát triển thoải mái về mặt trực quan với loại trừu tượng thiết kế mà bạn đang nói đến - giống như một phần ba. Cách tiếp cận của tôi đã phát triển từ việc mong đợi khắc phục điều này bằng huấn luyện, đào tạo và khuyến khích, vẫn tiếp tục làm việc huấn luyện, v.v. - nhưng nhận ra rằng sự thoải mái này có một phẩm chất bẩm sinh và bạn thường không thể thay đổi nó. Bạn hỏi nó có công bằng không. Tôi nghĩ rằng một chút không công bằng là để quản lý của bạn mong đợi một thành viên nhóm phát triển chịu trách nhiệm về sự căng thẳng này và tác động của nó. Nếu bạn có một người lãnh đạo xung quanh - hãy thử giải thích sự căng thẳng cho họ theo thuật ngữ CỦA HỌ không phải của bạn. Đó không phải là về nhà phát triển khác - đó là về hiệu quả, tác động và rủi ro trong tương lai = điểm mấu chốt và do đó có trách nhiệm quản lý rõ ràng. Săn lùng các giải pháp tổ chức khai thác các kỹ năng liên quan của bạn. Bạn có thể đảm nhận công việc hướng dẫn thiết kế nhiều hơn, và anh chàng kia làm nhiều việc hoàn thiện hơn. Đừng cho rằng tất cả các nhà phát triển sẽ không muốn vai trò này - nhiều nhà phát triển thích hoàn thiện công cụ để làm hài lòng khách hàng nhanh chóng - và rất biết ơn về một môi trường thiết kế chất lượng được cung cấp bởi người khác.


Chúc mừng pete. Tôi chỉ giả định rằng tất cả các nhà phát triển sẽ muốn quan tâm đến thiết kế và khái niệm và tái cấu trúc để làm cho một cái gì đó tốt hơn, v.v ... Tôi đoán tôi phải học rằng có tất cả các loại ngoài kia và đó là vấn đề tìm ra sự phù hợp cho từng loại và xử lý cái đó.
dreza

Tôi sẽ cho bạn một + cho câu cuối cùng nếu tôi có thể.
mattnz

4

Đôi khi nó không phải là khái niệm mà là thời gian để mò mẫm nó. Mọi người không nhận được mọi thứ khi được ai đó giải thích nhanh chóng với họ, nhưng hãy cho họ thời gian để đi tìm họ và sau đó họ sẽ nhận được. Đôi khi phải mất một ít thời gian để khái niệm thr chìm vào.

Tôi hiểu thời hạn rất chặt chẽ và kiến ​​thức còn hạn chế, có thể có nhiều tác động hơn bạn muốn, nhưng trong trường hợp này (và tôi đưa ra giả định ở đây), bạn đã chỉ cho anh ấy một tài liệu mẫu thiết kế nhà máy , hay bạn chỉ cần anh ấy hiểu mã của bạn bằng cách vẫy nó dưới mũi anh ấy hét lên "bạn đừng hiểu nó, bạn chỉ không nhận được nó" :)

Tôi thậm chí có thể đã làm điều tương tự với chính mình - cho mọi người xem mã, mong họ hiểu ngay lập tức, thất vọng khi họ nhìn trống rỗng, phóng to nó trong một nỗ lực vô ích để làm cho họ hiểu, khó chịu khi họ thậm chí còn bối rối hơn, sau đó hoặc cùi chỏ họ ra khỏi đường và tự làm điều đó hoặc được yêu cầu ngồi xuống và tự làm điều đó nếu tôi quá thông minh. Đó là tất cả một phản ứng dễ hiểu đối với những nỗ lực kém của tôi với tư cách là một giáo viên.


Công bằng mà nói, đó là những gì tôi đã làm. Tôi có lẽ đã đưa ra giả định rằng điều này sẽ dễ dàng để lấy. Có lẽ sẽ đi qua một vài trong số này với anh ta và xem liệu anh ta có sẵn sàng đọc về nó không
dreza

3

Các lớp học trừu tượng, các nhà máy sản xuất lớp, đừng hiểu sai ý tôi, nhưng nghe như một quả pháo để giết một con chim. Các mẫu có để giải quyết vấn đề không tạo ra chúng. Bạn thừa nhận rằng dự án là 2 người dự án.

Tuy nhiên, điều mà đồng nghiệp của bạn đang làm sai là anh ta không tuân theo các hướng dẫn. Nó sẽ gây ra một số lộn xộn hạ lưu. Nếu dự án được trừu tượng hóa bằng mọi cách, thì anh ta nên cố gắng làm theo.


Tôi đoán đó là một dự án hai người. Tôi đang làm việc trên web ui với một người khác nên tôi đoán tất cả chỉ có 3 người, nhưng người đó chỉ là hai chúng tôi.
dreza

@dreza: Dù sao đi nữa, hãy cố gắng tìm ra những lý lẽ tốt tại sao dự án được thực hiện như thế nào nó được thực hiện. Cố gắng đưa ra ý tưởng rằng tính nhất quán và kiến ​​trúc không phân chia sẽ giúp bảo trì và mở rộng. Hãy cố gắng nuôi những ý tưởng này cho đồng nghiệp của bạn. Ngoài ra, có thể anh ta gặp vấn đề trong việc nắm bắt một số khái niệm, trong trường hợp đó, hãy cố gắng tìm các ví dụ đơn giản, cụ thể cho thấy bạn có thể thực sự đạt được điều gì bằng cách tiếp cận bạn đã chọn. Bạn phải chứng minh rằng công việc làm thêm không được thực hiện một cách vô ích để khiến đồng nghiệp của bạn chấp nhận nó mà không gặp phải sự kháng cự.
Coder

chúc mừng coder. Tôi đã nghĩ rằng có lẽ tôi đã không truyền đạt đủ lợi ích nhưng đấu tranh để đưa ra một điều đơn giản hơn là những gì tôi đang làm. Sẽ tiếp tục làm việc với nó mặc dù
dreza

1

Bạn đã không muốn ép buộc anh ta ngay từ đầu, nhưng bạn có thể đã có một cuộc thảo luận ngắn về một số điều bạn đã làm. Trong thời gian hạn chế, tôi nghi ngờ anh ta sẽ có thể nắm bắt được khái niệm của bạn đủ để có thể thực hiện nó nhanh như 'hack' của anh ta. Bạn muốn anh ấy sửa chữa mọi thứ ngay bây giờ để ngăn người khác / bạn phải sửa chúng sau, nhưng dự án sẽ không được thực hiện đúng hạn. Anh ta không hiểu những gì bạn đang làm hoặc cảm thấy sẽ mất nhiều thời gian và không đáng để mạo hiểm.

Hãy để nó được biết khi dự án có thể được hoàn thành và gây lo ngại về những hạn chế này trong tương lai và sự cần thiết phải có thêm thời gian. Bạn sẽ gặp một số khó khăn khi khiến mọi người thấy nó theo cách của bạn nếu khách hàng hài lòng. Nó có thể không đúng, nhưng đó là thực tế.


Tôi đã nghĩ rằng tôi sẽ nêu ra những mối quan tâm này sau khi thực tế, nhưng nghĩ rằng điều này là rất nhỏ tôi có thể thử và giải thích nó cho anh ta và anh ta sẽ làm điều đó. Không nhận ra rằng tạo ra một phương thức trừu tượng và ghi đè lên nó là một nhiệm vụ lập trình phức tạp như vậy.
dreza

@Dreza - Bạn đồng nghiệp này đã làm việc lâu hơn ở công ty này chưa?
Ramhound

Không, tôi đã làm việc lâu hơn 1 tháng. Cả hai chúng tôi đều làm việc cho dự án này vì vậy khi bắt đầu tôi đã cho rằng chúng tôi có vị thế ngang nhau, v.v.
dreza

1

Có lẽ không phải là một vấn đề kỹ thuật, chắc chắn không phải là một vấn đề lập trình. Nghe có vẻ không có gì khác hơn là cuộc tranh luận "lập trình cho tương lai có thể so với thời hạn cuối ngày" truyền thống, đó là một trường hợp cụ thể của "Tôi không thích cách người kia làm công việc của mình, tôi muốn anh ta làm theo cách của tôi ". Xảy ra mỗi ngày ở mọi nơi làm việc với hơn 1 nhân viên.

Kỹ năng quản lý và nhân viên bán hàng của bạn sẽ quan trọng hơn bất kỳ siêu kỹ thuật nào trong thiết kế của bạn nếu bạn muốn "chiến thắng" cái này.

Tôi khuyên bạn nên đọc những cuốn sách như "Làm thế nào để giành được lửa và gây ảnh hưởng đến mọi người" và "Bạn có màu gì" và những cuốn sách kỹ năng của người khác.


Hầu hết các thực tiễn được đưa ra trong câu hỏi không phải là sự thay thế chậm hơn so với những gì tồn tại ngày nay. Điều này chủ yếu là vấn đề đặt mã ở đúng nơi, không phải ở một radom. Vì vậy, đây không phải là «lập trình cho tương lai có thể so với thời hạn cuộc họp ngày hôm nay». Dù sao, đúng về cuốn sách kỹ năng con người.
deadalnix
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.