Mẹo về cách truyền bá thực tiễn Hướng đối tượng [đã đóng]

Tôi làm việc cho một công ty vừa có khoảng 250 nhà phát triển. Thật không may, rất nhiều trong số chúng bị mắc kẹt trong lối suy nghĩ theo thủ tục và một số nhóm liên tục cung cấp các ứng dụng Script giao dịch lớn , trong khi thực tế ứng dụng chứa logic phong phú. Họ cũng thất bại trong việc quản lý các phụ thuộc thiết kế và kết thúc với các dịch vụ phụ thuộc vào một số lượng lớn dịch vụ khác (một ví dụ rõ ràng về Big Ball of Mud ).

Câu hỏi của tôi là: Bạn có thể đề nghị làm thế nào để truyền bá loại kiến ​​thức này?

Tôi biết rằng bề mặt của vấn đề là các ứng dụng này có kiến ​​trúc và thiết kế kém. Một vấn đề khác là có một số nhà phát triển chống lại việc viết bất kỳ loại thử nghiệm nào.

Một vài điều tôi đang làm để thay đổi điều này (nhưng tôi thất bại hoặc thay đổi quá nhỏ là)

• Chạy các bài thuyết trình về các nguyên tắc thiết kế (RẮN, mã sạch, v.v.).
• Hội thảo về TDD và BDD.
• Đội huấn luyện (điều này bao gồm sử dụng sonar, findbugs, jdepend và các công cụ khác).
• IDE và tái cấu trúc các cuộc đàm phán.

Một vài điều tôi nghĩ sẽ làm trong tương lai (nhưng tôi lo ngại rằng chúng có thể không tốt)

• Thành lập một nhóm các nhà truyền giáo OO, những người phổ biến cách suy nghĩ OO trong các nhóm differet (những người này sẽ cần phải thay đổi các nhóm mỗi vài tháng).
• Chạy các phiên đánh giá thiết kế, để chỉ trích thiết kế và đề xuất cải tiến (ngay cả khi các cải tiến không được thực hiện do hạn chế về thời gian, tôi nghĩ rằng điều này có thể hữu ích)

.

Một cái gì đó tôi tìm thấy với các đội tôi huấn luyện, là ngay khi tôi rời khỏi họ, họ trở lại các tập quán cũ. Tôi biết tôi không dành nhiều thời gian với họ, thường chỉ một tháng. Vì vậy, bất cứ điều gì tôi đang làm, nó không dính.

Tôi xin lỗi câu hỏi này bị văng lên với sự thất vọng, nhưng cách viết để viết này là đập đầu vào tường cho đến khi tôi bất tỉnh.

Đừng cố gắng đẩy OOP, nó sẽ chỉ làm mọi thứ tồi tệ hơn. Không phải vì OOP là một ý tưởng tồi nói chung: không phải vậy. Nhưng bởi vì dường như bất cứ ai chịu trách nhiệm về mã tóc đó không chỉ thiếu các công cụ để tránh những vấn đề này, mà còn cả kinh nghiệm và quan trọng hơn là động lực.

Những người có mong muốn viết mã sạch sẽ làm như vậy trong bất kỳ mô hình cụ thể nào, có thể là OOP, thủ tục, chức năng, v.v. Nhưng không phải tất cả các lập trình viên đều như vậy, và nếu bạn đẩy bất kỳ công cụ mã sạch nào lên những người không hiểu nhu cầu, bạn sẽ kết thúc với những công cụ này bị lạm dụng giống như các công cụ đã có sẵn. Bạn sẽ thấy các phương thức không liên quan được nhóm thành một lớp, các lớp kế thừa từ các lớp không liên quan, mức độ hiển thị của phương thức dựa trên gỡ lỗi thử và lỗi thay vì thiết kế có ý thức, các phương thức tĩnh không nên là phương thức tĩnh và không tĩnh. , bạn sẽ lãng phí thời gian của bạn.

Thay vào đó, hãy xem liệu bạn có thể đầu tư vào việc nâng cao ý thức cho khả năng duy trì và thanh lịch. Xét cho cùng, các mục tiêu cốt lõi của OOP không khác biệt với bất kỳ chiến lược quản lý phức tạp nào khác (đó là những gì mô hình lập trình thực sự hướng tới): đóng gói, điều chỉnh, khớp nối lỏng lẻo, mức độ phụ thuộc thấp, giữ trạng thái có thể thay đổi và phạm vi của nó tối thiểu, v.v ... OOP chắc chắn không phải là mô hình duy nhất cung cấp cho bạn các công cụ bạn cần để đạt được điều này.

