Làm thế nào là thời gian làm việc của bạn được phân phối giữa mã hóa và suy nghĩ? [đóng cửa]

... Theo tỷ lệ phần trăm. Ví dụ 60/40 hoặc 90/10 hoặc 100/0.

Giả thuyết của tôi là tỷ lệ thời gian bạn dành để suy nghĩ mã càng nhỏ có thể là kết quả (và sẽ cần ít thời gian hơn để viết nó xuống). Nghĩ nhiều hơn, viết ít hơn, nói cách khác. Bạn có nghĩ đó là sự thật?

Như một lưu ý phụ, tôi nghĩ rằng trong các công ty phần mềm điển hình, suy nghĩ không phải là một phần của văn hóa: bạn thường được cho là ngồi đó trước máy tính của mình gõ một cái gì đó. Bạn gần như chắc chắn sẽ được các nhà quản lý chú ý nếu bạn đi lang thang với một cái nhìn trống rỗng suy nghĩ về các bước tiếp theo với mã của bạn. Quá tệ.

Tôi mã trong giải pháp cuối cùng.

Nói 50% suy nghĩ, 50% mã hóa bao gồm 10% thực hiện và 40% gỡ lỗi.

Như với bất cứ điều gì khác, nó phụ thuộc

Khi bắt đầu một cái gì đó, phần lớn thời gian được dành để suy nghĩ và lập kế hoạch làm thế nào để mã hóa nó. Một khi bạn có kế hoạch tại chỗ, phần lớn thời gian được dành cho mã hóa.

Suy nghĩ 60% / Mã hóa 40%

Tôi không chỉ suy nghĩ trong công việc. Tôi đang suy nghĩ ở mọi nơi tôi đến. Tôi có xu hướng không bắt đầu viết mã cho đến khi tôi đã suy nghĩ về tất cả các khả năng. Tôi không nói về việc viết mã trong đầu, tôi đang nói về việc thực hiện tinh chỉnh từng bước trong đầu.

Một số ngày tôi viết một dòng mã, nhưng vẫn hoàn thành được nhiều công việc hơn (trong khi ứng dụng hoạt động) so với ngày hôm sau tôi viết một nghìn. Người quản lý của tôi sẽ gọi ngày đầu tiên lãng phí, anh ta nhìn vào các LỘC được sản xuất mỗi ngày để đánh giá năng suất (hoặc họ đã từng sử dụng, ít hơn những ngày này).

Tôi có suy nghĩ ít hơn ngày thứ hai? Có thể, tùy thuộc vào loại mã hóa trong tay (nếu việc truy vấn cơ sở dữ liệu mà tôi đã thực hiện hàng ngàn lần thì đó không phải là một thách thức lớn về mặt tinh thần).

Mã ngắn hơn thường tốt hơn nhưng không phải lúc nào cũng vậy.

Tại sao trừng phạt một nhà phát triển đã tăng lưu loát thông qua kinh nghiệm và biết chính xác những gì họ đang làm? Mỗi dòng mã không phải là mã đầu tiên của bạn.

Đừng cho rằng vì tôi đang gõ mà tôi không nghĩ. Gõ không mất nhiều nỗ lực tinh thần.

Lập kế hoạch là rất quan trọng, nhưng đừng nhầm lẫn với suy nghĩ về mã của bạn.

Trái ngược với hầu hết "% chi tiêu suy nghĩ"> "% dành cho câu trả lời mã hóa" ở trên, tôi (hơi ngạc nhiên) thấy rằng năng suất hiện tại của tôi có tương quan với tổ hợp phím của tôi. "Hiện tại" là chìa khóa: Tôi đang học một ngôn ngữ / hệ thống mới và tôi chỉ đơn giản học được nhiều hơn khi tôi bị bẩn tay và xây dựng công cụ và phá vỡ mọi thứ và tìm ra cách khắc phục nó hơn là nếu tôi ngồi lại và cố gắng suy nghĩ thông qua tất cả, điều thường biến thành sự nghiền ngẫm không hiệu quả về việc điều ngu ngốc này quá phức tạp.

(Tôi thường không buồn trả lời một câu hỏi với câu trả lời đã được chấp nhận, nhưng điều này khiến tôi suy nghĩ & tôi không thể giúp cân nhắc.)

