Cách tốt nhất để giới thiệu về giới thiệu OOP / OOD cho đội ngũ kỹ sư có kinh nghiệm về C ++


17

Tôi đang tìm kiếm một cách hiệu quả, đó cũng không phải là một sự xúc phạm, để giới thiệu các khái niệm OOP cho các thành viên nhóm hiện có? Đồng đội của tôi không phải là mới đối với các ngôn ngữ OO. Chúng tôi đã làm C ++ / C # trong một thời gian dài nên bản thân công nghệ đã quen thuộc.

Tuy nhiên, tôi nhìn xung quanh và không có nỗ lực truyền tải lớn (chủ yếu dưới dạng đánh giá mã), có vẻ như những gì chúng tôi đang sản xuất là mã C xảy ra trong các lớp. Hầu như không sử dụng nguyên tắc trách nhiệm duy nhất, trừu tượng hóa hoặc cố gắng giảm thiểu khớp nối, chỉ để nêu tên một số. Tôi đã thấy các lớp không có hàm tạo nhưng có bộ nhớ về 0 mỗi khi chúng được khởi tạo.

Nhưng mỗi khi tôi đưa lên OOP, mọi người luôn gật đầu và làm cho có vẻ như họ biết chính xác những gì tôi đang nói. Biết các khái niệm là tốt, nhưng chúng tôi (một số nhiều hơn những người khác) dường như rất khó áp dụng chúng khi nói đến việc cung cấp công việc thực tế.

Đánh giá mã đã rất hữu ích nhưng vấn đề với đánh giá mã là chúng chỉ xảy ra sau khi thực tế đối với một số người có vẻ như chúng tôi đã viết lại (chủ yếu là tái cấu trúc, nhưng vẫn mất nhiều thời gian) mã vừa được viết. Ngoài ra các đánh giá mã chỉ đưa ra phản hồi cho một kỹ sư riêng lẻ, không phải toàn bộ nhóm.

Tôi đang chơi đùa với ý tưởng thực hiện một bài thuyết trình (hoặc một loạt) và cố gắng đưa OOP trở lại cùng với một số ví dụ về mã hiện có có thể được viết tốt hơn và có thể được tái cấu trúc. Tôi có thể sử dụng một số dự án thực sự cũ mà không ai sở hữu nữa nên ít nhất phần đó không phải là vấn đề nhạy cảm. Tuy nhiên, điều này sẽ làm việc? Như tôi đã nói hầu hết mọi người đã thực hiện C ++ trong một thời gian dài vì vậy tôi đoán là a) họ sẽ ngồi đó suy nghĩ tại sao tôi nói với họ những điều họ đã biết hoặc b) họ thực sự coi đó là một sự xúc phạm bởi vì tôi nói với họ rằng họ không biết làm công việc họ đã làm trong nhiều năm chứ không phải hàng thập kỷ.

Có một cách tiếp cận khác sẽ tiếp cận đối tượng rộng hơn so với đánh giá mã, nhưng đồng thời sẽ không cảm thấy giống như một bài giảng trừng phạt?

Tôi không phải là một đứa trẻ mới ra trường, có lý tưởng không tưởng về mã được thiết kế hoàn hảo và tôi không mong đợi điều đó từ bất cứ ai. Lý do tôi viết điều này là vì tôi vừa làm một bài đánh giá về một người thực sự có thiết kế cấp cao đàng hoàng trên giấy. Tuy nhiên, nếu bạn hình ảnh các lớp: A -> B -> C -> D, trong mã B, C và D đều thực hiện gần như cùng một giao diện chung và B / C có một chức năng lót để lớp A hàng đầu hoàn toàn hoạt động tất cả công việc (xuống quản lý bộ nhớ, phân tích chuỗi, đàm phán thiết lập ...) chủ yếu theo 4 phương thức mongo và, đối với tất cả ý định và mục đích, gọi gần như trực tiếp vào D.

Cập nhật: Tôi là người lãnh đạo công nghệ (6 tháng trong vai trò này) và có sự hỗ trợ đầy đủ của người quản lý nhóm. Chúng tôi đang làm việc trên một sản phẩm rất trưởng thành và chi phí bảo trì chắc chắn cho phép họ được biết đến.



