Bản thân việc viết mã là một nghệ thuật và nhiều tình huống không may khác nhau có thể xảy ra trong quá trình thực hiện nghệ thuật này. Trong khi lập trình, nếu nhiều lần kiểm tra khác nhau không được thực hiện ở những khoảng thời gian khác nhau, thì theo một nghĩa nào đó, công việc sẽ vượt quá tầm kiểm soát và trở nên không thể quản lý được. Hầu như tất cả các nhà phát triển phần mềm trên thế giới đều trải qua từng tình huống này. Trong bối cảnh này, tất cả những vấn đề này đều có tên và định nghĩa do những người đã sống trước đó đặt ra. Chúng tôi đã xem xét 10 trong số đó cho bạn.
Bạn đã bao giờ nghe cụm từ hoặc định nghĩa này về “Bắt bọ bằng vịt nhựa” chưa? Tất nhiên, nhiều nhà phát triển phần mềm nhận thức được những biểu hiện mang tính kỹ thuật và toàn cầu như vậy. Bởi vì những người này, những người sống các giai đoạn cuộc đời của một người bình thường theo một cách khác, có thể nhận thức được một sự kiện nhỏ ở bất kỳ thời điểm nào trên thế giới như thể họ đang ở ngay bên cạnh mình. (Hoặc chúng tôi có vẻ như vậy.) Trong nội dung này, chúng tôi đã tổng hợp một số luật và đề xuất tương tự như định nghĩa trên.
Bắt côn trùng bằng vịt nhựa
Ban đầu được gọi là Gỡ lỗi Vịt Cao su, đây là một gợi ý được tạo ra để ngăn chặn các lỗi thường gặp. Nhắc đến câu chuyện trong cuốn sách Lập trình viên thực dụng, theo định nghĩa này, người lập trình viên cố gắng giải thích những đoạn mã mà anh ta viết cho lũ vịt và tiết lộ những sai lầm mà anh ta đã mắc phải. Lý do tại sao con vịt được sử dụng là vì nó được thực hiện như thể đang giải thích cho một người không hiểu gì về nghề này.
Nguyên tắc phồng lên
Nguyên tắc Bloat, còn được gọi là Quy tắc Zawinski, là tên được đặt cho tình huống mà mã viết phát triển theo thời gian và trở nên không thể tách rời. Nếu chúng ta giải thích tình huống như sau; Khi bạn bắt đầu viết mã, giả sử bạn đang xây dựng một trang web, bạn bắt đầu thêm các tính năng khác nhau khi công việc tiến triển, sau đó bạn lại thêm các tính năng khác nhau. Theo quy tắc này, mọi mã đều phải mở rộng và phồng lên hoặc không còn được sử dụng.
Tâm lý “Tệ hơn là tốt hơn”
Tâm lý “Tệ hơn là tốt hơn” xuất hiện trong một bài tiểu luận về chất lượng phần mềm máy tính của Richard P. Gabriel nhằm đáp lại Nguyên tắc Bloat. “Phần mềm có giới hạn nhưng dễ sử dụng có thể hấp dẫn người dùng và thị trường hơn phần mềm không có giới hạn và phức tạp.” Nói một cách đơn giản, sẽ là khôn ngoan nếu bạn xác định vấn đề chính mà phần mềm của bạn đang cố gắng giải quyết và nếu bạn hành động trong khuôn khổ đó thì mọi chuyện sẽ ổn. Điều quan trọng là phải giữ nó đơn giản vì quá chi tiết có thể dẫn đến rắc rối và khách hàng có thể không muốn điều đó.
Định luật Eagleson
Viết mã giống như đưa một ngôn ngữ vào văn bản. Tuy nhiên, vì ngôn ngữ này không phải là ngôn ngữ mà bạn luôn nói như tiếng mẹ đẻ nên nó có cấu trúc phù hợp để dễ quên. Hãy tưởng tượng rằng bạn đã viết một bài báo bằng ngôn ngữ không phải tiếng mẹ đẻ của bạn vài tháng trước và bây giờ hãy tưởng tượng rằng bạn đang kiểm tra nó. Có vẻ như đó không phải là lời nói của bạn. Tình huống rất giống nhau trong việc mã hóa, 6 Một chuỗi mã được viết cách đây nhiều tháng giờ đây không còn xa lạ với bạn nữa. Đại khái là Luật Eagleson, nhà phát triển 6 ghi nhận sự tiến bộ hàng tháng của họ. Bởi vì con người đang trong quá trình phát triển không ngừng và theo quy luật này, nếu bạn không thể viết được đoạn mã tốt hơn những gì bạn đã viết cách đây nhiều tháng thì bạn chưa được phát triển. Tất nhiên sẽ có người phản đối, và có lẽ đây vẫn chỉ là lý thuyết chứ chưa phải luật.
Nguyên tắc ít gây ngạc nhiên nhất
Theo nguyên tắc này, có thể được biểu thị bằng Nguyên tắc gây ngạc nhiên tối thiểu trong tiếng Thổ Nhĩ Kỳ, nếu nhà phát triển phần mềm có thái độ cực đoan hoặc cấp tiến trong khi cố gắng đổi mới mã mà anh ta viết, anh ta có thể đưa ra một sản phẩm xa lạ với mong đợi của người dùng. Trong bối cảnh này, điều quan trọng hơn là phải tiến hành từng bước hơn là thay đổi lớn. Bởi vì khi nhìn vào các mạng xã hội mà chúng ta sử dụng, trường hợp này là chúng ta không bao giờ thấy một sự thay đổi căn bản nào. Tất nhiên, sẽ không sai khi nói rằng tình trạng này là vô nghĩa khi cần có một sự thay đổi mạnh mẽ.
Luật côn trùng học điều khiển học
“Luôn có thêm một lỗi nữa.” Thường được gọi là Định luật Côn trùng học Điện tử của Lubarsky (không rõ Lubarsky là ai), một lỗi nữa vẫn sẽ xảy ra, cho dù bạn viết mã chương trình của mình có sạch sẽ đến đâu, cho dù bạn kiểm tra các thành phần của mình tốt đến đâu, bất kể bạn có thường xuyên tái cấu trúc hay không. lớp học của bạn. Vì thế không có cái gì gọi là hoàn hảo.
Định luật Kernighan
Theo luật này, quá trình gỡ lỗi khó gấp đôi so với việc viết mã. Vì vậy, ngay cả khi bạn viết mã thông minh nhất có thể thì hóa ra bạn cũng không đủ thông minh để gỡ lỗi. Brian Kernighan, người viết cuốn sách về ngôn ngữ lập trình C, nổi tiếng với luật thông tin này. Trong trường hợp này, động thái hợp lý nhất cần làm là viết mã tốt, dễ đọc và đơn giản hơn là mã thông minh.
Quy tắc chín mươi chín mươi
Theo quy định này, 90% code tương đương với 10% tổng thời gian lao động. Do đó, 10% còn lại bao gồm 90% thời gian. Định nghĩa này của Tom Cargill là một phần lý do khiến việc viết mã trở nên khó chịu: bởi vì bạn nghĩ mình càng ở gần thì bạn càng có thể nhìn thấy xa hơn. Nói cách khác, khi bạn thấy mình sắp hoàn thành công việc này, khi nhìn lướt qua, bạn nhận ra rằng mình vừa mới đi đến giữa.
Định luật Parkinson
“Công việc mở rộng để lấp đầy thời gian cần thiết để hoàn thành.” Chương trình đặc biệt này của Cyril Northcote Parkinson là một nguyên tắc rộng hơn, hoàn toàn xoay quanh việc lập trình và hoạt động theo Luật 90-90: công việc mất bao lâu bằng thời gian bạn cần để ăn trong suốt thời gian bạn có. Trong phát triển phần mềm, việc “hoàn thành sớm” thực sự là một điều viển vông.
Định luật Brook
Chúng ta có một câu tục ngữ tương ứng chính xác với quy luật này, nhưng tôi sẽ không viết nó ra đây. Nói chung, luật quy định rằng quy trình phần mềm càng có nhiều nhân lực thì thời gian viết mã càng lâu. Điều này được giải thích là do mọi người đều phải làm cùng một công việc, kéo dài thời gian quan liêu cần thiết để vượt qua một cuộc khủng hoảng có thể xảy ra và đồng nghĩa với việc phải thảo luận nhiều hơn.
Nguồn : https://webrazzi.com/2018/01/25/duymamis-olabilEĞİniz-absurt-programlama-ilkeleri/
