Làm thế nào để tránh nhảy vào một giải pháp khi chịu áp lực? [đóng cửa]

Khi theo thời hạn lập trình đặc biệt nghiêm ngặt (như một giờ), nếu tôi hoảng sợ, xu hướng của tôi là nhảy vào mã hóa mà không có kế hoạch thực sự và hy vọng tôi tìm ra nó khi tôi đi cùng. Có đủ thời gian, điều này có thể làm việc, nhưng trong một cuộc phỏng vấn, nó đã không thành công, nếu không phản tác dụng hoàn toàn. Tôi không phải lúc nào cũng thoải mái ngồi đó suy nghĩ trong khi đồng hồ kêu tích tắc.

Có một danh sách kiểm tra hoặc có các kỹ thuật để nhận ra khi bạn hiểu rõ vấn đề đủ để bắt đầu viết mã không? Khi nào thì hiệu quả nhất để suy nghĩ và thiết kế nhiều hơn so với mã một số thí nghiệm và tìm ra thiết kế trên tất cả sau này?

Dưới đây là danh sách các kỹ thuật để làm bài kiểm tra toán và một kỹ thuật khác để làm bài kiểm tra miệng . Có một danh sách các kỹ thuật tương tự để xử lý một vấn đề lập trình dưới áp lực không?

TRẢ LỜI: Tôi nghĩ rằng đây là một câu trả lời hợp lệ: Làm thế nào để giải quyết nó . Tôi thấy rằng liên kết đó là một câu trả lời cho các bước để giải quyết hoặc tiếp cận hướng tới một giải pháp . Ngoài ra còn có một số lời khuyên thực sự hay tại Suy nghĩ thành tiếng trong một cuộc phỏng vấn có thực sự là chiến lược tốt nhất? . Một lập luận tuyệt vời và ngắn gọn cho TDD là câu trả lời đầu tiên cho TDD Viết mã vs Tìm ra câu trả lời cho một vấn đề? .

Tôi nhớ lại việc đọc một nghiên cứu về cách các đầm lầy lửa hình thành một kế hoạch hành động khi đến hiện trường vụ cháy; nghiên cứu đã quan sát (và lên án) họ vì đã đưa ra một ý tưởng, sau đó theo đuổi ý tưởng đầu tiên đó ngay lập tức. Do áp lực của thời gian, khá nhiều "điều này có thể hoạt động" theo sau là "ok, chúng ta hãy làm điều đó". Nghiên cứu lưu ý rằng các lựa chọn tốt hơn, nhanh hơn, an toàn hơn đã có sẵn, nhưng chúng không được thực hiện đơn giản vì các đầm lầy không nghĩ đến chúng trước tiên.

Nếu bạn muốn một cách tiếp cận có cấu trúc để đối phó với "hỏa hoạn", có thể lấy một chiếc lá ra khỏi cuốn sách (mới) của họ trong đó quy định một số giai đoạn:

RRAPID

1. Phản ứng - Huy động nguồn lực đến sự cố
2. Trinh sát - Thu thập dữ liệu về tình hình
3. Đánh giá cao - Chọn một quá trình hành động dựa trên các tình huống tốt nhất và tồi tệ nhất
4. Kế hoạch - phát triển một kế hoạch dựa trên quá trình hành động
5. Vấn đề của Đơn đặt hàng - Sử dụng định dạng tóm tắt tiêu chuẩn
6. Triển khai - Thực hiện và giám sát

hoặc nói chung chung hơn:

1. Đánh thức mọi người dậy và khiến họ di chuyển
2. Tìm ra những gì đang xảy ra
3. Giải pháp động não
4. Chọn một và lên kế hoạch
5. Nói cho mọi người biết công việc của họ là gì
6. Thực thi và giám sát

Tôi luôn bắt đầu với việc hiểu các yêu cầu và tìm kiếm những khoảng trống trong đó cần câu trả lời.

Sau đó, tôi phác thảo (rất đại khái và trên giấy hoặc bảng trắng) hai hoặc ba giải pháp có thể. Sau đó tôi tự hỏi: "Có điều gì khác tôi cần biết để thực hiện bất kỳ điều nào trong số này không?"

Khi tôi có câu hỏi ban đầu (có câu hỏi 100% thời gian, nếu bạn không có câu hỏi nào, bạn chưa thực sự xem xét yêu cầu chuyên sâu.), Tôi quay lại các bên liên quan để nhận câu trả lời của mình.

