Khắc phục giải quyết vấn đề chậm do tăng kiến ​​thức về những gì có thể sai [đóng]

Điều này đã gây rắc rối cho tôi trong một thời gian và tôi thực sự đánh giá cao đầu vào của các chuyên gia khác.

Bối cảnh ngắn: Tôi bắt đầu lập trình khi bố mẹ mua cho tôi chiếc máy tính đầu tiên vào năm 1988 (lúc 14 tuổi, tôi 39 tuổi). Tôi đã đi theo một vài con đường sự nghiệp khác trước khi cuối cùng trở thành một lập trình viên chuyên nghiệp vào năm 1997. Có lẽ cuối cùng, nhưng đó là như vậy. Tôi vẫn hài lòng với lựa chọn của mình, tôi thích lập trình và tôi thấy mình giỏi trong những gì tôi làm.

Gần đây, tôi nhận thấy rằng tôi càng có nhiều kinh nghiệm, tôi càng mất nhiều thời gian để hoàn thành các dự án hoặc một số nhiệm vụ nhất định trong một dự án. Tôi sẽ không già đi. Chỉ là tôi đã thấy rất nhiều cách khác nhau để mọi thứ có thể đi sai. Và những cạm bẫy và vấn đề tiềm năng mà tôi biết và nhớ ngày càng nhiều hơn.

Ví dụ tầm thường: trước đây chỉ là "được thôi, viết một tập tin ở đây". Bây giờ tôi đang lo lắng về quyền, khóa, đồng thời, hoạt động nguyên tử, gián tiếp / khung, hệ thống tệp khác nhau, số tệp trong thư mục, tên tệp tạm thời có thể dự đoán được, chất lượng ngẫu nhiên trong PRNG của tôi, thiếu điện ở giữa hoạt động, một API dễ hiểu cho những gì tôi đang làm, tài liệu phù hợp, v.v.

Nói tóm lại, các vấn đề từ lâu đã chuyển từ "làm thế nào để tôi làm điều này" sang "cách tốt nhất / an toàn nhất để làm điều đó".

Kết quả cuối cùng là tôi mất nhiều thời gian để hoàn thành một dự án hơn là một người mới. Phiên bản của tôi có thể là đá rắn, và không thể xuyên thủng như tôi biết cách tạo ra nó, nhưng phải mất nhiều thời gian hơn.

Ví dụ "tạo tập tin" ở trên chỉ là một ví dụ. Nhiệm vụ thực tế rõ ràng phức tạp hơn, nhưng ít phù hợp hơn cho một câu hỏi chung chung như thế này. Tôi hy vọng bạn hiểu tôi đang đi đâu với điều này. Tôi không có vấn đề gì với các thuật toán hiệu quả, tôi yêu môn toán, tôi thích các môn phức tạp, tôi không gặp khó khăn gì với sự tập trung. Tôi nghĩ rằng tôi có một vấn đề với kinh nghiệm, và do đó sợ một lỗi (nội tại hoặc bên ngoài).

Tôi dành gần hai giờ mỗi ngày để đọc các phát triển mới, kỹ thuật mới, ngôn ngữ, nền tảng, lỗ hổng bảo mật, v.v. Câu hỏi hóc búa là tôi càng có nhiều kiến ​​thức, tôi càng chậm hoàn thành các dự án.

Làm thế nào để bạn đối phó với điều này?

Bạn không chậm hơn trong việc hoàn thành các dự án. Trước đây, bạn nghĩ rằng các dự án mới làm quen của bạn đã được thực hiện khi chúng thực sự không. Bạn nên bán chất lượng này cho khách hàng.

"Công ty này có thể hoàn thành công việc nhanh hơn và rẻ hơn, nhưng nó đã thực sự hoàn thành chưa? Hay bạn sẽ săn lùng bọ trong nhiều năm?"

Ngoài ra, bạn cần biết và chấp nhận thành ngữ cũ: "Hoàn hảo là kẻ thù của điều tốt".

Có vẻ như đã đến lúc bạn tham gia vào mặt tối: quản lý.

Tôi không đề nghị bạn từ bỏ lập trình và trở thành người quản lý. Nhưng có vẻ như tất cả những trải nghiệm bạn đã trích dẫn cho đến bây giờ đều mang tính kỹ thuật. Trong thao tác đơn giản bằng cách viết ra một tệp, bạn có thể nghĩ đến 10 khía cạnh khác nhau mà một nhà phát triển kém trưởng thành sẽ không bao giờ xem xét. Không hẳn là một điều xấu, nhưng ...

