Làm thế nào để tôi đối phó với tê liệt phân tích?

Rất thường xuyên, tôi bế tắc khi chọn quyết định thiết kế tốt nhất. Ngay cả đối với các chi tiết nhỏ, chẳng hạn như định nghĩa hàm, luồng điều khiển và tên biến, tôi dành thời gian dài bất thường để xem xét các lợi ích và sự đánh đổi các lựa chọn của tôi.

Tôi cảm thấy như mình đang mất rất nhiều hiệu quả khi dành hàng giờ cho những chi tiết không đáng kể như thế này. Mặc dù, tôi biết rằng tôi có thể thay đổi những điều này nếu thiết kế hiện tại của tôi không hoạt động, tôi gặp khó khăn khi quyết định một lựa chọn.

Tôi nên làm gì để chống lại vấn đề này?

Hai quy tắc đơn giản:

1. Làm điều đơn giản nhất có thể có thể làm việc.
2. Tái cấu trúc liên tục.

Khi bạn bắt đầu thực hiện từng điều này, bạn sẽ có được sự tự tin rằng bạn có thể đưa ra quyết định đơn giản ngay bây giờ mà không ảnh hưởng đến khả năng đáp ứng thay đổi sau này.

Hãy nhớ rằng việc kiểm chứng trong tương lai có nghĩa là làm cho mã dễ thay đổi, không cố gắng lường trước mọi cách có thể mà mã của bạn có thể cần thay đổi.

Thông thường khi tôi cảm thấy như vậy có nghĩa là tôi cần phải thử:

1. Đứng lên, đi bộ xung quanh và đảm bảo tất cả các sinh học đang hoạt động tốt.
2. Đi qua một bảng trắng và vẽ cho đến khi tôi cảm thấy tự tin.
3. Tìm một "người bạn khiếu nại thiết kế", người mà bạn có thể nói chuyện với họ.

Nếu vấn đề liên quan đến cú pháp và các phần nhỏ, thì:

1. Hãy tự hài lòng rằng, ngay cả khi nó xấu, nó được gói gọn ở đâu đó và đại diện cho một loại tàu địa phương hoàn toàn.
2. Thêm các dấu TODO hoặc chỉ các bình luận giải thích lý do tại sao mã lỗi bạn.
3. Chuyển sang nhiệm vụ tiếp theo.

Thật dễ dàng để nghĩ rằng bản thân không hành động. Ngay cả khi bạn quản lý, bằng cách nào đó, để đưa ra giải pháp tốt nhất ngay bây giờ có thể dễ dàng thay đổi trước khi bạn hoàn thành dự án, và sau đó thì sao?

Tốt hơn là chọn một giải pháp hợp lý và chạy theo nó, hơn là ngồi và xem xét giải pháp tốt nhất sẽ là gì. Giải pháp tốt nhất là khó nắm bắt và tệ hơn, chủ quan. Nếu các yêu cầu thay đổi thậm chí một chút, giải pháp của bạn có thể trở nên tồi tệ hơn một giải pháp mà bạn đã loại bỏ vì nó không phải là tốt nhất vào thời điểm đó.

Tôi đang học cách tránh tê liệt phân tích, vì vậy, với chúng tôi =) Điều này thường xảy ra vì chúng tôi muốn thực hiện "thiết kế tốt nhất". Trong thực tế, "tốt nhất" là trong mắt của kẻ si tình . Công thức của tôi để tránh tê liệt phân tích, là áp dụng nguyên tắc thiết kế đủ tốt . Làm thế nào tôi làm điều đó? Tôi mang các biến số như hạn chế thời gian, lên lịch và tự hỏi đâu là thiết kế đơn giản nhất có thể hoàn thành công việc (điều này không có nghĩa là dễ nhất) mà không ảnh hưởng đến chất lượng, nhưng đồng thời, tôi chắc chắn rằng đó là một thử nghiệm và một mở cho đóng mở rộng để sửa đổi (OCP)thiết kế là tốt. Ý tôi là gì khi kiểm tra và OCP? Chà, thay vì tìm kiếm những gì tôi cho là tốt nhất, tôi đã xem xét một thiết kế có thể cho tôi biết khi nào mọi thứ trở nên tồi tệ và cố gắng làm vừa đủ mã cho phép tôi tái cấu trúc và cải thiện sau này. Ngoài ra, hãy thử tách mã sẽ thay đổi với mã giữ nguyên. Tái cấu trúc trở nên dễ dàng hơn, bởi vì mã không được phép thay đổi sẽ an toàn hơn từ tương lai của bạn hoặc người khác.

