Làm thế nào để giải thích tại sao sự lựa chọn thiết kế là tốt? [đóng cửa]

Khi tôi trở thành một nhà phát triển tốt hơn, tôi thấy rằng phần lớn kỹ năng thiết kế của tôi đến từ trực giác hơn là phân tích cơ học. Điều đó thật tuyệt. Nó cho phép tôi đọc mã và cảm nhận nhanh hơn. Nó cho phép tôi dịch các thiết kế giữa các ngôn ngữ và trừu tượng dễ dàng hơn nhiều. Và nó cho phép tôi hoàn thành công việc nhanh hơn.

Nhược điểm là tôi thấy khó giải thích hơn với các đồng đội (và tệ hơn là quản lý) tại sao một thiết kế cụ thể là lợi thế; đặc biệt là các đồng đội đứng đằng sau thời gian thực hành tốt nhất. "Thiết kế này dễ thử nghiệm hơn!" hoặc "Bạn nên ưu tiên thành phần hơn thừa kế." đi thẳng qua đầu họ và dẫn vào lỗ thỏ của tôi khi cố gắng đầu mối mọi người trong thập kỷ tiến bộ công nghệ phần mềm cuối cùng.

Tất nhiên tôi sẽ làm tốt hơn với thực tiễn, nhưng trong thời gian đó, nó liên quan đến rất nhiều thời gian lãng phí và / hoặc thiết kế xấu (điều đó sẽ dẫn đến lãng phí thời gian để sửa nó sau này). Làm thế nào tôi có thể giải thích rõ hơn tại sao một thiết kế nhất định lại vượt trội, khi lợi ích không hoàn toàn rõ ràng với khán giả?

Điều này có thể không trực tiếp trả lời câu hỏi của bạn, nhưng nó có thể dẫn bạn theo một hướng thú vị.

Tôi nghĩ những gì bạn cần làm có liên quan nhiều hơn đến việc bán chúng trên ý tưởng hơn là giải thích nó cho họ. Bán hàng là để hiểu vấn đề của khách hàng là gì và sau đó cho họ thấy sản phẩm của bạn (hoặc phương pháp phát triển, bất cứ điều gì) sẽ mang lại lợi ích cho họ như thế nào . Mỗi người có những nhu cầu khác nhau, vì vậy những điều đó có lợi cho một người và khiến họ phấn khích rất có thể khiến người khác bị lạnh.

Đối với CEO của bạn, thời gian tiếp thị có thể là chìa khóa, đối với người quản lý của bạn, đó có thể là lịch trình dễ dự đoán hơn, đối với các đồng nghiệp lập trình của bạn, đó có thể là mã hóa nhanh hơn (hoặc kiểm tra / tài liệu / gỡ lỗi / bất cứ điều gì dễ dàng hơn) và cho khách hàng của công ty bạn có thể là ... ?

Bán hàng không diễn ra tự động - bạn phải nỗ lực phối hợp để hiểu quan điểm của người khác và sau đó tìm ra cách ánh xạ ý tưởng của bạn vào Happy Place ™ của họ. Một khi họ biết cá nhân họ sẽ được hưởng lợi như thế nào từ điều mới này, họ thường hỏi: "Chi phí bao nhiêu và chúng ta có thể làm điều đó trong bao lâu?" Một khi bạn nghe thấy những lời kỳ diệu đó, bạn biết rằng bạn đã hoàn thành tốt công việc bán hàng của mình.

Tôi thực sự không có giải pháp cho câu hỏi của bạn nhưng một thời gian trước tôi đã phải đối mặt với chính xác vấn đề nan giải và đang tìm cách trả lời chính xác câu hỏi này.

Tôi sẽ thấy mình ở một bên của cuộc tranh luận và một người khác ở phía bên kia và mặc dù mọi sợi cơ thể của tôi nói với tôi thiết kế phù hợp là X, tôi không thể sao lưu nó bằng lời nói.

Tệ hơn nữa là đôi khi tôi sẽ thừa nhận quan điểm và để người khác thực hiện theo cách của họ chỉ để thiết kế của họ nổi lên trong khuôn mặt của tôi và sau đó tôi nghĩ, "Vâng, đây là ví dụ hoàn hảo về lý do tôi không muốn để làm theo cách đó. Giá như tôi có thể chứng minh mã này cho họ trước đó. "

