Làm thế nào để đối phó với tư duy ad-hoc?

Tôi đã tham gia một nhóm phát triển sáu tháng trước. Mọi người đều tốt, tất cả đều tốt. Nhưng càng ngày tôi càng quan sát một tư duy đặc biệt. Công cụ được sửa chữa nhanh chóng, với chi phí cho khả năng sử dụng trong tương lai, có rất ít thử nghiệm và hai người vui vẻ thừa nhận, rằng họ thích mang theo kiến thức trong đầu, hơn là viết nó ra.

Làm thế nào để đối phó với điều này? Tôi muốn dẫn dắt bằng ví dụ, nhưng thời gian có hạn - tôi thích kiến trúc và thực sự triển khai công cụ. Nhưng tôi e rằng lối tư duy đặc biệt lây nhiễm cho tôi và thay vì phấn đấu cho sự rõ ràng và đơn giản trong thiết kế và mã - điều không đơn giản để thiết lập - tôi bị kéo xuống một vòng xoáy vô tận của những vụ hack - điều không có người ngoài cuộc có thể làm phiền - chỉ vì lợi ích của lịch trình và quản lý.

— Rotian
nguồn

Tôi đề nghị một cú đá thả để gây ra sự thiếu khả năng lưu giữ ký ức. Tài liệu là điều cần thiết cho bất kỳ hệ thống tồn tại lâu nào ... ngay cả khi nó không chính thức.

— Giàn khoan

Chào mừng bạn đến phát triển phần mềm!

— yannis

@YannisRizos, không không không! ;)

— Rotian

@Rotian Điều này gần như bắt buộc phải đọc: joelonsoftware.com/articles/fog0000000332.html . Một chút lỗi thời, nhưng vẫn là một tài nguyên tuyệt vời, và có lẽ là giá trị như một câu trả lời của riêng mình.

— K.Steff

Nhìn rộng hơn, tôi khuyên bạn nên sử dụng "Chú Bob" / Mã sạch / và / Bộ giải mã sạch /. Tôi không đồng ý với tất cả những gì anh ấy nói trong những cuốn sách đó, nhưng chúng là những món ăn rất tốt để suy nghĩ. Họ chắc chắn đã mở mắt tôi một chút!

— Michael Scott Shappe

Câu trả lời:

Bạn đã biết một phần của câu trả lời: bạn cần dẫn dắt bằng ví dụ. Bạn cũng cần trở nên thoải mái với thực tế là "khả năng lãnh đạo" của bạn có thể bị bỏ qua, rằng đồng nghiệp của bạn sẽ tiếp tục làm mọi thứ theo cách họ luôn làm - vì điều đó khiến sếp hài lòng hoặc vì chính họ coi trọng sự nhanh nhẹn khả năng duy trì lâu dài.

Cuối cùng, bạn cần để cho kết quả của bạn tự nói lên. Bạn đã bỏ lỡ thời hạn ba ngày nhưng hãy lưu lại nhóm QA ít nhất là nhiều ngày thử nghiệm theo lịch trình vì bạn đã thử nghiệm sự phát triển của mình và phần lớn hoạt động như thiết kế? Đó là một chiến thắng.

Tuy nhiên, cuối cùng, nếu bạn không có ít nhất một mức độ mua quản lý nào đó cho sự đánh đổi đó, bạn chỉ đơn giản là ở trong môi trường sai lầm và cần tìm thêm một cách có lợi cho các thực tiễn tốt. Các thực hành xấu đang hình thành thói quen, vì vậy bạn càng sớm có thể tìm ra cách để giữ vững lập trường của mình, hoặc thay đổi môi trường làm việc với các thực tiễn tốt hơn thì càng tốt.

— Michael Scott Shappe
nguồn

Tôi đánh giá cao câu trả lời của bạn. Tôi đoán bạn biết môi trường của tôi khá tốt - tôi sẽ cố gắng làm việc chăm chỉ hơn - và nếu tôi không nhận được một cuộn - tôi sẽ tìm kiếm một cái gì đó khác.

— Rotian

+1. Hãy là người thay đổi bạn muốn thấy trong nhóm của bạn. Thiết lập tiêu chuẩn.

— Scott C Wilson

+1 để cho kết quả tự nói lên. Điều đó kết hợp với dẫn đầu bằng ví dụ là cách tốt nhất để ảnh hưởng đến thay đổi tích cực. Mọi người thường tự nhiên muốn làm một công việc tốt (hầu hết, dù sao đi nữa) và nếu họ thấy ai đó đạt được kết quả tốt hơn họ, họ có thể sẽ yêu cầu bí mật. Và họ rất có thể lắng nghe khi họ hỏi về ý định của chính họ hơn là nếu họ được nói, không được yêu cầu.