3
Bạn có phải là người giám sát hoặc ông chủ của họ theo bất kỳ cách nào? Nếu không, bạn có hỗ trợ của giám đốc kỹ thuật, ông chủ của tất cả các bạn không? Nếu bạn chỉ là một trong số những người và sự phát triển đã ổn định và hiệu quả trong nhiều năm mà không sử dụng các thiết kế OOP sâu thì bạn sẽ tham gia vào một trận chiến khó khăn để thuyết phục các lập trình viên rằng mã làm việc không hoạt động và quản lý mà bạn không lãng phí tiền chi tiêu tốt hơn để tạo mã.
Patrick Hughes

Sau khi tôi thực hiện bài đăng này, các liên kết liên quan đã bật lên nghe có vẻ rất giống tình huống của tôi: lập trình viên.stackexchange.com / questions / 43014 / trên . Tôi lo lắng về chính xác điều tương tự. Vấn đề là nhóm của họ có 2 nhà phát triển và tôi chắc chắn có thể quản lý điều đó bằng các đánh giá mã. Tôi đang tìm kiếm một cách tiếp cận phù hợp với quy mô nhóm của chúng tôi (10+) Tôi chỉ không được giao tiếp với mọi nhà phát triển một cách nhiều như tôi muốn.
DXM

Câu trả lời:


5

Tại sao bạn không phát triển một khóa đào tạo ngắn về các nguyên tắc RẮN và cung cấp cho họ khóa đào tạo này? Nó dường như đã làm việc khá tốt cho tôi trong tổ chức hiện tại của tôi và tôi thấy việc đào tạo ngắn thực sự rất thú vị (cho tất cả mọi người tham gia).

Khi tôi đào tạo, tôi đã dành một chút thời gian để tìm kiếm các ví dụ "xấu" bệnh hoạn trong mã hiện có (của các dự án khác nhau) và tái cấu trúc chúng trong bài thuyết trình, từng bước, sử dụng các nguyên tắc. Điều này đã chứng minh rằng

  1. Không khó để thực hiện các phép tái cấu trúc này
  2. Nó không mất nhiều thời gian
  3. Kết quả cuối cùng (được chọn cẩn thận ;-)) rõ ràng tốt hơn mã gốc.

5

Đánh giá mã đã rất hữu ích nhưng vấn đề với đánh giá mã là chúng chỉ xảy ra sau khi thực tế.

Trong một dự án, chúng tôi đã đánh giá thiết kế.

15 phút. Ở bảng trắng. Nói qua thiết kế trước khi mã hóa.

Phần quan trọng nhất là lên lịch đánh giá thiết kế trước khi thực hiện bất kỳ công việc nào.

Chúng tôi cũng đã có "Đánh giá thiết kế quan trọng", đó là một thỏa thuận lớn, đầy mồ hôi. Họ liên quan đến rất nhiều tài liệu và một bài thuyết trình dài. Họ rất khó để lên lịch và hầu như luôn bị đẩy ra cho đến khi mã hóa bắt đầu, giảm giá trị của chúng xuống không.

Đánh giá thiết kế không chính thức - trước khi mã hóa - không áp lực - không có tài liệu - cho phép thảo luận tốt hơn về cách phân công trách nhiệm và cách các đối tượng sẽ cộng tác.


vâng, chúng tôi đã thực hiện đánh giá thiết kế chính xác như bạn đã mô tả chúng. Vấn đề là nhiệm vụ cỡ trung bình. Nếu nhiệm vụ đủ lớn, tôi thường dành thời gian để đưa ra sơ đồ lớp ban đầu, sau đó được nhóm tinh chỉnh. Nếu nhiệm vụ nhỏ, thì thiết kế cấp cao hiện có đã đủ tốt. Tuy nhiên, đối với các tác vụ cỡ trung bình, tôi không có khả năng đặt đủ suy nghĩ vào thiết kế nên quy tắc cơ bản là "sử dụng phán đoán tốt nhất và tuân theo OOP". Nếu tôi tự mình thực hiện các nhiệm vụ này, tôi sẽ bắt đầu với mã hóa và xen kẽ với việc tái cấu trúc liên tục và ...
DXM