Điều này đưa tôi đến điểm cuối cùng: OOP là một ý tưởng tuyệt vời và nó hoạt động tốt đối với một số loại vấn đề nhất định, nhưng (và tôi đang nói cả từ kinh nghiệm của bản thân và diễn giải ý kiến ​​của một số bộ óc vĩ đại ở đây) cho nhiều loại vấn đề, nó là hoàn toàn không phù hợp. Khi bạn mới tham gia OOP và mã spaghetti bán thủ tục là lựa chọn duy nhất bạn quen thuộc, OOP tự nhiên xuất hiện như một món quà từ thiên đường (và theo cách tương đối, đó là), và bạn có khả năng tiếp cận tất cả các vấn đề như đinh cho búa OOP của bạn. Điều đó chỉ là tự nhiên, và thúc đẩy OOP đến (và hơn thế nữa) những hạn chế của nó là một cách tốt để xây dựng các kỹ năng OOP của bạn, vì vậy đó không phải là tất cả tiêu cực. Nhưng có lẽ (chỉ có thể) cơ sở mã đặc biệt này không cần OOP. Có lẽ nó sẽ được hưởng lợi nhiều hơn từ một kiến ​​trúc thủ tục,

TL; DR: Nếu bạn muốn truyền giáo bất cứ điều gì cả, hãy để nó là (thực hành nền tảng) không phải là bất kỳ mô hình hay phương pháp cụ thể nào.

Bạn không thể khiến bất cứ ai thay đổi, những người không muốn thay đổi. Đó là lý do tại sao các đội bạn đã huấn luyện đã trở lại theo cách cũ của họ.

Vì vậy, thực sự, câu hỏi của bạn nên là "làm thế nào để tôi khiến các nhà phát triển muốn thay đổi theo cách tiếp cận OO?"

Bắt đầu đơn giản, bắt đầu nhỏ, hãy để mọi thứ xây dựng từ đó. Hiển thị lợi ích cho nhà phát triển cá nhân thay vì lợi ích trừu tượng hoặc triết học cho mã, nhà phát triển khác hoặc công ty.

Chỉ ra cách các kỹ thuật OO khác nhau sẽ dẫn đến ít hơn mã mà chúng phải viết cũng như thời gian phát triển nhanh hơn. Hầu như bất kỳ nhà phát triển sẽ lắng nghe một đề xuất sẽ làm cho công việc của họ dễ dàng hơn.

Sau đó bắt đầu chứng minh làm thế nào các kỹ thuật OO sẽ dẫn đến mã được duy trì dễ dàng hơn. Mọi người trong loại môi trường đó sống trong sợ hãi tạo ra " sự thay đổi " làm mất đi một phần ba ứng dụng sản xuất. Đóng gói là chìa khóa để tránh rủi ro này và cho phép mỗi lớp (sắp có) của ứng dụng duy trì hợp đồng với các lớp khác.

Tôi sẽ xem xét làm thế nào dữ liệu được truyền xung quanh. Nếu đó là một danh sách dài các biến mỗi lần, hãy xem xét gói một số biến đó trong một cấu trúc (hoặc thở hổn hển! Một lớp !!!) như một bước sơ bộ. Đơn giản chỉ cần bọc dữ liệu trong một đối tượng là sự khởi đầu của hợp đồng giữa các lớp.

Ở cấp độ rộng hơn - hãy xem xét việc mua quản lý cho nỗ lực này nếu bạn chưa có. Quản lý cần nhìn thấy những lợi ích cụ thể của các khiếm khuyết giảm và rủi ro thấp hơn từ việc thay đổi. Cuối cùng, quá trình tái cấu trúc sẽ dẫn đến thời gian phát triển nhanh hơn, nhưng đó là một lợi ích lâu dài.

Ý tưởng của bạn về các nhóm đánh giá và các nhà truyền giáo OO là những người tốt. Nó cần phải nhiều hơn chỉ là bạn đang thúc đẩy chương trình nghị sự này.

Kinh nghiệm của tôi là việc chuyển từ tư duy thủ tục sang tư duy OO là một trở ngại lớn. Nó đòi hỏi sự kiên trì mà nhiều nhà phát triển không chịu đựng được. Điều này chủ yếu là do các nguyên tắc cơ bản của OO được xem qua.