— Erik Dietrich

@Rotian Tất nhiên không phải môi trường cụ thể của bạn, nhưng vâng, tôi đã ở đó và tôi đã làm điều đó. Điều tồi tệ nhất là vào thời điểm đó, tôi thậm chí còn không hiểu nó tệ đến mức nào. Tôi chỉ biết có gì đó không đúng ở mức độ sâu sắc, và cuối cùng quyết định thế là đủ để thoát ra. Chỉ trong những năm gần đây, tôi mới có thể chỉ ra những thực tiễn cụ thể mà họ nên (hoặc không nên) thực hiện.

— Michael Scott Shappe

Không có gì?

Ý tôi là, hạn chế thời gian kinh doanh tồn tại. Của bạn có thể là một kịch bản trong đó thời gian để thị trường có giá trị hơn dễ sử dụng trong tương lai.

Nếu bạn là một lập trình viên xếp hạng và tập tin, thì việc thiết lập các tiêu chuẩn và liên quan đến bản thân với kiến trúc sản phẩm không thực sự là công việc của bạn (đặc biệt là 2 tháng). Bạn nên cố gắng cải thiện sản phẩm theo cách bạn có thể (bao gồm cả thay đổi văn hóa), nhưng không phải trả giá cho việc xa lánh nhóm và / hoặc ông chủ của bạn. Trở thành chàng trai mới nghĩ rằng anh ta biết rõ hơn là một cách nhanh chóng và dễ dàng để làm điều đó.

Tôi sẽ hỏi tại sao bạn đang thực hiện tất cả các bản sửa lỗi hack nhanh này? Có phải do sửa lỗi hack nhanh trước đó? Điều đó đủ dễ để chỉ ra rằng nếu mọi thứ được thực hiện "đúng" ngay từ đầu ...

Cuối cùng, thực hành lập trình xấu dẫn đến nỗi đau cụ thể. Nếu mọi người nghĩ rằng họ sẽ không, tất cả những gì bạn cần làm là chờ đợi.

— Telastyn
nguồn

Theo tôi hiểu, vấn đề không phải là những người này thực hiện sửa lỗi đột xuất do hạn chế về thời gian. Vấn đề là họ không xem đó là một khoản nợ kỹ thuật nên được trả vào lúc nào đó trong tương lai. Nó giống như nhảy: bạn có thể đi qua mà không cần sự hỗ trợ của Trái đất trong một thời gian, nhưng tốt hơn hết là bạn nên chuẩn bị hạ cánh.

— 9000

@ 9000: OP nói rằng đó là vì lịch trình và quản lý, vì vậy tôi đoán (hy vọng) rằng đó chủ yếu là áp lực thời gian. Đánh giá thấp công việc thực tế liên quan đến phát triển phần mềm không hẳn là hiếm.

— Telastyn

Tôi đồng ý rằng các thực hành xấu dẫn đến nỗi đau cụ thể; nhưng nỗi đau cụ thể không phải lúc nào cũng dẫn đến những thay đổi mà bạn mong đợi sẽ thấy trong một thế giới hợp lý. Từ kinh nghiệm, tôi có thể nói với bạn rằng các nhà quản lý tồn tại, những người sẽ không học hỏi từ nỗi đau đó và không đến để khuyến khích các thực hành đúng đắn. Họ sẽ tiếp tục lầm bầm, bởi vì để làm khác, sẽ yêu cầu đứng lên để các ông chủ của HỌ phải ủng hộ dành thời gian để làm điều đó "đúng", điều mà không phải lúc nào họ cũng chuẩn bị làm.

— Michael Scott Shappe

@UncleMikey: Tất nhiên rồi. Nhưng nếu các nhà quản lý của bạn quá kém hiệu quả để sắp xếp mọi thứ một cách phù hợp, thì có rất ít bạn có thể làm.

— Telastyn

@ 9000 và Telastyn - vâng, đó là cả hai tôi nghĩ - một sự thiếu hiểu biết nhất định về thực tế là một thứ như nợ kỹ thuật thực sự tồn tại kết hợp với một môi trường khuyến khích cách giải quyết vì nhiều lý do khác nhau (có thể là thời gian, thói quen, v.v.).

— Rotian