Mặt tối là tất cả về giá trị hiện tại. Đó là về việc đầu tư tối thiểu để đạt được lợi nhuận tối đa (phân tích lợi ích chi phí). Trong kinh doanh, mọi thứ đều có thể khiến tôi phải trả giá bao nhiêu, xác suất thành công, xác suất thất bại, xác suất thất bại ngoạn mục và lợi ích tiềm năng. Làm toán; hành động phù hợp.

Điều này cũng hoạt động tốt khi bạn là nhà phát triển: tạo một tệp tạm thời, bỏ qua các quyền và xung đột tên - 5 phút. Thu nhập ròng, phần còn lại của nhóm có thể bắt đầu làm việc với bất kỳ mã nào phụ thuộc vào sự hiện diện của tệp đó. Nó có phải là một giải pháp hoàn hảo? Tuyệt đối không. Nó sẽ giúp bạn 99%, 95%, có thể 90%? Vâng, nó có thể sẽ.

Một câu hỏi khác để hỏi: Bạn cảm thấy thế nào về nợ kỹ thuật? Một số người nghĩ rằng nó phải được loại bỏ. Tôi nghĩ những người đó là sai. Cũng giống như trong kinh doanh, nợ kỹ thuật cho phép bạn vay "tiền mặt" hoặc "thời gian" để cung cấp một cái gì đó sớm hơn. Điều gì tốt hơn: Một giải pháp hoàn hảo trong 2 năm hoặc một bản hack hoàn chỉnh mà khách hàng có thể sử dụng và mua trong 4 tháng? Mọi tình huống đều khác nhau, nhưng trong một số tình huống nếu bạn đợi 2 năm, khách hàng của bạn sẽ đăng ký với đối thủ của bạn.

Chìa khóa là quản lý nợ kỹ thuật giống như cách một doanh nghiệp hoạt động tốt quản lý nợ tài chính. Nếu bạn không nhận đủ, bạn sẽ không nhận được lợi tức đầu tư tối ưu. Nếu bạn nhận quá nhiều, sự quan tâm sẽ giết chết bạn.

Vì vậy, lời khuyên của tôi: Bắt đầu đánh giá công việc của bạn dựa trên việc bạn có tối đa hóa giá trị của mình thay vì tối đa hóa tính kỹ lưỡng của bạn hay không. Và nếu bạn thực hành điều này, bạn sẽ phát triển cùng một trực giác mà bạn đã phát triển trong lĩnh vực kỹ thuật của mình.

Một ghi chú bên lề, gần đây tôi đã bắt đầu thực hiện kỹ thuật pomodoro và nó đã giúp ích rất nhiều. Thay vì tiếp tục tiếp tuyến, hãy tập trung vào những khoảng thời gian nhỏ và sau đó phân bổ pomodoros cho công việc / nghiên cứu trong tương lai. Thật đáng ngạc nhiên bao nhiêu lần tôi đã ghi chú để nghiên cứu một chủ đề nhưng một giờ sau khi thời gian đến, tôi tự nghĩ, "có ít nhất 3 điều khác tôi có thể làm với thời gian của mình ngày hôm nay có giá trị hơn."

Tôi đã có (có khả năng) vấn đề tương tự nhiều năm trước, nó đã kéo dài một vài năm và tôi đã vượt qua nó. Vì vậy, có thể bạn sẽ cảm thấy thú vị khi biết tôi đã đạt được điều đó như thế nào, ngay cả khi tôi không chắc chắn cách của tôi cũng sẽ áp dụng cho bạn.

Bạn cũng nên có một cái nhìn ở đây: Bảy giai đoạn chuyên môn về Kỹ thuật phần mềm Điều đó cho thấy năng suất phần lớn là một tác dụng phụ của mức độ kỹ năng. Có thể bạn vẫn đang ở một thời điểm nào đó giữa giai đoạn 3 và giai đoạn 4 về công nghệ bạn đang sử dụng (trình độ kỹ năng phụ thuộc vào công nghệ, bạn có thể thành thạo một số công nghệ trong khi vẫn học những công nghệ khác).

Bây giờ tôi bắt đầu với lời khai tiểu sử.

Một chút bối cảnh. Tôi 47. Tôi bắt đầu lập trình lúc 12 tuổi vào những năm 80. Khi còn học trung học, tôi cũng làm việc như một lập trình viên trò chơi chuyên nghiệp bán thời gian. Về cơ bản, nó không mang lại cho tôi nhiều tiền như vậy, chỉ đủ để mua phần cứng, nhưng tôi thích nó và học được nhiều thứ. Năm 18 tuổi, tôi bắt đầu học chính thức về Khoa học Máy tính.

Kết quả là khi tôi 20 tuổi, bất cứ khi nào bắt đầu bất kỳ nhiệm vụ lập trình nào, tôi đều biết nhiều cách để giải quyết các vấn đề đã cho và rất ý thức về nhiều tham số và cạm bẫy trong tay, và những hạn chế và giới hạn của bất kỳ phương pháp nào.

