Những cách để phá vỡ Hội chứng của nhà lập trình viên hoàn hảo, [đóng]

Tôi có lẽ không phải là người duy nhất cảm thấy như vậy. Nhưng tôi có cái mà tôi có xu hướng gọi là "Hội chứng của lập trình viên hoàn hảo" mà nhiều người có thể nói là giống như người cầu toàn nhưng trong trường hợp này nó thuộc về lĩnh vực lập trình. Tuy nhiên, lĩnh vực lập trình là một chút vấn đề cho một hội chứng như vậy.

Bạn đã bao giờ cảm thấy rằng khi bạn đang lập trình, bạn không tự tin hoặc không bao giờ đủ tự tin rằng mã của bạn sạch sẽ và mã tốt tuân theo hầu hết các thực tiễn tốt nhất? Có quá nhiều quy tắc để tuân theo mà tôi cảm thấy như bị choáng ngợp bằng cách nào đó. Không phải là tôi không thích tuân theo các quy tắc tất nhiên tôi là một lập trình viên và tôi thích lập trình, tôi xem đây là một nghệ thuật và tôi phải tuân theo các quy tắc. Nhưng tôi cũng thích nó, ý tôi là tôi muốn và tôi thích tuân theo các quy tắc để có cảm giác tốt về những gì tôi đang làm là đi đúng hướng .. nhưng tôi chỉ ước mình có thể có mọi thứ hơn một chút trong "kiểm soát" liên quan đến thực tiễn tốt nhất và mã tốt.

Có lẽ đó là một tổ chức thiếu? Có lẽ đó là một thiếu kinh nghiệm? Có lẽ là thiếu thực hành? Có lẽ đó là thiếu một cái gì đó mà ai đó có thể chỉ ra? Có cách nào để thoát khỏi hội chứng đó bằng cách nào đó?

Ưu tiên . Điều đầu tiên đầu tiên. Tập trung vào những gì quan trọng.

Các ưu tiên của bạn có thể khác nhau, nhưng nói chung bạn nên quan tâm:

• Mã chính xác
• Mã duy trì
• Mã sạch
• Mã đơn giản, thanh lịch
• Mã hiệu quả

Có thể theo thứ tự đó. Tuy nhiên, điểm đầu tiên là quan trọng nhất. Không có nó, mã là vô dụng. Bạn làm gì với một chương trình không hoạt động chính xác?

Làm cho nó hoạt động, mọi thứ khác gần như không liên quan để giải quyết các vấn đề bạn cần giải quyết. Tất nhiên, tôi cũng chịu đựng điều này. Những gì tôi đã học được giúp là chỉ tập trung vào các giải pháp hoạt động . Thế là đủ. Đó là 99% công việc.

Bạn có thể muốn nghĩ về một cái gì đó như mã tốt . Nó là gì? Những loại người viết nó? Làm thế nào để viết mã tốt ? Nó rất đơn giản. Viết mã hoạt động . Mã làm việc là mã tốt. Mọi thứ khác đến sau.

Tất nhiên, khi viết mã trong môi trường chuyên nghiệp, nhóm , mã rõ ràng, dễ đọc và mã duy trì trở nên ngày càng quan trọng. Tuy nhiên, nhiệm vụ đầu tiên vẫn là làm cho nó hoạt động , và tập trung vào đó. Chỉ sau đó, bạn có thể bắt đầu tinh chỉnh và tái cấu trúc cho tốt hơn - nếu cần.

Một điều khá rõ ràng là tính chính xác của mã là rất quan trọng - tuy nhiên tất cả chúng ta đều không chấp nhận tầm quan trọng của nó khi viết mã. Chúng tôi cắt góc, chúng tôi sử dụng tối ưu hóa sớm, chúng tôi cố gắng viết mã thanh lịch ngay cả trước khi chúng tôi đã viết mã làm việc . Đó là bản chất của con người để phấn đấu cho sự hoàn hảo ngay từ đầu, nhưng lập trình và phát triển phần mềm là các quá trình lặp đi lặp lại, và các ưu tiên tồn tại. Do đó, một lần nữa, làm cho nó hoạt động , lo lắng về mọi thứ khác sau này. Hiểu tầm quan trọng của mã chính xác và phấn đấu cho nó.