Làm thế nào về việc để cho cảm giác ruột của bạn quyết định cho một trong các lựa chọn? Điều đó sẽ diễn ra khá nhanh và kết hợp tốt với timeboxing , điều mà ammoQ cũng đề xuất . Bạn có thể thử giới hạn 1 phút nếu các tùy chọn đã được thiết lập hoặc 2 phút nếu bạn phải xác định chúng trước. Hoặc bất cứ điều gì có vẻ thích hợp (được xác định trước). Khi học cách lắng nghe bản năng ruột của bạn, lựa chọn trực quan của bạn sẽ trở nên nhanh hơn và tốt hơn với thực tiễn .

Trong trường hợp bạn đang lo lắng về sự lo lắng về khả năng lựa chọn không hoàn hảo, đây là một số suy nghĩ để giải quyết rằng:

• Nếu có một tùy chọn có lợi thế rõ ràng hơn các lựa chọn khác, bạn sẽ không tự hỏi mình nên chọn cái nào. Vì vậy, bằng lý do đó, bất cứ khi nào bạn thiếu quyết đoán về một số lựa chọn về một vấn đề không quá phức tạp, điều đó chỉ ra rằng tất cả các tùy chọn đều hoàn toàn như nhau; vì vậy không có gì nhiều để mất bằng cách chỉ chọn bất kỳ một trong số họ.
• Điều đó đang được nói, trực giác hoàn toàn không phải là ngẫu nhiên, mà là một phỏng đoán khá tốt, có giáo dục cho giải pháp tối ưu. Thường tốt hơn những gì người ta sẽ nghĩ đến thông qua việc lục lọi vô tận.
• Phục vụ cho chủ nghĩa hoàn hảo, người ta có thể đánh giá sự nhanh chóng của quyết định cao hơn sự tối ưu của sự lựa chọn khi đánh giá một cách có ý thức về hiệu suất của một người. Điều này có ý nghĩa hoàn toàn với các lựa chọn không quan trọng, nhưng không phải là tầm thường để ghi nhớ.

Chúc may mắn! :)

Tôi nghĩ rằng nó đi xa với một chút kinh nghiệm. Hầu hết sự tê liệt của tôi xảy ra bởi vì tôi cố gắng tưởng tượng cơ sở mã sẽ trông như thế nào ở phía trước xa hơn tôi cần để vượt qua nó, tôi chỉ làm điều đơn giản nhất có thể sẽ hoạt động và sau đó tiếp tục. Khi dự án có một số hình dạng nhất định, các đơn vị mã lặp đi lặp lại bắt đầu nổi bật và đủ dễ dàng để trừu tượng các mẫu lặp đi lặp lại và đơn giản hóa mã.

Để vượt qua sự miễn cưỡng của bạn để quyết định, hãy áp dụng thời gian biểu : đặt đồng hồ báo thức tắt trong vài phút; hành hạ tâm trí của bạn cho đến lúc đó, nhưng khi báo thức kêu, hãy chọn tùy chọn tốt nhất bạn đã tìm thấy cho đến lúc đó.

Tạo một nguyên mẫu. Hãy nhớ rằng, một nguyên mẫu được tạo ra để vứt đi, vì vậy nó không quan trọng chức năng, tên biến hoặc thậm chí kiến ​​trúc lớn mà bạn sử dụng. Bạn chỉ cần xây dựng nó để chứng minh rằng nó hoạt động.

Khi bạn đã tạo nó và ném nó ra, tôi sẵn sàng đặt cược rằng bạn sẽ dễ dàng đưa ra những quyết định đó hơn.

Tôi cũng bị vấn đề này Điều tôi muốn nói là bạn không có đủ động lực hoàn thành.