Chà, tôi chưa bao giờ thực sự tìm thấy câu trả lời nhưng vài ngày trước khi tôi lướt qua Lean Software Development: Bộ công cụ Agile, Tôi đã bắt gặp một điều thú vị có thể gợi ý rằng câu trả lời không thực sự tồn tại. Một phần của cuốn sách đã nói về các nhà lãnh đạo trong các lĩnh vực khác, đặc biệt là trong các đơn vị ứng phó khẩn cấp và cách các nhà lãnh đạo đưa ra quyết định. Khi có hỏa hoạn, hoặc ai đó đang bắn vào bạn, những nhà lãnh đạo đó không bao giờ ngồi xuống và tranh luận về ưu / nhược điểm với đồng đội của họ. Thay vào đó, họ sử dụng trực giác, được phát triển thông qua đào tạo và kinh nghiệm để giúp họ đưa ra quyết định. Áp dụng tương tự cho nghề nghiệp của chúng tôi: làm thế nào bạn có thể đưa ra quyết định hoàn toàn hợp lý khi phải đối mặt với vô số điều chưa biết và tính biến đổi rất phổ biến trong phát triển phần mềm? Các tác giả cho rằng thay vì cố gắng biện minh cho mọi quyết định, các nhà phát triển nên được khuyến khích đào tạo và cải thiện bản năng của mình để cuối cùng họ sẽ "chỉ biết" phải làm gì.

Cách duy nhất tôi tìm thấy để vượt qua những tranh luận này là xây dựng một hồ sơ theo dõi đã được chứng minh về công việc của tôi. Để cho quản lý và những người khác trong nhóm của tôi biết rằng các quyết định thiết kế mà tôi đưa ra trong mã của mình dẫn đến mã dễ bảo trì hơn, mở rộng và đáng tin cậy hơn. Bạn làm điều này nhiều lần và mọi người sẽ chú ý đến bạn. Vào thời điểm đó, ý kiến ​​của bạn, có thể chỉ dựa trên bản năng của bạn, sẽ có trọng lượng cao hơn nhiều so với hiện nay. Chiến lược này đã làm việc với 90% + trong nhóm của tôi bao gồm cả sếp của tôi. Thật không may, bạn có thể tìm thấy một hoặc hai anh chàng hoàn toàn bướng bỉnh và sẽ từ chối xem bất cứ điều gì theo cách của bạn. Tại thời điểm đó, bạn có một vài lựa chọn:

1. Bạn có thể cố gắng để tăng thứ hạng (cuối cùng tôi đã đến gặp sếp của tôi và yêu cầu một thứ hạng vì tôi đã quá mệt mỏi với những cuộc tranh cãi cuối cùng này)
2. Bạn có thể cố gắng vận động hành lang cho phần lớn nhóm để hỗ trợ bạn.
3. Nếu dự án có thể đủ khả năng (nghĩa là không mất quá nhiều năng suất), theo ý kiến ​​của bạn là một quyết định tồi, hãy để người khác giành chiến thắng trong cuộc tranh luận. Một trong hai điều sẽ xảy ra:
   • Trong một số trường hợp (hy vọng phần rất nhỏ), trực giác của bạn sẽ sai và cuối cùng bạn sẽ học được điều gì đó. Tốt cho bạn.
   • Trong hầu hết các trường hợp (một lần nữa ... hy vọng), bạn VÀ người ủng hộ thiết kế "xấu" sẽ nhận ra chính xác lý do tại sao nó xấu; sau tất cả tầm nhìn luôn là 20/20. Hy vọng rằng, đây sẽ là một bài học cho người đó rằng có thể bạn biết bạn đang nói về điều gì và lần sau họ sẽ nghĩ hai lần tranh luận về trường hợp của họ.

Chà, câu trả lời này không thực sự cụ thể đối với lập trình như bạn nghĩ. Bạn phải mang nó trở lại những điều họ hiểu.

Nếu đó là một thứ gì đó giống như thành phần trên sự kế thừa, có lẽ bạn chỉ cần nói rằng hiện tại có lẽ 90% các nhà phát triển sẽ coi đó là một cách thực hành tốt nhất (một phỏng đoán hoang dã, một phần dựa trên thực tế là 100% các nhà phát triển đồng ý gần như không có gì), và bạn đồng ý và sẽ rất vui khi đi vào lý do tại sao.

Tôi cố gắng trung thực hết mức có thể về những gì gây tranh cãi và bao nhiêu phần trăm các nhà phát triển sẽ đồng ý với tôi.

Điều này thường làm việc tốt hơn với quản lý so với các nhà phát triển, những người có thể sẽ khiến bạn đi xuống hố thỏ để giải thích liệu bạn có thực sự ủng hộ thiết kế tốt hay không và làm thế nào để bạn biết điều đó. Có điều gì đó đáng khen ngợi trong việc này, nhưng điều đó có nghĩa là bạn phải dành nhiều thời gian. Trừ khi họ tin tưởng bạn đủ để nhận lời của bạn cho những điều đó, ít nhất là tạm thời. Về mặt tốt, họ có thể thuyết phục bạn rằng bạn sai, điều đó đánh bại sự thật phũ phàng, lạnh lùng thuyết phục bạn xuống đường.