Khi tôi lên kế hoạch cho một vấn đề chi tiết trước khi bắt đầu viết mã, tôi thấy rằng tôi thực hiện ít sửa đổi hơn. Tôi nghĩ rằng cần rất nhiều kỷ luật để không đi thẳng vào mã, nhưng là đáng giá. Thật không may, như bạn đã lưu ý, hầu hết các lập trình viên không hiểu rằng thời gian rời khỏi máy tính để lập kế hoạch và nghĩ trước tiên có thể thực sự tăng tốc và cải thiện một nhiệm vụ.

Tôi khá chắc chắn rằng tôi hiểu sự khác biệt của bạn giữa suy nghĩ và mã hóa. Nhưng, tại sao lại ngừng suy nghĩ khi bạn bắt đầu viết mã? Hy vọng, việc gõ không mất quá nhiều công sức mà bạn không thể nghĩ cùng một lúc.

Tôi thấy rằng nó hoạt động tốt để suy nghĩ một lúc về hướng tôi nên đi, sau đó bắt đầu viết mã trong khi tôi nghĩ về nhiều chi tiết ít quan trọng hơn.

Làm thế nào là thời gian làm việc của bạn được phân phối giữa mã hóa và suy nghĩ?

Nó phụ thuộc. Vào thời điểm này trong năm, tôi chủ yếu thực hiện sửa lỗi, vì vậy suy nghĩ là phần lớn nỗ lực làm việc của tôi.

Như một lưu ý phụ, tôi nghĩ rằng trong các công ty phần mềm điển hình, suy nghĩ không phải là một phần của văn hóa: bạn thường được cho là ngồi đó trước máy tính của mình gõ một cái gì đó. Bạn gần như chắc chắn sẽ được các nhà quản lý chú ý nếu bạn đi lang thang với một cái nhìn trống rỗng suy nghĩ về các bước tiếp theo với mã của bạn.

Bạn sẽ thấy rằng thái độ này không giới hạn ở các công ty phần mềm. Đó là một hiện tượng phổ biến trong văn hóa doanh nghiệp Mỹ. Kinh nghiệm của tôi là các nhà quản lý đã dành thời gian đáng kể trong quân đội (hoặc khi còn trẻ hơn trong trường học theo kiểu quân đội) có thói quen luôn làm việc . Nếu Seargant của bạn bắt bạn không làm việc (và vì người xem bên ngoài không thể nhìn thấy, hãy suy nghĩ == tắt đi), anh ta sẽ ra lệnh cho bạn chà rửa vỉa hè bằng bàn chải đánh răng (hoặc công việc ngu ngốc khác) chỉ để giữ bạn từ đi tắt. Người quản lý tồi tệ nhất mọi thời đại mà tôi làm việc sẽ cố tình tạo ra một cuộc khủng hoảng để tạo ra công việc cho bạn nếu anh ta bắt bạn không làm gì - và vì anh ta cũng là chủ sở hữu, anh ta không tin rằng bạn cần phải suy nghĩ về bất cứ điều gì, chỉ là hoàn thành nó đi.

Làm thế nào là thời gian làm việc của bạn được phân phối giữa mã hóa và suy nghĩ?

HỌ GIỐNG NHAU

GIAO DỊCH KẾT THÚC

Suy nghĩ với tôi là một cách trừu tượng hóa mã hóa. Bạn nghĩ về những khả năng và kết quả rất có thể của họ. Tôi nghĩ rất nhiều. Đôi khi tôi nằm gục đầu trên bàn và nhắm mắt lại. Suy nghĩ là cấp độ nhỏ nhất của thiết kế. Tôi luôn điều chỉnh độ dài suy nghĩ của mình dựa trên hiệu ứng khu vực của mã tôi sắp viết.

"Tôi đặt nút này ở đâu?" hầu như không có thời gian suy nghĩ, "tôi đặt trường cơ sở dữ liệu này ở đâu?" miễn là nó cần.

Suy nghĩ trên giấy cũng có ích, và nó trông giống như làm việc nhiều hơn và ít giống như mơ trong ngày.

nó có thể thay đổi rất nhiều Rất nhiều mã của tôi là kết quả của một loạt các công cụ mà tôi đã viết. Vì vậy, có những ngày tôi "viết" một số lượng lớn mã, hầu như không có mã nào bằng tay. Và có những ngày tôi nghĩ rằng tôi dành nhiều thời gian với một cây bút chì hơn là với bàn phím của tôi.