Ví dụ, khi tôi đang viết mã kết xuất, sau đó tôi có một ưu đãi hoàn thành lớn vì tôi biết rằng nếu tôi tiếp tục với nó, tôi sẽ thấy hệ thống hoạt động và nghĩ rằng tôi đã tuyệt vời như thế nào khi nhắn tin cho một quad, hoặc biến đổi một đỉnh. Nhưng bây giờ tôi đang bao thanh toán lại (cố gắng 4, nếu bạn muốn biết) thì tôi đau khổ vì đó là rất nhiều công việc và ngay cả khi tôi hoàn thành, tôi sẽ chỉ nhìn thấy một quad cũ. Và tôi thực sự không muốn phải cấu trúc lại một lần nữa và tôi phát ngán khi gặp lại một người bạn cũ hết lần này đến lần khác, và đó không còn là phần thưởng cho tôi nữa.

Bạn cần chia nó thành các thành phần và tự thưởng cho mình khi hoàn thiện chúng, ngay cả khi chỉ với một số giao diện điều khiển cho thấy nó hoạt động.

Tôi đã đọc câu hỏi của bạn và suy nghĩ mọi thứ dọc theo các áp phích khác: bạn không phù hợp với công việc này; cho mình một giới hạn thời gian; làm một cái gì đó khác trong một thời điểm Sau một số phản ánh, tôi không chắc bất kỳ câu trả lời nào thực sự hữu ích

Rắc rối với các vấn đề tinh thần như thế này là chúng không dễ giải quyết, chúng là một phần của bạn và rõ ràng là bạn quan tâm (có lẽ quá nhiều) về công việc của mình, đừng tự tin đồng ý với chính mình, cũng vậy thiếu kinh nghiệm để xem xét lựa chọn đầu tiên của bạn là hoàn toàn đúng đắn, hoặc căng thẳng quá mức về việc làm cho nó hoàn toàn đúng. Tại sao bạn lại lo lắng về những điều tầm thường như vậy?!

Bây giờ tôi có vấn đề tương tự, nhưng không phải với mã quá nhiều .. thường là những gì cần có cho bữa tối .. pizza hoặc cà ri .. hmm ... pizza nhưng sau đó cà ri là tốt, nhưng tôi cảm thấy như một món cà ri, pizza rẻ hơn , nhưng sau đó bạn có thêm cà ri, nhưng ... và cứ thế. :)

Vì vậy, tôi đã nghĩ - tại sao tôi không gặp vấn đề tương tự với mã hóa và tôi nghĩ đơn giản là vì tôi có một bộ các mẫu mà tôi sử dụng thường xuyên. Nếu tôi cần một định nghĩa hàm, thật dễ dàng .. nó sẽ nằm trong cùng một hướng như mọi định nghĩa hàm khác tôi từng mã hóa. Nếu tôi cần một luồng điều khiển, đầu tiên tôi quyết định xem tôi cần một vòng lặp for hay vòng lặp while và sau đó tạo cùng một mã cũ mà tôi đã sử dụng lần trước tôi cần một trong những điều này. Điều tương tự cũng xảy ra với mọi thứ, tôi có muốn xếp hàng không? Chắc chắn - hãy cắt và dán mã hàng đợi 'tiêu chuẩn' của tôi (được ghi từ dự án cuối cùng tôi đã làm hoặc bất kỳ ai tôi có thể nhớ bằng cách sử dụng một trong những điều này). Kết quả cuối cùng ... Tôi chỉ băn khoăn về những thứ mới, và thành thật mà nói, đó là một niềm vui.

Vì vậy, lời khuyên của tôi là bắt đầu xây dựng một thư viện các đoạn mã - tôi thường gửi email cho chính mình và đặt chúng vào một thư mục nhưng bất cứ điều gì bạn làm việc là tốt nhất - và sau đó bạn sẽ bắt đầu biết phải làm gì mỗi lần. Bạn sẽ luôn đi đến mã cũ bạn đã viết và giải quyết vấn đề, sẵn sàng cho vấn đề tiếp theo. Bạn sẽ thấy bạn trở thành một nhà phát triển nhanh hơn nhiều (nghiêm túc, đây là cách duy nhất để đạt được năng suất lập trình viên) và hy vọng sẽ tìm thấy thời gian cho các bit thú vị, chứ không phải là công việc hàng ngày buồn tẻ mà bạn đã giải quyết nhiều lần kết thúc.