Tại một số điểm (khoảng 26 tuổi), việc viết bất kỳ chương trình nào trở nên thực sự khó khăn đối với tôi. Có rất nhiều khả năng đã mở ra mà tôi không thể lựa chọn giữa chúng nữa. Trong một vài năm (làm cho nó 6) tôi thậm chí đã ngừng lập trình và trở thành một người viết tin tức kỹ thuật.

Tôi chưa bao giờ hoàn toàn ngừng cố gắng để lập trình tuy nhiên. Và đến một lúc nào đó nó trở lại. Chìa khóa đối với tôi là lập trình cực đoan, cụ thể hơn là nguyên tắc Đơn giản: "Viết điều đơn giản nhất có thể làm việc".

Về cơ bản, tôi buộc bản thân không quan tâm đến hiệu quả mã (đó là rào cản chính của tôi, tránh các thiết kế không hiệu quả), nhưng chỉ đi theo cách dễ nhất. Tôi cũng buộc tôi phải quan tâm ít hơn về các lỗi và trì hoãn việc xử lý lỗi để sau đó, sau khi viết các bài kiểm tra làm tăng lỗi (thực sự đó là TDD).

Đó là điều tôi học được khi viết. Khi tôi không biết viết gì, hoặc tôi biết những gì tôi đang viết là xấu . Cứ đi tiếp. Thực tế viết những thứ xấu. Cuối cùng tôi sẽ sửa nó sau. Hoặc nếu nó thực sự tệ đến mức xóa nó và viết lại, nhưng nó nhanh hơn để viết những thứ hai lần viết bất cứ điều gì hoàn hảo ngay lần đầu tiên.

Thực sự rất có khả năng một mã mà bạn tin là tốt ngay từ lần viết đầu tiên sẽ cần cải thiện nhiều như một mã thực sự xấu.

Nếu bạn đi theo con đường Đơn giản, bạn cũng nhận được một phần thưởng bổ sung. Bạn dễ dàng chấp nhận để loại bỏ / thay đổi thiết kế / mã hóa ban đầu. Bạn có được một tâm trí linh hoạt hơn.

Tôi cũng có thói quen đưa một nhận xét tạm thời vào mã, giải thích những gì tôi không làm bây giờ và dự định sẽ làm sau khi mã sẽ hoạt động trong trường hợp sử dụng bình thường.

Tôi cũng đã tham dự một Dojo XP, một katas mã thực hành với các lập trình viên khác để tiếp thu các thực hành XP. Nó đã giúp đỡ. Nó làm cho các phương pháp chính thức ở trên theo bản năng. Lập trình cặp cũng giúp. Làm việc với các lập trình viên trẻ mang lại một số động lực, nhưng với kinh nghiệm bạn cũng thấy những gì họ không làm. Ví dụ trong trường hợp của tôi, tôi thường thấy họ tham gia vào các thiết kế quá phức tạp và tôi biết cơn ác mộng thiết kế có thể dẫn đến. Đi theo cách đó. Đã làm điều đó. Có vấn đề.

Điểm tối quan trọng đối với tôi là giữ dòng chảy. Nhanh chóng là thực sự thành công trong việc giữ dòng chảy.

Bây giờ tôi trở lại là một lập trình viên chuyên nghiệp và tôi tin rằng tôi đều tốt hơn và nhanh hơn với sự hiểu biết sâu sắc hơn về những gì tôi đang làm. Thực hành TDD Tôi vẫn có thể chậm hơn một chút so với khi tôi còn là một con bò đực nhỏ (và chưa thử nghiệm gì), nhưng tôi cũng không sợ tái cấu trúc và chắc chắn dành ít thời gian để gỡ lỗi hơn (gần như không có thời gian, làm cho nó ít hơn 10% thời gian ).

Cuối cùng: Tôi đã vượt qua codeblock của mình bằng các phương thức nhanh (XP), đơn giản hóa sau đó tái cấu trúc và thực hành để biến điều đó thành bản năng. Nó làm việc cho tôi. Không chắc chắn nó có thể được khái quát cho bất cứ ai khác.

Về mức độ tiếp thu kỹ năng, tôi chủ yếu học cách chấp nhận rằng mỗi khi tôi thay đổi công nghệ (học ngôn ngữ mới, khuôn khổ mới, v.v.) tôi sẽ trải qua một giai đoạn khi tôi chậm lại. Điều này là bình thường và cuối cùng sẽ khắc phục điều đó. Tôi cũng có thể bù đắp cho điều đó bằng phương pháp tốt và kỹ năng lập trình mục đích chung và nó sẽ không còn là vấn đề nữa.