Trong khi có rất nhiều tấn được gọi là thực hành tốt , tôi nghĩ lẽ thường là quan trọng nhất, hãy nghĩ về lý do tại sao các thực hành được coi là tốt, khi nào và ở đâu để áp dụng chúng. Đừng cố gắng đáp ứng từng chút một của các thực hành tốt. Không có thay thế hoặc thay thế cho kinh nghiệm cá nhân. Bạn không thể tránh những cạm bẫy phổ biến - bất kể bạn đọc bao nhiêu cuốn sách, hội thảo bạn tham dự hay không. Điều quan trọng là học bằng cách làm, làm mọi thứ một cách chính xác và vui vẻ - bất cứ khi nào có thể.

Cách đơn giản nhất để tránh vấn đề này là chỉ thay đổi những gì gây tổn thương. Không đánh bóng mã là chính xác, dễ đọc và có thể duy trì, ngay cả khi bạn nghĩ rằng một số thay đổi có thể làm cho nó thậm chí còn tốt hơn. Nhưng một khi bạn đang cố gắng thay đổi một cái gì đó và không ổn định với một biến mà mục đích không rõ ràng, hoặc một chức năng quá dài để hiểu, hãy sửa nó. Không sớm hơn.

Điều đó không có nghĩa là bạn không nên phấn đấu để có mã tốt, sạch ngay từ đầu, tất nhiên là bạn nên, nhưng bạn nên xem xét nỗ lực đầu tiên của mình "đủ tốt" trừ khi được chứng minh khác đi.

Tôi nghĩ rằng thuốc giải độc tốt nhất cho điều này là để nhắc nhở bản thân rằng tất cả những quy tắc thực hành tốt nhất và quy tắc làm sạch mã này không tồn tại vì lợi ích của riêng họ, cũng không phải bản thân mã.

Cuối cùng, điều quan trọng hơn bất cứ thứ gì khác là phần mềm hoạt động và có thể được sử dụng. Và điều đó sẽ không xảy ra nếu bạn không hoàn thành nó.

Tôi không thích so sánh mã hóa với nghệ thuật, nhưng về mặt này nó hoạt động: các nghệ sĩ ( đặc biệt là các tác giả ) cũng thường muốn tiếp tục làm việc trên một tác phẩm bởi vì luôn có một thứ gì đó không hoàn hảo. Nhưng giá trị nào có ở sự hoàn hảo khi nó trì hoãn xuất bản vô thời hạn và do đó ngăn cản bất cứ ai đánh giá cao tác phẩm?

Điều quan trọng nhất để nhận ra là mã của bạn sẽ luôn thay đổi và luôn có chỗ để cải thiện. Không có mã nào là hoàn hảo. Thường xuyên hơn không, một thư viện lớp bạn làm việc hôm nay sẽ rất khác sáu tháng. Bạn tìm hiểu một số kỹ thuật mới, hoặc tìm thấy một mô hình thực sự phù hợp với bạn. Miễn là mã dễ dàng duy trì và có thể đọc được thì bạn nên làm tốt. Lý tưởng nhất là bạn sẽ có các bài kiểm tra đơn vị để dễ dàng tái cấu trúc sau này.

Thật dễ dàng để bị cuốn vào việc làm cho mã trông hoàn hảo và làm theo mọi tiêu chuẩn bạn có thể nghĩ ra. Nó xảy ra cho tất cả chúng ta. Nhìn vào mã tôi đã viết vài tuần trước khiến tôi suy nghĩ về việc thực hiện thay đổi. Thêm một tài sản ở đây, cấu trúc lại phương thức ở đó. Và nó dường như xảy ra vào cuối dự án. Nhưng nếu bạn quá bận tâm đến mức bạn có thể sẽ tạo ra một lỗi hiển thị. Tôi đã làm điều đó một vài lần trong sự nghiệp của tôi. Một vài phiên sửa lỗi 3 giờ sáng đã chữa cho tôi vấn đề đó.