Tất nhiên, phần sau của tất cả những điều đó cũng quan trọng - bạn càng có nhiều công việc, bạn càng mất ít thời gian để suy nghĩ.

Đây là một chiến lược kết hợp các đề xuất của Rein Henrichs ( bắt đầu đơn giản, tái cấu trúc ) và ammoQ ( timeboxing ):

1. Cung cấp cho mình một giới hạn thời gian khá nghiêm ngặt cho một giải pháp đầu tiên chỉ hoạt động. Ví dụ: 30 giây cho một tên biến. Trước tiên bạn có thể đưa ra một cái gì đó như x, sau đó tinh chỉnh nó string, sau đó namecho đến khi thời gian kết thúc.
2. Sau đó tiến hành các nhiệm vụ khác trong một thời gian xác định, ví dụ 10 phút.
3. Chỉ sau đó cho phép bản thân một hộp thời gian khác để cải thiện hơn nữa quyết định của bạn, ví dụ nhưuserHandle

Lợi ích có thể có của phương pháp này:

• kiến thức trở lại vấn đề này sau này có thể giúp giảm bớt vấn đề
• trong khi tiếp tục các nhiệm vụ khác, bạn có thể đưa ra một giải pháp thỏa mãn tốt mà không cần phải lục lọi
• có cho đi sau bước 1 và đang trong dòng chảy của bước 2 , nó có thể đến dễ dàng để giữ bước 3 thực sự nhanh chóng, như bạn muốn tiếp tục với bước 2, và do đó hạnh phúc chỉ cần chọn một giải pháp phù hợp và chấp nhận nó

Khi tôi thực hiện nghiên cứu và không có lựa chọn tốt nhất rõ ràng, tôi tự giới hạn thời gian (thường là 5 phút) để chọn một nghiên cứu, sau đó chỉ cần tiến về phía trước với nó. Ngay cả khi bạn gặp chướng ngại vật, tại thời điểm này, không có gì đảm bảo, bạn sẽ không gặp phải trở ngại tương đương bằng cách đưa ra quyết định khác. Tôi không thể nghĩ về một thời gian tôi đã hối hận về quyết định của mình.

Thông thường lý do bạn không thể quyết định là sự khác biệt là không đáng kể hoặc bạn không có đủ thông tin.

Trong trường hợp a) Đặt giới hạn thời gian để đưa ra các lựa chọn hợp lý để xem xét. Đừng quyết định cái nào. Vào cuối thời gian, chọn một (ngẫu nhiên nếu không có ưu tiên rõ ràng) của các tùy chọn đã xác định và giới hạn thời gian khác. Nếu không có quyết định rõ ràng nào được đưa ra vào cuối thời gian, thì đó là lựa chọn đã được chọn. Bắt đầu viết mã và tái cấu trúc nếu bạn rõ ràng đã hiểu sai. Nếu ông chủ hỏi tại sao, hãy nói "Tôi đã lật một đồng xu, bạn có cách nào tốt hơn không?"

Trong trường hợp b) - bạn cần thêm thông tin và ngồi quanh A béo lớn của bạn .... cả ngày sẽ không cung cấp nó. Thoát khỏi chế độ thiết kế và đi vào chế độ thu thập thông tin. Nguyên mẫu, đặt câu hỏi, đọc tạp chí tecnical. Dù bạn làm gì, đừng ngủ trên đó quá lâu.

Thông thường, giải pháp tốt nhất là thử giải thích quyết định của bạn với đồng nghiệp. Tuy nhiên, vì bạn không muốn làm điều này rất thường xuyên, điều tốt nhất tiếp theo là suy nghĩ trên giấy - bằng giấy / bút hoặc cửa sổ notepad trống.