Một phần quan trọng của lập trình là quản lý và kiểm soát sự phức tạp và đối với cá nhân tôi, đó là một trong những vấn đề hàng đầu. Nếu bị bỏ qua thì tần suất thiếu hụt sẽ tăng hoặc như trong trường hợp của bạn, ETA của phần mềm đã hoàn thành tăng đáng kể.

Độ phức tạp của phần mềm có thể được kiểm soát và quản lý từ nhiều cấp độ và cách khác nhau nhưng một nguyên tắc tốt để có được một số quan điểm là: "Ưu tiên hàng đầu của bất kỳ dự án phần mềm nào là sự hài lòng của khách hàng là chức năng của sự mong đợi của họ."

Nói cách khác, độ phức tạp của phần mềm phụ thuộc rất nhiều vào mức độ bạn có kỹ năng kiểm soát sự mong đợi của khách hàng.

Khi một người chấp nhận quan điểm đó, thì hai điểm quan trọng trở nên rõ ràng:

1. kỳ vọng của khách hàng phải được thực hiện rõ ràng (dưới bất kỳ hình thức nào);
2. kỳ vọng của khách hàng luôn có thể được sửa đổi và điều đó được thực hiện thông qua nghệ thuật đàm phán.

Ví dụ của bạn là một ví dụ rất hay, "chỉ cần viết nó" so với "vô số những cân nhắc khác". Hãy suy nghĩ về nó - nếu ai đó viết ra các yêu cầu toàn diện cho cả hai biến thể, liệu có thể có sự tương đương trong các tính năng được mô tả hay không?

Xây dựng một chiếc F16 khác với việc chế tạo một chiếc Cessna mặc dù cả hai đều có thể bay.

Câu trả lời đơn giản là: chấp nhận nó.

Trong tất cả các hệ thống, có sự đánh đổi giữa độ tin cậy, độ bền, bảo mật, tốc độ, chi phí phần cứng, chi phí phát triển, thời gian đưa ra thị trường, bạn đặt tên cho nó. Bạn sẽ không luôn đồng ý với cách khách hàng đưa ra những đánh đổi đó, nhưng bạn không phải là người đưa ra những quyết định đó. Tất cả những gì bạn có thể làm là cung cấp một ý kiến ​​xem xét. Phát triển phần mềm bao gồm toàn bộ gam, từ "trang web cá nhân của tôi" đến "chạy lò phản ứng hạt nhân" và mã phải được viết tương ứng. Nếu sự cố có nghĩa là "tải lại trang web cá nhân của tôi" thì ai thực sự quan tâm nếu điều đó xảy ra? Nhưng nếu một sự cố có nghĩa là "Chernobyl" thì sở thích của bạn đối với mã rắn là nếu bất cứ điều gì hơi bình thường theo ý thích của tôi.

Có một số khách hàng sẽ vui vẻ chấp nhận mã cấp độ "Proof of Concept" và chạy nó trong các hệ thống trực tiếp của họ và thường họ có các quản trị viên hệ thống đã quen với điều đó. IME hệ thống của họ thường không có sẵn trong một giờ hoặc lâu hơn vào giữa đêm trong khi một loạt các khởi động lại theo lịch trình xảy ra. Nhưng họ đã đưa ra quyết định kinh doanh đó là cách họ muốn lăn. Lý tưởng là vì lĩnh vực của họ chuyển động nhanh đến mức mã chất lượng cao sẽ không bao giờ sẵn sàng, nhưng thường vì họ không thể thấy giá trị (nếu một hệ thống "chỉ hoạt động" thì họ không bao giờ nhận thấy nó, do đó hệ thống đó không đại diện cho giá trị tiền bạc). Nếu điều đó làm phiền bạn quá nhiều, hãy cố gắng tránh những khách hàng đó.

Luôn cập nhật là thời gian tất cả chúng ta phải chi tiêu, hoặc ít nhất nên dành. Đôi khi điều đó sẽ giúp bạn làm việc, những lần khác nó chỉ giữ cho tâm trí của bạn ở trạng thái tốt. Dù bằng cách nào, hãy cố gắng tận hưởng nó.

Có vẻ như các kỹ năng của bạn sẽ rất hữu ích cho việc phát triển hệ thống quan trọng cho nhiệm vụ chất lượng rất cao, như các ứng dụng liên quan đến tài chính / giao dịch, phát thanh truyền hình, hàng không vũ trụ, quốc phòng ...

Lỗi trong các loại ứng dụng này rất tốn kém và họ thuê những người có suy nghĩ giống bạn vì bạn có thể giải quyết tất cả các trường hợp.