... Hãy để mã quyết định thiết kế cuối cùng trông như thế nào. Tuy nhiên, khi tôi để các nhiệm vụ này cho một số thành viên trong nhóm, những gì tôi đôi khi tìm thấy trong phần đánh giá mã là những thứ giống như tôi đã mô tả trong bài viết ban đầu của mình.
DXM

1
@DXM: Cái gì? Bạn đang làm chúng? Hay không làm chúng? Nếu lớn, thì bạn không thực hiện đánh giá thiết kế - bạn đang thiết kế cho người khác - ai học khi bạn thiết kế? Nếu nhỏ, thì bạn không thực hiện đánh giá thiết kế - "thiết kế hiện tại là đủ tốt" - ai sẽ bỏ qua khi bạn bỏ qua thiết kế? Nếu trung bình, bạn không làm thiết kế, và bạn cũng không xem xét thiết kế của họ? Có vẻ như bạn không thực sự đánh giá thiết kế thực tế. Tại sao bạn nói bạn là và sau đó đưa ra ba ví dụ mà bạn không?
S.Lott

@Lott: theo phản ánh về phản hồi của bạn, kết luận duy nhất của tôi là bạn hoàn toàn đúng. Tôi đoán điều tôi nên nói là tôi đã đưa ra ý tưởng chính xác này ít nhất 8 lần và mọi người luôn đồng ý, nhưng vâng, nếu tôi nhìn lại nhịp điệu mà chúng tôi đã giải quyết, chúng tôi thực sự không thực hiện bất kỳ ý tưởng nào. Tôi muốn thảo luận thêm về vấn đề này, nhưng tôi đã bị kỷ luật bởi các mod vì có một cuộc thảo luận trên một trang web hỏi đáp nghiêm ngặt. Chúng ta có thể chuyển sang trò chuyện không? Tôi muốn giải thích tình huống nhiều hơn và có thể chọn bộ não của bạn (hoặc bất kỳ ai khác muốn tham gia) một chút. Chưa bao giờ trò chuyện, bạn biết nó hoạt động như thế nào không?
DXM

@DXM: Trò chuyện tầm thường. Và không quá hữu ích. Nếu bạn có thêm câu hỏi - chi tiết hơn câu hỏi ban đầu này - bạn nên hỏi những câu hỏi chi tiết hơn. Đó là điểm. Trong một vài trường hợp, "thảo luận thêm" lên tới "Tôi không thích câu trả lời của bạn cho câu hỏi của tôi vì những lý do sau đây ..." thật là ngớ ngẩn. Không thích một câu trả lời chỉ đơn giản là không thích một câu trả lời và không yêu cầu bất kỳ cuộc thảo luận nào. Trong một số trường hợp, số lượng thảo luận cho "câu hỏi của tôi không mơ hồ, bạn không thể đọc được." Vô ích, thực sự. Hỏi câu hỏi của bạn. Như câu hỏi.
S.Lott

4

Tôi cho rằng bạn trẻ hơn một số nhà phát triển, nhưng cao hơn trong chuỗi thực phẩm.

Có nguy cơ bị chôn vùi trong downvote, có thể là 'các kỹ sư giàu kinh nghiệm' thực tế đang làm điều đúng đắn - hoặc vì đây là một sản phẩm trưởng thành có thể đã tồn tại trong nhiều thập kỷ, điều từng là điều đúng đắn.

Mã cũ có xu hướng đã được tối ưu hóa để chạy nhanh trên phần cứng của thời gian; trong số những thứ khác, điều này có nghĩa là cắt giảm mức độ kế thừa và tránh các lệnh gọi hàm / phương thức cho các hoạt động tầm thường.

Trình biên dịch đã trở nên thông minh hơn rất nhiều trong những năm qua, vì vậy không phải tất cả mọi thứ trước đây đều đúng - ví dụ, trình biên dịch có thể chọn để thực hiện một hàm nhỏ.

Có lẽ một lộ trình phía trước sẽ là áp dụng một cách tiếp cận khác - yêu cầu các nhà phát triển giải thích làm thế nào / tại sao phương pháp của họ tốt hơn lý thuyết bạn được dạy - và thành thật về nó.