Thành lập một nhóm các nhà truyền giáo OO, những người phổ biến cách suy nghĩ OO trong các nhóm differet (những người này sẽ cần phải thay đổi các nhóm mỗi vài tháng).

là một ý tưởng tốt. Điều này nên được kỹ lưỡng và OO nên được nói về từ đầu. Khi tôi học các giai thoại lịch sử OO đã giúp rất nhiều.

Tôi cũng sẽ đề nghị,

• Vì động lực là chìa khóa, thúc đẩy họ chi tiết làm thế nào OO có thể cải thiện công việc của họ, đặc biệt là khả năng duy trì mã.
• Xem lại mã và chỉ ra cách cấu trúc lại áp dụng thành phần, kế thừa, đa hình và các mẫu.
• Giới thiệu một quy trình tốt như SCRUM và thu hút các nhà phát triển vào đó.
• Làm cho việc đọc sách như 'Tái cấu trúc' và 'Tái cấu trúc theo mẫu' là bắt buộc.

Tôi đồng ý với Shuvo Naser. Đó là một trở ngại lớn, vì vậy hãy coi nó giống như một chuyến leo núi. Học cách thiết kế toàn bộ ứng dụng bằng OOP sẽ mất nhiều thời gian.

1. Xác định những người hiểu OOP và đưa họ đến gần hơn với các trưởng nhóm, huấn luyện viên, nhà thiết kế, người đánh giá mã, v.v.
2. Sử dụng một dự án hiện có như một tài liệu tham khảo đào tạo. Có thể những người ở # 1 đã ở trong đội đó.
3. Tái cấu trúc một số dự án hiện có. Điều này có thể giúp một số người xây dựng cầu nối giữa mã thủ tục của họ với mã OO. Bắt đầu với những điều cơ bản. Họ phải xem khi nào, ở đâu và tại sao bạn sử dụng các nguyên tắc này.
4. Tham gia cùng họ trong các buổi thiết kế với những người biết họ đang làm gì.
5. Đặt chúng vào nhóm phát triển với ai đó có thể cung cấp hướng dẫn thiết kế và đảm bảo dự án tuân thủ các nguyên tắc OO (Giả sử lý do bạn muốn làm điều này ngay từ đầu là vì nó sẽ cải thiện sự phát triển.).

Thông qua hiếm khi thấy trước những lợi ích. Chúng ta đang nói về thiết kế phức tạp và không sử dụng Trang bìa Báo cáo TPS .

Bạn đã có ý tưởng tốt

Những ý tưởng bạn phác thảo trong câu hỏi của bạn âm thanh tuyệt vời. Đó là một bất ngờ lớn mà bạn không tìm thấy thành công. Đó là năm 2012 và cuộc cách mạng hướng đối tượng từ lâu đã được chuyển từ trạng thái hiện đại sang trạng thái thực hành. Có vẻ như trừ khi bạn có doanh thu rất thấp và rất ít tuyển dụng, bạn sẽ có một khoảng thời gian khó khăn để không nhận được vài chục hoặc thậm chí một trăm lập trình viên hướng đối tượng vững chắc.

Nhanh nhẹn hay hướng đối tượng?

Bạn đề cập đến một số công nghệ Agile như TDD và một số khái niệm mới hơn, vì vậy đừng quá gay gắt với mọi người vì không chấp nhận điều gì đó vẫn được một số nhóm quản lý tích cực đấu tranh. Một số người tuyên bố sẽ nắm lấy Agile, nhưng khi họ nói về nó, điều đó có nghĩa là những gì họ nói nó có nghĩa. Tổ chức không được đặc trưng bởi các nhóm đưa ra quyết định và thích nghi, mà thay vào đó là kiểm soát theo kiểu hợp đồng phân cấp mạnh mẽ.

Nhưng trở lại hướng đối tượng. Bạn không đề cập đến phân tích hoặc thiết kế hướng đối tượng và tôi không chắc ngôn ngữ lập trình nào đang nhường chỗ cho ngôn ngữ lập trình hướng đối tượng nào. Tôi biết UML đang gặp vấn đề phổ biến trong số nhiều lập trình viên hướng đối tượng. Đã được đào tạo kỹ lưỡng về OOAD, tôi tin rằng nó có thể giống như học văn hóa và lịch sử của một quốc gia có ngôn ngữ tự nhiên mà bạn muốn học. Ví dụ, nếu tôi muốn học tiếng Hy Lạp, tôi có thể học bảng chữ cái, từ vựng và ngữ pháp, nhưng nếu tôi bỏ qua lịch sử và văn hóa phong phú, tôi sẽ bỏ lỡ rất nhiều. Trong mọi trường hợp, nếu bạn tìm hiểu tất cả về một ngôn ngữ lập trình hướng đối tượng, nhưng không có gì về OOAD, tôi nghĩ rằng một cơ hội quan trọng đã bị mất.