Sự thật là các hệ thống hiện đại ngày càng trở nên phức tạp. Máy tính bây giờ giống với trò chơi "Jenga" nơi bạn có tất cả các phần này dựa vào nhiều phần khác. Kéo ra một mảnh sai và bạn có một lỗi, rút ​​ra một mảnh chính xác / cần thiết và bạn vẫn có thể tạo ra một lỗi. Hệ thống càng phức tạp, bạn càng có nhiều thời gian để nghĩ ra các cách để làm cho mã của bạn mạnh mẽ hơn và hy vọng cũng an toàn hơn. Tốc độ sẽ rất tốt, nhưng tôi nghĩ rằng tốc độ chiếm chỗ dựa rất nhiều trong những ngày này khi bạn nghe tin công ty "XYZ" bị hack và 6 triệu số thẻ tín dụng của khách hàng đã bị đánh cắp.

Khách hàng của bạn có thể không muốn nghe rằng chương trình của họ cần được bảo mật, mạnh mẽ, v.v. Nhưng bạn có thể nói với họ rằng xe của họ không cần dây an toàn và túi khí cũng như nhà của họ cần khóa và cửa ... vì ai muốn nghe tất cả cái đó?

Nếu bạn đang suy nghĩ quá mức, bạn đang đi về mọi thứ đúng cách, ngoại trừ việc bạn cần chọn một chiến lược có vẻ "cụ thể" và chỉ cần đi theo nó.

Có vẻ như bạn nhận thức được xu hướng suy nghĩ của bạn về mọi thứ có thể sai.

Các nhà phát triển thận trọng có kinh nghiệm thường học cách tuân theo câu thần chú YAGNI, bạn sẽ không cần nó, khi họ cố gắng trở lại quy trình làm việc gọn gàng, nhanh nhẹn và hiệu quả sau khi bị nghẹt thở trong đám cỏ của phân tích chế độ thất bại.

Tuy nhiên, nếu bạn thực sự đang viết một cái gì đó trong một lĩnh vực mà mức độ chăm sóc đó không kém gì những gì Chuyên nghiệp yêu cầu, thì bạn nên nhận ra rằng "vận tốc", "năng suất" của bạn, theo thuật ngữ ròng, có thể đo lường được bằng bao nhiêu tốt ( hoặc gây hại) bạn đang làm cho công ty của bạn, khách hàng của bạn và bộ phần mềm hoặc gia đình sản phẩm bạn đang xây dựng hoặc bảo trì.

Nhớ:

• Bao gồm tổng chi phí bảo trì, tổng chi phí sở hữu và tổng chi phí triển khai và bảo trì các giải pháp khi bạn xem xét các thay đổi trong phương pháp của mình. Đi nhanh hơn và phạm nhiều sai lầm hơn có thể hoặc không thể làm mọi thứ tốt hơn.

• Nếu bạn làm việc trong một công ty tốt, có lẽ bạn có thể thảo luận điều này trong nhóm của riêng bạn và với người giám sát của riêng bạn, mà không phải là một Động thái giới hạn nghề nghiệp. Nếu bạn không thể, bây giờ là thời điểm tốt để tìm hiểu điều đó và tìm một công việc mới.

Điều duy nhất tôi có thể thấy là: "Bạn đang ngày càng trở nên có giá trị hơn".

Và khi bạn có được nhiều kinh nghiệm hơn, bạn sẽ học về những điều bạn nên tránh, và đây là điều giúp bạn trở nên tốt hơn những người khác.

Một điều bạn sẽ nhận thấy rằng mã của bạn sẽ an toàn hơn và dễ bảo trì hơn bây giờ.

• Điều duy nhất bạn cần làm là giải thích cho khách hàng của mình tại sao phải mất thời gian và nó sẽ hữu ích như thế nào đối với họ.
• Bạn cần cho họ thấy chiều sâu của kiến ​​thức của bạn.
• Bạn cần nói với họ lý do tại sao bạn đã làm, những gì bạn đã làm và làm thế nào nó quan trọng với họ và doanh nghiệp của họ.

Đề nghị của tôi sẽ tập trung vào phần này.

khi nghi ngờ mặc định trích dẫn sai Knuth ...

"Tối ưu hóa sớm là gốc rễ của mọi tội lỗi."

Đây là những gì tôi muốn đề xuất, vì dường như thỉnh thoảng bạn có một vấn đề mà tôi gặp phải ...

Điều gì thực sự hiệu quả với tôi ...

1. Viết các bài kiểm tra đơn vị, như thể tất cả các mã đã được thực hiện.
   
2. tài liệu giao diện.
   
3. thực hiện giao diện.

những gì bạn đã thực sự làm:

1. làm việc thông qua các yêu cầu lớp mô hình
2. thực sự thiết lập sự phân chia công việc, đối tượng nào chịu trách nhiệm cho những gì
3. làm việc trong một môi trường khi bạn thực sự có thể bước qua mã làm việc, điều này làm cho mọi thứ nhanh hơn rất nhiều, chính xác hơn ...