Bắt đầu bằng cách viết hoàn toàn bất cứ điều gì - chỉ để hòa vào nhịp điệu của văn bản. Trong cửa sổ notepad, bạn có thể chỉ cần gõ "Tôi đang nghĩ trên giấy" và sau đó tiếp tục với một dòng ý thức. Sau một vài giây, bạn sẽ có nhịp điệu viết, vì vậy hãy nhấn enter một vài lần và bắt đầu giải thích vấn đề nan giải của bạn.

Nêu vấn đề, sau đó nêu các giải pháp có thể, những gì tốt về mỗi người, v.v.

Mặc dù nó không phải lúc nào cũng hoạt động, quá trình lấy suy nghĩ ra khỏi đầu (RAM) và lên phương tiện bên ngoài (tài liệu notepad) giúp bạn tự do hơn khi thực hiện các kết nối mới và xem quyết định từ các quan điểm khác nhau.

Tôi bị vấn đề tương tự. Đối với các vấn đề nhỏ, cách tôi cố gắng giải quyết là đi với thiết kế đầu tiên tôi nghĩ rằng điều đó không ngu ngốc. Không có điểm nào cố gắng tìm một thiết kế tối ưu; thật khó nếu không thể không lý luận về tất cả các sắc thái của bất kỳ thiết kế nào bạn có thể nghĩ đến mà không viết nó lên. Khi bạn viết mã, bạn sẽ thấy rằng bạn có thể thực hiện những cải tiến nhỏ. Thực hiện đúng, tôi thấy khá dễ dàng để hội tụ một giải pháp hợp lý tốt theo cách này.

Đối với các vấn đề lớn hơn, tôi nghĩ rằng có công trong việc suy nghĩ thông qua các lựa chọn của bạn trước tiên, nhưng timebox nó. Các vấn đề lớn có không gian giải pháp lớn, bạn không thể đánh giá mọi khả năng, bạn cũng không nên cố gắng.

TLDR; Chọn một giải pháp hợp lý, cải thiện nó khi bạn đi.

Điều này cũng có liên quan:

Giáo viên gốm sứ tuyên bố vào ngày khai giảng rằng ông đang chia lớp thành hai nhóm. Tất cả những người ở phía bên trái của studio, theo ông, sẽ được phân loại chỉ dựa trên số lượng tác phẩm họ sản xuất, tất cả những người ở bên phải chỉ dựa vào chất lượng của nó. Thủ tục của anh ta rất đơn giản: vào ngày cuối cùng của lớp, anh ta sẽ mang vảy trong phòng tắm của mình và cân nhắc công việc của nhóm "số lượng": năm mươi pound chậu được xếp hạng "A", bốn mươi pound một "B", v.v. Tuy nhiên, những người được xếp loại "chất lượng" chỉ cần sản xuất một nồi - mặc dù là một nồi hoàn hảo - để có được "A".

Vâng, đã đến thời điểm chấm điểm và một sự thật tò mò đã xuất hiện: các tác phẩm có chất lượng cao nhất đều được sản xuất bởi nhóm được xếp loại về số lượng. Có vẻ như trong khi nhóm "số lượng" đang bận rộn tạo ra hàng đống công việc - và học hỏi từ những sai lầm của họ - thì nhóm "chất lượng" đã ngồi lý thuyết về sự hoàn hảo, và cuối cùng không có nhiều điều để thể hiện cho những nỗ lực của họ hơn là những lý thuyết vĩ đại và một đống đất sét chết.

từ http: //www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Tôi chưa bao giờ hiểu điều này. Khi tôi là một người hướng dẫn, tôi sẽ nói một cái gì đó như:

"OK, create an integer variable and assign the return value of strlen() to it."

Không quá phức tạp, bạn có thể nghĩ, và 95% mọi người đã viết một cái gì đó như:

int x;   // or y, or len, or whatever
x = strlen( s );

Nhưng thỉnh thoảng sẽ có một người ngồi như một con thỏ bị tê liệt trong đèn pha. Tôi sẽ thông cảm hỏi vấn đề là gì và họ sẽ nói "Tôi không biết gọi nó là gì!".

Đây là những người nên tìm kiếm một nghề nghiệp khác. Như có thể bạn nên.