Vấn đề cần khắc phục?

Cầu quá xa? Nếu bạn yêu cầu mọi người học một điều nhỏ mỗi tuần, trong một năm, trong số những người tham gia, sẽ có rất nhiều thay đổi. Nếu bạn yêu cầu họ thay đổi mọi thứ họ biết, nó sẽ được chào đón bởi một số ít, khó cho nhiều người và không thể cho những người khác. Một số thay đổi như kiểm soát nguồn được bản địa hóa. Bạn chuyển đổi từ việc không làm điều đó trước đây, bạn đã được đào tạo mà không làm căng thẳng giới hạn của trí nhớ, ai đó đã đưa bạn đi qua nó lần đầu tiên, và sau đó ngày này khá dễ dàng.

Những thay đổi khác là phổ biến. Ví dụ, việc hủy bỏ C và chuyển sang Java đòi hỏi phải được đào tạo, thiết lập và thay đổi lớn hàng ngày để áp dụng IDE mới, trình biên dịch mới, ngôn ngữ mới, API mới, mô hình triển khai mới, v.v. điều xảy ra thường xuyên nhất kết hợp với một chương trình thí điểm hoặc tái cấu trúc công ty.

Dẫn đầu một cuộc cách mạng? Nếu những người hiện đang làm công việc có lịch sử được khen thưởng và công ty dường như không có nguy cơ thất bại, động lực thay đổi của họ là gì? Nếu bạn có vẻ như một người ngoài cuộc muốn chỉ ra hướng đi và để họ chịu trách nhiệm về kết quả mà họ không dự đoán được, thì có vẻ như tất cả rủi ro, không có phần thưởng.

Vị trí quyền lực hay ý tưởng lãnh đạo? Nhiều tổ chức hoạt động dựa trên quyền lực vị trí. Nếu bạn thiếu sự hỗ trợ hữu hình từ các nhà quản lý, trưởng bộ phận, giám đốc và Phó chủ tịch, bạn chỉ đơn thuần là một nhà lãnh đạo ý tưởng. Một số người ở vị trí nguy hiểm khi có một ý tưởng, và không thể giải trí cho ý tưởng thứ hai. Nếu bạn có thể chỉ cho họ thay vì nói với họ, điều đó sẽ đi một chặng đường dài để những người hoài nghi thầm lặng và quan tâm đến các đồng minh tài năng.

Cơ sở hỗ trợ quá nhỏ? Thực hiện một cuộc phân chia giữa 250 người đó và sắp xếp họ thành ba loại: sẵn sàng nắm lấy, sẵn sàng học hỏi và không muốn học. Bạn có lý do chính đáng để thất vọng với một số người không quan tâm đến việc thay đổi. Bạn cũng có thể được đẩy trên một sợi dây. Điều này là lãng phí nỗ lực. Nếu bạn có cảm giác ai là người hỗ trợ thay đổi, bạn có thể tìm hiểu điều gì khiến họ quan tâm.

Không giống như một bộ ba y tế nơi sự lựa chọn có đạo đức và thực tế là giúp nhóm trung gian có thể giúp đỡ, bạn có thể đầu tư năng lượng và thời gian của mình dựa trên đánh giá và sở thích của bạn. Vì thành công của bạn, tại sao không trau dồi nhóm đã sẵn sàng đón nhận những ý tưởng mới? Họ có thể là một vài người đầu tiên, nhưng giống như một quả cầu tuyết, tầm nhìn và sự tín nhiệm của bạn như một người ủng hộ sẽ tăng lên. Mọi người sẽ sớm hỏi bạn khi nào khóa đào tạo tiếp theo.