cũng dựa vào các xác nhận trong phát triển ban đầu ... sau đó tìm ra biện pháp khắc phục nào cần được thực hiện và bạn sẽ không viết mã không thể truy cập được hoặc khó kiểm tra.

Tôi nghĩ bạn nên tuân thủ các tiêu chuẩn mã hóa của mình, nhưng hãy chắc chắn rằng bạn thẳng thắn với khách hàng của mình. Nhiều khách hàng không biết những gì cần / chi phí để xây dựng phần mềm tốt. Đó là một phần công việc của nhà phát triển chuyên nghiệp để giáo dục họ.

Cho dù bạn nhanh nhẹn hay thác nước, bạn sẽ nhận được một số thỏa thuận từ khách hàng về những gì họ mong đợi ứng dụng sẽ làm. Quá nhiều nhà phát triển (OK có thể nhiều nhân viên bán hàng hơn) phạm tội bao cát . "Họ không nói rằng họ muốn có một trang web bảo mật cao." Trong hầu hết các trường hợp, đó là vì họ không được hỏi. "Bạn có phiền nếu trang web thương mại điện tử của bạn bị hack không?" Tất nhiên họ quan tâm và tại sao bạn sẽ xây dựng nó để cho phép bất cứ ai xâm nhập an ninh? Bạn phải giáo dục họ.

Chỉ cần đảm bảo rằng bạn chỉ làm những gì khách hàng trả tiền cho bạn để làm. Một phần của dịch vụ của bạn là kinh nghiệm của bạn. Khách hàng mong đợi bạn biết những cạm bẫy mà không cần phải hỏi. Tùy thuộc vào họ để bao gồm các yêu cầu. Bạn có thể muốn truyền cho khách hàng muốn một cái gì đó giá rẻ.

Hãy nghĩ về hậu quả thực tế của một lỗi so với tất cả các vấn đề khác cần giải quyết.

Hãy xem xét các hậu quả sau đây của việc tạo ra một đoạn mã được viết kém:

1. Toàn bộ cơ sở dữ liệu bị đổ mỗi tháng. 48 giờ ngừng hoạt động trong khi các bản sao lưu được khôi phục.
2. Hồ sơ khách hàng được liên kết chéo. Đơn hàng trị giá $ 200 được chuyển đến khách hàng sai mỗi tháng.
3. Một đơn hàng bị kẹt trong tình trạng sai mỗi tuần một lần. Đặt hàng tàu nhưng kho phải gọi trợ giúp mỗi khi nó xảy ra.
4. Một lần sau hai tuần, ứng dụng gặp sự cố và người dùng phải nhập lại dữ liệu trị giá 2 phút.
5. Mỗi tháng một lần, ứng dụng bị treo khi khởi động. Người dùng phải giết quá trình và bắt đầu lại.

Điều đầu tiên rõ ràng là không thể chấp nhận được. # 2 - # 5 có thể có hoặc không, tùy thuộc vào bản chất của doanh nghiệp. # 2 - # 5 cần được đánh giá trong bối cảnh các vấn đề khác mà doanh nghiệp đang gặp phải.

Lý tưởng nhất là # 2 - # 5 sẽ không bao giờ xảy ra. Trong cuộc sống thực, với những ưu tiên mâu thuẫn, những người ký vào bảng lương của bạn có thể muốn bạn làm việc với những thứ khác thay vì viết mã hoàn hảo mà không bao giờ có vấn đề. Họ sẽ không bị ấn tượng nếu số 5 được sửa chữa với chi phí không sửa một lỗi nghiêm trọng hơn trong một chương trình khác.

Giải pháp là tạo ra một tập hợp các thư viện với các chức năng thường được sử dụng mà bạn có thể sử dụng lại trên các dự án. Ví dụ: tôi có thư viện StringFiances.dll .NET, công cụ như mã hóa, mã hóa, giải mã, đánh giá biểu thức chính quy, v.v ... Bằng cách này, tôi không phải viết lại liên tục những thứ không thay đổi.

Có một trình bao bọc cho các tác vụ tạo tập tin cũng có rất nhiều ý nghĩa. Thư viện của bạn có thể hiển thị một phương thức gọi là GetFile () thực hiện tất cả các kiểm tra cho bạn và trả về null hoặc một tệp (hoặc bất cứ điều gì bạn thấy hữu ích).

Tôi nghĩ bạn cần học cách quyết định cần thực hiện bao nhiêu cho dự án nào. Một số dự án có thể là tầm thường và bạn thực sự không cần phải dành tất cả thời gian đó để hoàn thiện nó. Không phải tất cả mọi thứ sẽ cần mã hóa vững chắc cũng như mọi thứ sẽ mở rộng tới hàng triệu người dùng.