0

Sẽ thúc đẩy các thử nghiệm đơn vị với độ bao phủ 100% chi nhánh của từng phương thức mới / thay đổi sẽ không dẫn đến giảm thiểu khớp nối giữa các phương thức.


UT là một ý tưởng tốt, nhưng tôi không tin rằng điều này sẽ đạt được kết quả mong muốn. Bên cạnh đó, một trong những nguyên tắc cơ bản của OO là việc ghép giữa các hàm là không thể tránh khỏi, vì vậy tốt hơn hết bạn nên thực hiện điều đó rõ ràng và nhóm các hàm được ghép như vậy trong một lớp.
MSalters

Tôi đồng ý rằng "việc ghép từng chức năng là không thể tránh khỏi". Tuy nhiên, thiết kế tốt sẽ giảm số lượng các chức năng khác mà mỗi chức năng được ghép nối. (Một lớp học chỉ là phương tiện cho mục đích này)
Ian

0

Bạn có thể muốn lấy cuốn sách "Các mẫu thiết kế" từ Gang of Four. Nó không dành riêng cho C ++, vì vậy bạn không công khai chỉ trích kiến ​​thức về đồng nghiệp C ++ khi bạn đề cập đến nó. Tuy nhiên, đồng thời nó giải quyết các chủ đề mà bạn cho là có liên quan. Ngoài ra, cuốn sách được chấp nhận rộng rãi là có liên quan, vì vậy họ không thể dễ dàng bỏ qua nó là lý thuyết hoặc không thực tế.

Mặt khác, xem xét rằng C ++ không phải là ngôn ngữ OO thuần túy, cả về thiết kế lẫn thực tế. Toàn bộ câu chuyện về nhà xây dựng / bộ nhớ âm thanh mà bạn nên giới thiệu RAII, đây hoàn toàn không phải là một kỹ thuật OO mà chỉ dành riêng cho C ++ (thật không may - IDNet của ID cho thấy điều gì xảy ra khi RAII là một suy nghĩ lại). Các cuốn sách liên quan ở đây là (Thêm) C ++ hiệu quả và (Thêm) C ++ đặc biệt.


2
Nhưng các tác giả nói rõ rằng các mẫu thiết kế không phải là một giới thiệu về OOP / OOD nói chung! Khán giả trước tiên nên làm quen với các kỹ thuật OOP cung cấp trước khi đi sâu vào một danh mục mẫu thiết kế mã cứng! "Các mẫu thiết kế đầu tiên" sẽ giới thiệu tốt.
Falcon

2
Nó xuất hiện từ mô tả của OP rằng họ biết OOP / OOD, họ chỉ không sử dụng nó (có thể vì sợ nó quá phức tạp), trong trường hợp một cuốn sách giải thích tại sao nó hữu ích có thể thúc đẩy tốt hơn các ví dụ mã.
wildpeaks

@wildpeaks: OP sais thì ngược lại. Họ không biết OOP / OOD. Họ đang lập trình OOP theo cách thức thủ tục. Họ cần một cái gì đó để giới thiệu cho họ các kỹ thuật thiết kế và cuốn sách GoF không phù hợp với kịch bản này.
Falcon

Tôi đã đề cập đến các câu But every time I bring up OOP, everyone always nods and makes it seem like they know exactly what I'm talking aboutMy teammates are not new to OO languages, nhưng tôi có thể thấy nó thực sự hơi mơ hồ vì họ có thể đang nói dối về việc biết OOP khi OP nói với họ về điều đó.
wildpeaks

1
@MSalters - Lời nói đầu của các mẫu thiết kế: "Cuốn sách này không phải là phần giới thiệu về công nghệ hoặc thiết kế hướng đối tượng. Nhiều cuốn sách đã làm rất tốt điều đó. Cuốn sách này giả định rằng bạn thành thạo một cách hợp lý ít nhất một ngôn ngữ lập trình hướng đối tượng và bạn cũng nên có một số kinh nghiệm trong thiết kế hướng đối tượng. " Cuốn sách này không phù hợp với yêu cầu. Họ nên đọc một số công cụ cấp độ mục nhập.
Falcon
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.