Trong khi tôi đang phản ứng với câu trả lời của họ, tôi xem xét các giải pháp của mình và xem liệu cái nào tốt hơn những cái khác hay sẽ tốt hơn một khi tôi nhận được câu trả lời cho câu hỏi. Ví dụ, nếu bạn cần câu hỏi sớm như thế nào ngay lập tức, tôi có thể tìm kiếm một câu hỏi có sự phát triển nhanh nhất nhưng lại mở ra một cách để cải thiện thiết kế sau này. Nếu họ nói với tôi hiệu suất là rất quan trọng, thì tôi sẽ xem xét các giải pháp và xác định xem giải pháp nào có khả năng thực hiện tốt hơn (đây là những dự đoán tại thời điểm này, nhưng nói chung là thông báo). Nếu GUI có liên quan, tôi có thể tạo ra một nguyên mẫu giấy của một số thiết kế khác nhau và khiến các bên liên quan nhìn vào chúng trước khi tôi viết mã bất cứ điều gì (Thông thường họ sẽ thấy rằng họ quên nói với bạn về XYZ, một thứ gì đó là trung tâm của thiết kế!)

Khi tôi nhận được câu trả lời của mình, tôi chọn một thiết kế thô và sau đó tôi lập một danh sách tất cả những điều tôi sẽ phải làm để thực hiện nó. Sau đó tôi bắt đầu viết mã.

... Xu hướng của tôi là nhảy vào viết mã mà không có kế hoạch thực sự và hy vọng tôi tìm ra nó khi tôi đi cùng.

Tôi đã làm điều này khi còn ở trường đại học. Nó đã trở thành một vấn đề thực sự và thường sẽ dẫn đến việc viết lại mã. Tôi bắt đầu giải quyết điều này bằng cách không viết mã. Tôi nhấn mạnh vào suy nghĩ về vấn đề. Với thực hành đủ, tôi theo bản năng tiếp cận những suy nghĩ của tôi hơn là một bàn phím.

... trong một cuộc phỏng vấn, nó đã không thành công, nếu không muốn phản tác dụng. Tôi không phải lúc nào cũng thoải mái ngồi đó suy nghĩ trong khi đồng hồ kêu tích tắc.

Trong một cuộc phỏng vấn, phải có một cách thực hiện hợp lý, được cân nhắc kỹ lưỡng để đưa ra giải pháp và điều đó không phải lúc nào cũng dễ dàng. Những gì bạn không muốn làm là thốt ra câu trả lời mà không cần suy nghĩ. Nếu bạn biết câu trả lời, hãy nhanh chóng đưa ra. Nếu bạn không, hãy dựa vào suy nghĩ của bạn để đưa ra giải pháp. Luôn chỉ ra khi bạn không biết và chứng minh bạn sẽ tìm giải pháp như thế nào.

Có một danh sách kiểm tra hoặc có các kỹ thuật để nhận ra khi bạn hiểu rõ vấn đề đủ để bắt đầu viết mã không?

Tôi sẽ không khuyến khích như vậy bởi vì bạn có thể dựa vào nó một cách cứng nhắc. Thay vào đó, hãy tự hỏi nếu bạn hiểu rõ vấn đề đủ để bắt đầu viết mã. Sao bạn biết? Bởi vì khi bạn lý luận cách tiếp cận của bạn và sau đó kiểm tra nó, với kiến ​​thức hiện tại của bạn về ngôn ngữ, nó sẽ có ý nghĩa. Luôn có kế hoạch và cách tiếp cận. Cũng nên nhớ rằng mã không bao giờ kết thúc và mã không phát triển sẽ chết vì vậy mong đợi được quay lại mã của bạn thường xuyên.

Khi nào thì hiệu quả nhất để suy nghĩ và thiết kế nhiều hơn so với mã một số thí nghiệm và tìm ra thiết kế trên tất cả sau này?

Bạn sẽ muốn biết thiết kế trên tất cả và suy nghĩ về nó. Sau đó, bạn bắt đầu thực hiện cấu trúc lớp và sơ khai. Sau đó xem lại nó một lần nữa. Liệu nó có ý nghĩa? Các thử nghiệm mã hóa là cách tuyệt vời để chứng minh một cái gì đó hoạt động tốt và nên được sử dụng nhưng không được dựa vào thời trang hoặc định hình mã bạn viết.