Viết một chương trình có thể mở rộng quy mô cho hơn một triệu người dùng sẽ mất thời gian và trải nghiệm mà bạn có bây giờ, nhưng nếu bạn biết rằng ứng dụng của bạn sẽ không được sử dụng tối đa hơn 1000 người dùng, sẽ không có điểm nào để chi tiêu hết thời gian đó hoàn thiện nó

Tôi nghĩ rằng đây là một giai đoạn quan trọng trong sự nghiệp lập trình của bạn và bây giờ bạn cần phải đi đến cấp độ tiếp theo, điều này phải làm với sự trưởng thành và không phải lập trình. Bạn cần có khả năng quyết định chính xác bao nhiêu thời gian và mã nên đủ cho bất kỳ dự án cụ thể nào.

Và giống như mọi thứ khác, bạn có thể đạt được điều này cũng như thực hành. Vì vậy, hãy cố gắng quyết định điều này trước khi bạn bắt đầu một dự án, đôi khi ngay cả khi bạn đang làm việc với nó, với kinh nghiệm bạn cũng sẽ vượt qua điều đó. Có thể có một vài lần truy cập và bỏ lỡ ngay từ đầu nhưng theo thời gian, bạn sẽ hoàn thiện nó (ra quyết định, không phải mã).

@Zilk, tôi không phải là lập trình viên tuyệt vời và tôi đã lập trình từ năm 1998. Ngay cả bây giờ tôi cũng đang đối mặt với vấn đề này. Nhưng những gì tôi nhận ra cuối cùng là vấn đề chất lượng. Nếu tôi chết hôm nay, ai đó sẽ có thể lấy những gì tôi đang làm bây giờ từ nơi tôi đã rời đi. Đó phải là tiêu chuẩn của lập trình (Universal).

Tôi đã chuyển mình từ nhà phát triển sang kiến ​​trúc sư bây giờ. Chuyển sang Quản lý đang thay đổi dòng. Nếu bạn muốn tiếp tục với đam mê của mình, bạn có thể chuyển sang làm Kiến trúc sư.

Ban đầu là Kiến trúc sư kỹ thuật -> Kiến trúc sư giải pháp -> Kiến trúc sư doanh nghiệp -> Kiến trúc sư trưởng, v.v.

Là một kiến ​​trúc sư, bạn sẽ hướng dẫn mọi người thành công. Những người như bạn đã lập trình trong nhiều thập kỷ kinh nghiệm mà bạn có thể sử dụng để hướng dẫn người khác.

Giống như một con chim cao hơn nó bay nhiều đất hơn nó có thể thấy đó là kinh nghiệm của bạn.

Tôi cũng cho bạn biết lập trình thực hiện đúng là quan trọng hơn lập trình thực hiện sai nhanh hơn. Gần đây, một trong những đàn em của tôi đã lập trình một cái gì đó sai và nó tiêu tốn của ngân hàng rất nhiều tiền. Tất nhiên chúng tôi đã giao hàng đúng hẹn trước đó nhưng điều đó không có ích! Tôi có được giao vai trò hướng dẫn mặc dù cùng một thiếu niên sẽ mã hóa rằng vấn đề sẽ không xảy ra. Tôi đang đưa ra ví dụ này để nhấn mạnh rằng việc đưa ra hướng dẫn tốt cũng rất quan trọng. Một số người gọi công việc này là Tư vấn.

Một lựa chọn khác là: ngừng viết mã, thay vào đó hãy bán chuyên môn của bạn để phát hiện ra các vấn đề trước.

Nói cách khác, trở thành một nhà tư vấn .

Nhiều tổ chức sẵn lòng trả đô la đắt tiền (nếu không phải là đô la hàng đầu) cho ai đó để phát hiện ra các vấn đề trước khi dành nhiều tháng để tạo mã tạo ra các vấn đề. Người ta biết rằng sửa một lỗi trong thiết kế, là các đơn đặt hàng có cường độ rẻ hơn / dễ dàng hơn so với sửa lỗi sau khi nó được mã hóa, kiểm tra và triển khai.

Bạn sẽ không được viết càng nhiều mã, và bạn có thể có thể bỏ lỡ đó, nhưng sau đó có vẻ như các dòng thực tế của mã không phải là sức mạnh cốt lõi của bạn, nhưng khi biết đó dòng mã nên được viết - và không nên.

Tập trung vào điểm mạnh của bạn.
(tốt, nếu đó là những gì bạn thích ...)

Đề nghị tốt nhất của tôi cho bạn là: xây dựng khối.

Tạo một khối xây dựng tệp mà bạn luôn có thể tin tưởng, tạo một khối cho API của bạn, ngừng lãng phí thời gian của bạn để viết cùng một thứ nhiều lần. Hãy suy nghĩ về mọi vấn đề một lần và sửa chữa nó một lần và mãi mãi.