Làm theo cách khác.

Thay vì "những gì có thể được thực hiện tốt hơn?" tìm kiếm "điều gì làm tôi bực mình?" cho đến khi không có gì.

Là một lập trình viên, công việc của bạn là sản xuất mã. Mục đích của các thực tiễn tốt nhất là tăng tỷ lệ sản xuất của bạn bằng cách làm cho mọi thứ dễ hiểu / làm / ghi nhớ hơn. Nếu việc tuân thủ các thực hành này đang cản trở việc thực hiện mọi thứ, bạn đang làm sai điều gì đó. Đơn giản chỉ cần cố gắng tạo mã nhanh nhất có thể và thực tiễn của bạn sẽ phát triển để cho phép bạn làm điều đó.

Làm cho nó hoạt động, làm cho nó sạch sẽ, làm cho nó RẮN, làm cho nó hoạt động.

Ba câu đầu tiên là một câu ngạn ngữ mà tôi tán thành mỗi khi có ai đó tự hỏi làm thế nào để viết mã RẮN trên dòng thời gian. Khi bạn lần đầu tiên viết một dòng mã, nó chỉ đơn giản là phải hoạt động, vì vậy hãy làm những gì bạn phải làm và không được ưa thích. Lần đầu tiên bạn xem lại một dòng mã, nó không còn là một lần nữa và bạn nên dọn sạch mã, làm cho nó dễ đọc hơn và do đó dễ bảo trì hơn. Lần thứ ba con trỏ của bạn đi theo dòng đó, bây giờ có lẽ là một vấn đề lớn và bạn nên cấu trúc lại nó để tuân thủ phương pháp RẮN, trừu tượng hóa các phụ thuộc, triển khai các mẫu và nói chung làm cho mã dễ cắm hơn hoặc được cắm vào để tăng cường trong tương lai.

Sự thanh lịch trong mã sẽ đạt được khi lập trình viên nhận thấy một cơ hội và nói chung là một chức năng đơn giản hóa, làm sạch và nói chung là cải thiện khả năng đọc và duy trì mã trong khi làm theo các bước trước. Nó không phải là một cái gì đó để được tối đa hóa .

Mã trình diễn hầu như luôn là mối quan tâm ít nhất trong các ngôn ngữ được quản lý bộ nhớ (Java, họ .NET, hầu hết các ngôn ngữ chức năng, v.v.). Trong các môi trường này, mục tiêu là viết mã chính xác ("chính xác" ở đây được định nghĩa là tạo ra kết quả mong đợi trong tất cả các trường hợp dự kiến vàdễ hiểu và có cấu trúc tốt, và do đó có thể duy trì được) và hiệu suất chỉ là thứ yếu (thông thường nó sẽ tiến hành ở một mức độ nào đó từ mã chính xác). Trong mọi trường hợp, một thuật toán là hiệu suất khi nó "đủ tốt". Hãy nhớ rằng, "tối ưu hóa sớm là gốc rễ của mọi tội lỗi"; thực hiện tối ưu hóa mà bạn không biết bạn sẽ cần ít hơn là lãng phí thời gian, làm xáo trộn mã và nói chung là ngăn chặn tiến trình. Nó phải hoạt động trước, sau đó một khi nó hoạt động, bạn chạy nó và xem nó chạy nhanh như thế nào. Nếu nó không đủ nhanh (như được xác định bởi một số điểm chuẩn là một yêu cầu được công bố), bạn sẽ cải thiện nó cho đến khi nó được, và sau đó bạn dừng lại .

Bạn thực sự cần phải thực dụng về lập trình. Vâng, tất cả chúng ta đều thích làm mọi thứ đúng, nhưng bạn được trả tiền để cung cấp phần mềm làm việc, không phải để đánh bóng nó cho đến hết cuộc đời.

Cách tiếp cận cần thực hiện là "hoàn thành công việc" trong cuộc sống chuyên nghiệp của bạn. Cung cấp và di chuyển trên. Lưu sự hoàn hảo của bạn cho các dự án cá nhân.