Đối với những thứ như một thiết kế dễ kiểm chứng hơn, nếu họ không đồng ý rằng nó dễ kiểm tra hơn thì nó khá giống với ví dụ đầu tiên. Nếu họ không đồng ý rằng mong muốn được kiểm chứng nhiều hơn, thì bạn phải đưa nó trở lại những điều họ hiểu. Đây rất có thể là quản lý và bạn có thể nói về chi phí phát triển thấp hơn trong dài hạn, ít QA hơn, các quy trình dễ dự đoán hơn (vì độ dài của các chu kỳ QA lặp lại là khó dự đoán), v.v.

Tôi nghĩ một phần của vấn đề là bạn đánh giá thấp việc khó khăn như thế nào để một nhóm đồng ý với bạn về bất cứ điều gì gây tranh cãi, ngay cả khi bạn tình cờ là chính xác (và tất nhiên bạn có thể không). Lập trình một phần là một bài tập xã hội học và bạn có thể cần sắp xếp thời gian để thực sự đi xuống một số lỗ thỏ đó, vì một thiết kế tuyệt vời mà không ai hiểu hoặc bị bỏ lại phía sau hiếm khi là một thiết kế tuyệt vời trong thực tế. Vì vậy, đừng nghĩ rằng thời gian đó là lãng phí, hãy nghĩ rằng đó là một phần cần thiết trong thành công của dự án của bạn. Mặc dù nó sẽ dễ dàng hơn nhiều nếu bạn bằng cách nào đó có thể bỏ qua nó.

Là tiếng nói duy nhất của sự thay đổi không bao giờ là một điều dễ dàng. Thử thách đầu tiên thường là đưa những người khác lên tàu với bạn (Hy vọng có một số người trong công ty của bạn có suy nghĩ thoáng hơn những người còn lại). Nếu bạn có thể thu hút sự chú ý của một vài nhà phát triển / quản lý cấp cao khác để tham gia cuộc thập tự chinh của mình, những tiếng nói kết hợp đó sẽ khó hơn bao giờ hết để những người còn lại bỏ qua.

Tôi tìm thấy một cách tốt để giải thích cho mọi người là thông qua các ví dụ cụ thể về những sai lầm trong quá khứ mà họ đã tham gia tích cực (ví dụ: "Bạn đã bao giờ thử gỡ lỗi này chưa? Nó đã như thế trong nhiều năm và không ai biết làm thế nào sửa nó.."). Tốt hơn hết, áp dụng những ý tưởng và nguyên tắc thiết kế 'mới' đó cho một dự án nhỏ / thử nghiệm và có thể thể hiện mức độ thành công của nó vào cuối.

Tùy thuộc vào thái độ của những người khác trong công ty của bạn, sự thay đổi có thể đến nhanh chóng, hoặc có thể giống như cố gắng bơi qua đường. Một số nhà quản lý hoàn toàn bất động trừ khi họ có số liệu thống kê / bằng chứng chắc chắn trước mặt họ, nơi những người khác khá muốn theo kịp suy nghĩ mới nhất.

Bạn có thể cần thử các chiến thuật khác nhau tùy thuộc vào người bạn giao dịch; Đề xuất rằng tiền / thời gian / nỗ lực có thể được tiết kiệm và chất lượng có thể được cải thiện là một cách tốt để thu hút sự chú ý của các nhà quản lý phi kỹ thuật; và lời hứa về thử nghiệm tự động dễ dàng thu hút khá nhiều nhà phát triển, những người thường không thể chịu đựng nhiều ngày chạy qua cùng một bảng tính thử nghiệm.

Phụ thuộc vào khán giả! Khi các nhà phát triển, chúng tôi đã phát triển một trực giác cho mã tốt và xấu và sử dụng các thuật ngữ cảm xúc mơ hồ như "mùi mã", "mã xấu", "giải pháp đẹp". Điều này chỉ hoạt động khi giao tiếp với các nhà phát triển khác có cùng suy nghĩ. Cố gắng giải thích CEO phi kỹ thuật của bạn rằng bạn nên đầu tư x man-giờ để làm cho một số mã "đẹp hơn" rất có thể bạn sẽ thất bại một cách ngoạn mục.

Bạn cần có khả năng đưa ra trường hợp rằng bất kỳ cải tiến thiết kế nào cũng sẽ

• tiết kiệm tiền cho công ty
• kiếm tiền cho công ty

Ví dụ, trường hợp tuân thủ nguyên tắc trách nhiệm đơn lẻ là gì? Nếu mỗi lớp có một trách nhiệm duy nhất, việc định vị và sửa lỗi sẽ dễ dàng hơn nhiều và việc thêm các tính năng và cải tiến sẽ dễ dàng hơn. Ít thời gian sửa lỗi và thêm tính năng = tiền tiết kiệm.