Sẽ không có ai bắt kịp điều đó, chắc chắn không phải là người mới dành 80% thời gian để gỡ lỗi mã cho các trường hợp góc mà họ không hiểu.

Trên hết, không khắc phục các sự cố không thể xảy ra, chẳng hạn như quyền sai.

Nếu các quyền là sai, một cái gì đó đã sai và bạn nên sửa nó thay vì làm bằng chứng chương trình của bạn.

Đến một lúc nào đó bạn phải tự bắn vào chân mình thay vì luôn kiểm tra xem mình có làm hay không.

Thay vì dành thời gian cho tài liệu, hãy dành thời gian làm cho mã của bạn tự viết tài liệu và càng ngắn càng tốt. Thay thế tất cả các chức năng trùng lặp. Thu nhỏ thư viện của bạn, đổi tên mọi thứ với độ chính xác.

Đừng quá khó khăn với chính mình. Bạn đang làm việc trong một nghề ngày càng phức tạp, đòi hỏi trí tuệ, kiến ​​thức và kinh nghiệm của con người nhiều hơn bao giờ hết.

Sức mạnh xử lý của máy tính đang chậm lại - có lẽ sẽ bị đình trệ - dẫn đến nhu cầu giới thiệu chip đa lõi, số điện áp gpu, song song, v.v ... Chỉ có rất nhiều bóng bán dẫn có thể được đặt trên chip.

Do đó, những tiến bộ lớn hiện nay và trong tương lai sẽ đến từ các lập trình viên - thuật toán tiên tiến và mã hiệu quả hơn.

Nếu bạn nhìn vào GTA 4 và GTA 5, sự khác biệt là đáng kinh ngạc. Nhưng cả hai đều chạy trên cùng một phần cứng. Đây là kết quả của một số thực hành lập trình rất thông minh và tiên tiến mà đơn giản là không bắt buộc, hoặc có sẵn, 10 năm trước.

Điều đó cũng có thể có nghĩa là các lập trình viên có kinh nghiệm có thể trở nên có giá trị hơn trong tương lai - giống như các ngành nghề khác như kỹ thuật nơi thu nhập cao nhất thường xảy ra muộn trong sự nghiệp.

Cũng giống như bạn, tôi bắt đầu lập trình từ năm 14 tuổi, cũng là lúc tôi có chiếc máy tính đầu tiên (mặc dù tôi đã học được vài tháng tại thời điểm đó). Tuy nhiên, tôi "chỉ" 33 bây giờ. :-)

Đề nghị của tôi là, khi phát triển một cái gì đó, bạn lấy từng một trong những lo lắng đó (quyền tệp, số lượng tệp trong một thư mục, v.v.) và sau đó sử dụng tất cả kinh nghiệm rộng lớn của bạn để trả lời một số câu hỏi về nó, theo tinh thần này:

• Sẽ mất bao lâu để xử lý vấn đề đó đúng trong mã của bạn?
• Nếu bạn không xử lý nó đúng cách, có khả năng thứ này sẽ cắn bạn sau này?
• Nếu nó cắn bạn, hậu quả là gì?

Với những câu trả lời đó, một anh chàng có kinh nghiệm như vậy sẽ không gặp vấn đề gì để đưa ra quyết định sáng suốt. ;-)

Trách nhiệm của những "cựu chiến binh" như bạn đưa ra loại yêu cầu này và liên quan đến cả việc xác định những gì có thể sai và quyết định những vấn đề tiềm ẩn nào bạn nên chú ý.

Biết tất cả các tiêu chí có thể có trong khi phát triển ứng dụng là điều quan trọng nhất trong việc phát triển một sản phẩm chất lượng. Bạn đang làm tốt trong việc này. Một điều bạn có thể làm là, Bạn có thể phân loại yêu cầu thành mức chất lượng sau đó ánh xạ mức độ với thời hạn nhất định. Bằng cách này, bạn có thể đáp ứng thời hạn dự án Easliy.

Theo lời của Edsger Dijsktra: Mạnh Nếu gỡ lỗi là quá trình loại bỏ các lỗi phần mềm, thì lập trình phải là quá trình đưa chúng vào. Đó chỉ là một câu hỏi về việc học cách dành thời gian để mã hóa nó đúng. Tôi vẫn còn là một lập trình viên tương đối trẻ (đọc 20ish) và tôi khao khát có thể viết mã một cái gì đó hoàn toàn đúng một lần. Một giờ lập kế hoạch và 10 phút mã hóa là cách tốt hơn so với 10 phút lập kế hoạch, một giờ mã hóa và ba lần gỡ lỗi.