Xử lý một lỗ hổng thiết kế cơ bản khi bạn chưa quen với dự án [đã đóng]

Tôi mới bắt đầu làm việc với một dự án nguồn mở với khoảng 30 nhà phát triển trong đó. Tôi đang làm việc để sửa một số lỗi như một cách để vào "vòng lặp" và trở thành một người thường xuyên đến dự án. Vấn đề là tôi nghĩ rằng tôi đã phát hiện ra một lỗ hổng thiết kế cơ bản gây ra một trong những lỗi tôi đang làm việc. Nhưng tôi cảm thấy nếu tôi viết điều này trong danh sách gửi thư tôi sẽ tỏ ra kiêu ngạo, và một số cuộc thảo luận mà tôi đã có về vấn đề này đang húc đầu vào một số người. Làm thế nào tôi nên đi về điều này?

Ngay cả khi bạn khá chắc chắn rằng đây là một "lỗ hổng thiết kế cơ bản", hãy nhớ rằng bạn là người ngoài cuộc. Nó có thể ở đó vì một lý do tốt. Hoặc, tùy thuộc vào độ tuổi của dự án, nó có thể được đặt ở đó vì lý do chính đáng vào thời điểm đó và bây giờ nó vẫn còn tồn tại vì lý do lịch sử.

Thay vì "làm nổ cái này trong danh sách gửi thư", hãy thử đặt câu hỏi. Cái gì đó như:

"Này, tôi vừa chạy vào X, và nó chẳng có ý nghĩa gì với tôi cả. Có vẻ như cách đúng đắn để thực hiện điều này sẽ là Y, nhưng sau đó tôi lại biết tôi mới ở đây và tôi không muốn nhảy đến bất kỳ kết luận nào. Đây có phải là một lỗi trong thiết kế, hoặc có điều gì tôi đang thiếu không? Ai đó có thể điền vào tôi không? Cảm ơn. "

Kỹ thuật là một trong số ít nơi trên thế giới mà sự khiêm tốn vẫn được coi là một đức tính chân chính và đặt câu hỏi về "những vấn đề rõ ràng" theo cách này là một cách thực sự tốt để có được câu trả lời tốt và học hỏi những thứ mới.

Một trong 48 định luật về quyền lực :

Chiến thắng thông qua hành động của bạn, không bao giờ thông qua tranh luận

Bất kỳ chiến thắng nhất thời nào bạn nghĩ có được thông qua tranh luận thực sự là một chiến thắng của Pyrros: Sự phẫn nộ và bệnh hoạn bạn sẽ khuấy động mạnh mẽ hơn và tồn tại lâu hơn bất kỳ thay đổi quan điểm nhất thời nào. Sẽ mạnh mẽ hơn nhiều khi khiến người khác đồng ý với bạn thông qua hành động của bạn mà không cần nói một lời nào. Chứng minh, không giải thích.

Đây là một trong những điều tôi đã học được một cách khó khăn sau nhiều cuộc tranh luận vô nghĩa.

Trong trường hợp cụ thể này, tôi khuyên bạn nên đưa ra một đoạn mã rất đơn giản và cụ thể sẽ hoạt động nhưng sẽ không vì lỗi thiết kế này. Như người xưa vẫn nói, "Bạn không thể tranh luận với trình biên dịch / trình thông dịch".

Một điều khác là để có ảnh hưởng đối với một nhóm, bạn phải được coi là một thành viên của nhóm . Mặc dù bạn đã gia nhập công ty, mọi người vẫn chưa nhận thấy bạn là thành viên của nhóm. Vì vậy, tốt hơn là nên đi cùng với nhóm đã thành lập cho đến khi họ học cách nhận thức bạn là một trong số họ.

Bạn có thể hỏi tại sao một thiết kế cụ thể đã được sử dụng? Bằng cách đó, bạn có thể nhận được nhiều câu chuyện ngược hơn vì có thể có một số lý do chính đáng tại sao một cái gì đó được chọn mà bạn không biết. Tôi có ý tưởng rằng bạn không phải là chuyên gia có thể tách rời thiết kế nhưng tìm hiểu có thể là một cách để tìm hiểu thêm để cuối cùng bạn có thể hỏi về lỗ hổng mà bạn tìm thấy để không nhìn thấy thông điệp như mồi lửa hoặc trolling.

Bạn có thể sẽ không thích điều này ... nhưng, ở đây đi ...

Tôi đang làm việc để sửa một số lỗi như một cách để vào "vòng lặp" và trở thành một người thường xuyên đến dự án. Vấn đề là tôi nghĩ rằng tôi đã phát hiện ra một lỗ hổng thiết kế cơ bản gây ra một trong những lỗi tôi đang làm việc.

Không, không bạn đã không. Nếu bạn đã làm, bạn sẽ không do dự về nó. Thực tế là bản thân bạn không chắc chắn về "lỗ hổng thiết kế cơ bản", có nghĩa là bạn chưa phát hiện ra. Khi cố gắng chỉ ra sai lầm của người khác, họ không mua cho bạn bất kỳ người bạn nào để sử dụng so sánh nhất (như "cơ bản").