Trong đó cho dài hạn? Cho đến khi bạn nuôi dưỡng một nhà vô địch để mang theo những thứ sau bạn, bạn nên mong đợi đầu tư thời gian xây dựng mối quan hệ. Bạn có thể cần ở lại với các đội bạn huấn luyện trong hơn một tháng. Cho đến khi nhóm sở hữu các thực tiễn được cải thiện cho chính họ, bạn chỉ là một cảnh sát công nghệ hoặc phương pháp. Kèm cặp là một quá trình có thể mất nhiều năm. Có rất nhiều điều mà các nhà phát triển của bạn không muốn làm mà bạn nghĩ là quan trọng (tôi nghĩ cụ thể là bạn đã đề cập đến thử nghiệm đơn vị). Có thể mất một thời gian để xây dựng một tầm nhìn chung về giá trị mà nó mang lại. Tôi biết điều này bằng kinh nghiệm bởi vì tôi đã từng ủng hộ một công cụ bảo hiểm mã tại một công ty Fortune 500 có danh tiếng lớn về chất lượng, nhưng các nhà quản lý và đồng nghiệp đều cảnh giác với việc cam kết với nó.

Chuyên gia hay cơ sở? Nhanh hơn nhiều so với cố vấn sẽ là để thúc đẩy hỗ trợ cơ sở đến từ mỗi thành viên trong nhóm. Bắt đầu với một nhóm gồm mười chuyên gia phần mềm, nếu tôi có lựa chọn để có một người làm việc theo quy trình mọi lúc hoặc mười người làm việc theo quy trình mười phần trăm thời gian, tôi sẽ chọn người thứ hai. Quy trình cơ sở cho phép những người ủng hộ cảm nhận được tác động của phương pháp này và cách tiếp cận được điều chỉnh để giải quyết tốt nhất các vấn đề của đội ngũ sở hữu công việc.

Bạn có thấy Đường Tự do không? Một phần của việc giới thiệu "Thực tiễn tốt nhất" là khiến mọi người từ bỏ một số tự do để làm mọi việc theo cách chung. Từ bỏ ý định của lập trình viên sẽ trở nên ngon miệng hơn nếu bạn tìm kiếm cơ hội để lại nhiều sự lựa chọn cho các nhà phát triển. Những gì họ chọn được phân định từ những gì được ủy quyền bởi một phân vùng mà chúng ta có thể gọi là đường tự do. Có thể cần thiết cho các bộ phận tương tự, hợp lý về tổ chức, khu vực / địa điểm cụ thể, nhóm và thực tiễn cá nhân.

Điều này đáng lẽ phải là một bình luận, nhưng vì rõ ràng tôi chưa thể bình luận về các thứ, cũng có thể là một câu trả lời.

Điều quan trọng nhất từng có trong loại đột phá này (có thể là OOP hoặc bất kỳ sự thay đổi mô hình nào khác, giả sử, lập trình chức năng hoặc bất cứ điều gì xuất hiện trong năm tới) là DO CODE ĐÁNH GIÁ VÀ LẬP TRÌNH PEER . Đồng hành cùng họ, dẫn dắt các đội vào một cách làm việc khác sẽ giúp họ.

Con đường cá nhân của tôi để lập trình hướng đối tượng bắt đầu khi một số đánh giá ngẫu nhiên khi thực hiện đánh giá mã đã trừng phạt tôi vì đã làm công cụ theo cách mô đun và trạng thái duy trì mà không đi đầy đủ C ++ OO; nghĩ mã như

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(lưu ý rằng client_total có thể hoàn toàn dư thừa, là một ví dụ được lên kế hoạch đặc biệt kém)

Và tôi đã kết thúc việc này chỉ khi nhiều đồng nghiệp cao cấp hơn chỉ vào màn hình của tôi và nói "nhìn xem, nếu bạn viết điều tương tự nhiều lần, hãy sử dụng một thủ tục hoặc một chức năng và chỉ cần gọi đi gọi lại".

Các cuộc nói chuyện và các cuộc họp và thực tiễn tùy chọn sẽ không khiến họ thực hiện một sự thay đổi mô hình hoặc giới thiệu một thực tiễn mới, vì không có động lực thực sự để làm điều đó ngoài sự tò mò thuần túy. Mặt khác, làm cho nó không trở thành một điều xấu hoặc thường chỉ cau mày khi điều đó làm tăng tỷ lệ chấp nhận thực sự tốt.

Hãy chuẩn bị cho sự phát triển rên rỉ và định hướng lớp học sẽ xảy ra cho đến khi họ kết hợp thiết kế phù hợp vào những gì họ đang làm. Bạn sẽ thấy nhiều thứ sẽ khiến bạn chết bên trong một chút, nhưng đó là cách con đường học tập trông như thế nào.