Những gì bạn có thể đã phát hiện ra là một thiết kế tốt hơn một chút, cho vấn đề bạn đang gặp phải. Mặc dù vậy, có lẽ bạn nên kiểm tra kỹ lưỡng - vì bạn là người mới tham gia dự án, có nhiều khả năng bạn không biết bạn đang nói về điều gì.

Nhưng tôi cảm thấy nếu tôi viết nó trong danh sách gửi thư, tôi sẽ trở nên kiêu ngạo

Gọi nó là "lỗ hổng thiết kế cơ bản" chắc chắn sẽ xuất hiện như một kẻ kiêu ngạo. Đối với vấn đề đó, thậm chí chỉ ra rằng nó có thể là một lỗi không phải là ý tưởng tốt nhất. Nếu bạn không biết thực tế (và có thể sao lưu) rằng đó là một vấn đề, thì bạn cần khiêm tốn đặt câu hỏi và nghiên cứu cho đến khi bạn hiểu nó hoàn toàn . Tốt hơn bất cứ ai bạn đang cố gắng thuyết phục.

... và một số cuộc thảo luận mà tôi đã có về vấn đề này đang tàn phá một số người. Làm thế nào tôi nên đi về điều này?

Dừng lại. Đây không phải là một vấn đề đạo đức và nó không giết chết bất cứ ai (tôi giả sử). Nếu bạn có ý định trở thành thành viên lâu dài của dự án, trước tiên bạn phải kiếm được sự tin tưởng trước khi đặt câu hỏi cho họ. Khắc phục các lỗi, thực hiện công việc tuyệt vời của nó (bằng bất kỳ số liệu nào về giá trị của nhóm), thiết kế một vài tính năng và kiếm chỗ ngồi tại bàn.

Sau đó, không chỉ ngón tay hoặc gọi bất cứ điều gì bị hỏng, khiêm tốn đưa ra một đề nghị để cải thiện thiết kế cho nhóm. Và tốt hơn hết là bạn nên nghĩ về tất cả các hậu quả và giải pháp cho chúng, hoặc bạn sẽ bị bắn hạ vì "ngây thơ". Hãy sẵn sàng cho một cuộc tranh luận về lý do tại sao thiết kế của bạn tốt hơn. Hãy chuẩn bị để thua, và mất duyên dáng.

Nếu ý tưởng của bạn thực sự tốt hơn, cuối cùng nó sẽ được nhóm chấp nhận (mặc dù có lẽ không phải bởi nhà thiết kế ban đầu), nhóm không quan tâm, hoặc nhóm là ngu ngốc. Trong cả hai trường hợp sau, tại sao bạn lại muốn trở thành một phần của nhóm?

...

Nếu bạn có khả năng, giải pháp thay thế là chỉ mã hóa thứ chết tiệt đó một cách rực rỡ đến nỗi họ sẽ run sợ trước khả năng mã hóa của bạn và không còn lựa chọn nào khác ngoài chấp nhận sự đơn giản thanh lịch và sự thật vĩnh cửu trong thiết kế của bạn. Các nhà phát triển làm thẩm quyền tôn trọng, nhưng bạn phải cẩn thận - sự trừng phạt cho bất tài (hay kiêu ngạo không chính đáng) là khá nghiêm trọng. Tuy nhiên, vì bạn đang hỏi câu hỏi này, tôi đoán rằng con đường kiêu ngạo xuất sắc và không bị đánh cắp không thực sự là một lựa chọn. ;)

"Xin cảm ơn vì đã chào đón tôi vào nhà của bạn. Khi tôi bước qua cửa, tôi muốn cho mọi người trong gia đình biết rằng em bé của họ xấu xí và ai đó mặc quần áo cho anh ta buồn cười."

Một lỗi là một lỗi, và gọi nó là ổn. Nói rằng nguyên nhân là do "lỗ hổng thiết kế" đang chỉ tay vào chàng trai trước mặt bạn (giống như "bố" nhất) và nói với anh ta rằng anh ta là một thằng ngốc.

Không cần thiết và phản tác dụng. Tôi đề nghị:

"Liên quan đến vấn đề #blah, tôi nghĩ rằng tôi có thể khắc phục bằng cách thực hiện XY và Z nhưng tôi không chắc điều đó sẽ ảnh hưởng đến phần còn lại của dự án như thế nào. Điều này có ổn không?"

Trường hợp XY và Z sửa lỗi. Hãy để họ nói với bạn rằng đó là một lỗ hổng thiết kế; có thể có một giải pháp thay thế. Hoặc các giả định đằng sau 'lỗ hổng' có thể chạy quá sâu trong suốt dự án đến nỗi việc thay đổi nó sẽ sửa lỗi nhưng phá vỡ mọi thứ khác!