Đây là bài share được dịch từ bài viết của tác giả Anna Monus (https://www.hongkiat.com/blog/code-optimization-coding-antipatterns/). Trong bài share này, có một số trong những chỗ được mình sửa đổi, bổ sung cập nhật để mang đến phù hợp.Bạn vẫn xem: Hardcoded là gì


*

Thiết kế phong cách thiết kế của một website hay 1 ứng dụng, hoặc tùy chỉnh một coding workflow tác dụng thường xuyên khiến bọn họ phải đương đầu với những vấn đề nan giải, thường xuyên xuyên gặp phải. Chúng ta không cần thiết phải giải quyết những vấn đề thi công này từ số lượng 0, bởi ta hoàn toàn có thể tái sử dụng được những giải pháp ở cấp độ kiến trúc cũng tương tự những đoạn code ở tầng vi mô.

Bạn đang xem: Hardcoded là gì

Design patterns là trong số những giải pháp tái sử dụng trong một số trường hợp duy nhất định, hoàn toàn có thể hữu ích để xử lý những sự cố kỉnh thường xảy ra và có thể giúp chúng ta tối ưu phần nhiều đoạn codes của mình.


*

Mặc mặc dù Design patterns là phương tiện hoàn hảo để cải thiện quy trình trở nên tân tiến của bọn chúng ta bằng phương pháp sử dụng những công thức đã được kiểm chứng tốt. Mặc dù nhiên, đôi lúc những thiết kế patterns kia cũng đem về những hậu quả tiêu cực so với chúng. Thời điểm này, chúng được gọi là mọi Antipatterns.

Antipatterns là gì?

Thuật ngữ "antipatterns" mở ra lần trước tiên trong một cuốn sách có tên AntiPatterns vào năm 1998.

Nó đề cập đến những chiến thuật tái thực hiện mà ban sơ trông có vẻ hữu ích, nhưng dần sau đó, chúng lại trở nên vô ích hơn là lợi.

Điều này có thể xảy ra bởi nhiều nguyên nhân khác nhau, ví như nếu chúng ta không thực hiện những patterns đúng bối cảnh, thiết lập đặt, tuyệt thời gian phù hợp (các giải pháp có công dụng trong thừa khứ chưa phải lúc nào cũng vận động đúng ở thời gian hiện tại), hoặc giữa những trường vừa lòng xấu rộng là tổng thể mô hình đã không tốt ngay từ khi ban đầu rồi (>""Antipatterns cũng hay được call là những quy mô thất bại. Tuy nhiên, tin vui là họ hoàn toàn hoàn toàn có thể nhận biết và nên tránh chúng.

Trong nội dung bài viết này, tôi sẽ ra mắt qua cho các bạn 10 antipatterns phổ cập hay gặp phải trong quá trình cải tiến và phát triển web. (Chú ý rằng phần nhiều antipatterns tôi liệt kê dưới đây không hoàn toàn giống với đa số gì bạn có thể tìm thấy trong cuốn sách tôi sẽ đề cập ở trên).

10 Antipatterns phổ biến

1. Premature Optimization (Tối ưu sớm)

Thời điểm tốt là một trong những yếu tố quan trọng trong việc tối ưu hóa các đoạn codes. Nếu họ để ý tới các hiệu quả nhỏ và buổi tối ưu hóa bọn chúng quá nhanh chóng trong quy trình phát triển, trước khi chúng ta biết đúng đắn những điều cần làm, rất bao gồm thể chúng ta sẽ dễ ợt mắc nên antipattern "Tối ưu sớm".


*

Theo câu nói danh tiếng của Donald Knuth: "Tối ưu mau chóng là gốc rễ của đông đảo điều ác", nó hoàn toàn có thể hơi bị cường hóa lên một chút, nhưng tất cả thể cho thấy rằng những vụ việc nghiêm trọng về về tối ưu hóa sớm hoàn toàn có thể gây ra trong tương lai như thế nào.

Nếu chúng ta tối ưu hóa hiệu năng trước lúc xây dựng một kiến trúc hiệu quả, nó rất có thể gây ra codes trở cần khó đọc, việc debug và gia hạn khó khăn hơn, cùng những đoạn codes vượt bị đẩy vào mã nguồn của chúng ta.

Một ý tưởng giỏi để ngăn ngừa việc về tối ưu mau chóng là tuân theo cơ chế lập trình YAGNI (You Aren’t Gonna Need It), nó khuyên bọn họ nên tuân thủ "cần cái gì thì thêm loại đó", chứ đừng có mà "chắc là về sau sẽ phải đến".

2.Reinventing the Wheel

Reinventing the wheel - Tái phát minh sáng tạo bánh xe rất có thể hiểu nôm mãng cầu là mẫu bánh xe nó vẫn được phát minh sáng tạo từ rất rất lâu rồi, và nó cũng tốt nhất rồi, đừng tất cả mất thời gian đi sáng tạo lại nó nữa

*

Reinventing the wheel không những gây ra lãng phí thời gian, mà còn những giải pháp tùy chọn, đặc biệt là những tác dụng cơ phiên bản hiếm khi tốt hơn mọi chuẩn mà các nhà phát triển hay người tiêu dùng đã demo nghiệm khôn xiết kĩ rồi.

3. Dependency Hell

Trái ngược với "reinventing the wheel", họ có một antipattern không giống cũng phổ cập đó là "dependency hell".

Nếu, thay bởi vì cặm cụi viết phần nhiều thứ từ bỏ đầu, họ lại quá lạm dụng việc áp dụng thư viện mặt thứ ba dựa trên những phiên bạn dạng cụ thể của những thư viện khác. Điều này sẽ khiến cho bạn dễ dãi phải đối mặt với những tình huống khó cai quản mỗi lúc muốn update thư viện, vì nhiều khi những dependencies này sau khi update lại không tương thích với các cái khác.


*

Dependency hell có thể được giải quyết bằng cách sử dụng những package managers có khả năng update thông minh những dependencies để chúng vẫn có thể tương ưa thích được cùng với nhau. Nếu họ vấp phải rất nhiều vấn đề, câu hỏi refactoring cũng có thể là một ý tưởng hay.

4. Spaghetti Code

Kết quả của một xây đắp kiến trúc kém là 1 trong những đống codes ck chất lên nhau y như một chén mì Spaghetti vậy, khôn xiết rối rắm và phức tạp. Phần đa Spaghetti codes rất khó để gọi và số đông khó hoàn toàn có thể hiểu được nó hoạt động như chũm nào (>"Don"t Repeat Yourself (DRY), thay vì tạo ra giải pháp giải quyết vấn đề, bạn lại đi gom nhóp từng mẩu codes hết nơi này mang đến chỗ khác, sau đó chỉnh sửa lại nó cho cân xứng với ngữ cảnh.


Kết quả của phương thức này là chúng ta có những đoạn codes bị lặp đi lặp lại, vì hầu hết chúng chỉ không giống nhau ở một vài ba điểm nhỏ.

Copy và paste programming không những thấy ở đầy đủ lập trình viên mới, ngoài ra ở hầu hết lập trình viên đã bao gồm kinh nghiệm, bởi vì nhiều người trong các họ có xu hướng sử dụng đa số đoạn codes đã được viết sẵn, kiểm soát kĩ lưỡng của họ cho gần như tác vụ nắm thể, điều này dễ dàng gặp phải sự lặp lại không ao ước muốn.

7. Cargo-Cult Programming

Cái tên “cargo-cult programming” được xuất phát điểm từ một hiện tượng dân tộc bản địa học mang tên "cargo cult". Cargo cults xuất hiện ở nam giới Thái tỉnh bình dương sau rứa chiến vật dụng II, lúc tiếp xúc cùng với nền sang trọng tiên tiến, người phiên bản địa cứ cho rằng các thành phầm như Coca-Cola, TVs, xuất xắc tủ lạnh một trong những tàu chở hàng sở hữu lên đảo, đa số được tạo bởi những quyền lực siêu nhiên, và họ tin rằng mỗi khi tiến hành những nghi lễ ma thuật giống như như phong tục của bạn phương Tây, những thùng chất đầy hàng hóa đó đang lại xuất hiện trở lại.


Antipattern này cũng đều có những biểu hiện tương trường đoản cú như vậy. Ta thực hiện những frameworks, thư viện, giải pháp, hay những design patterns,...có lợi cho việc đó ta, mà lại không thực sự hiểu trên sao họ cần bắt buộc dùng cho chúng xuất xắc những technology đó vận động ra sao.

Cargo cult programming xẩy ra ở đa số lập trình viên ko có kĩ năng hoặc là xây dựng viên new (hoặc là những người thiếu khả năng về phương diện nào đó), họ xào nấu những mã nguồn từ chỗ này cho nơi không giống trong vận dụng mà phần đông ít hoặc không hiểu biết biết về chân thành và ý nghĩa thật sự của chúng. Antipattern này không chỉ tệ vì khiến cho ứng dụng của bọn họ bị "bơm căng phồng", nhưng mà còn có thể dễ dàng đưa đầy đủ lỗi bắt đầu vào mã nguồn của chúng ta.

8. Lava Flow

Chúng ta nói tới "Lava flow" antipattern mọi khi cần buộc phải xử lý những đoạn mã codes vượt hoặc có quality thấp nhưng dường như không thể tách rời với ứng dụng, nhưng bọn họ không hoàn toàn hiểu được bọn chúng có tác dụng gì hoặc tác động của chúng đến toàn bộ ứng dụng như vậy nào. Do vậy, việc loại trừ chúng là một trong việc hết sức rủi ro.

Điều này thường xuyên xảy ra với hầu như legacy codes, hoặc là khi đoạn codes này được viết bởi những người khác (thường thiếu tài liệu chính xác), hay là khi dự án được đưa từ quá trình development quý phái production thừa nhanh.

Cái thương hiệu của antipattern này miêu tả sự tương đương với dung nham núi lửa, ban sơ thì dịch chuyển nhanh, trôi chảy cạnh tranh phòng ngừa, nhưng tiếp nối thì cứng lại cùng khó các loại bỏ.


Trên lý thuyết, ta rất có thể loại quăng quật lava flows sau khi đã kiểm tra và refactoring kĩ lưỡng, nhưng mà trong thực tế, việc triển khai nó ngoài ra rất trở ngại hoặc thậm chí còn là không thể. Vì lava flows thường xuyên có ngân sách thực hiện nay cao, nên giỏi hơn hết để ngăn ngừa chúng là ta tùy chỉnh cấu hình được bản vẽ xây dựng thiết kế giỏi và một workflow làm cho việc tác dụng ngay từ lúc đầu ^_^.

9. Hard Coding

"Hard coding" là 1 antipattern được nói tới rất nhiều trong số những cuốn sách về phát triển web ngay ở lời nói đầu. Hard coding xẩy ra khi họ lưu trữ những cấu hình hoặc là tài liệu đầu vào (ví dụ như những đường dẫn file, remote host name hay là một đoạn văn phiên bản ở ngôn ngữ ví dụ nào đó) sinh hoạt trong mã nguồn áp dụng thay vị lưu chúng ở giữa những file cấu hình, database, user input đầu vào hay từ 1 external api nào đó.


Vấn đề chạm mặt phải ở đấy là những hard code đó sẽ chỉ hoạt động chính xác trong một môi trường nhất định nào đó, và khi mà đk thay đổi, chúng sẽ không hề hoạt động đúng chuẩn nữa.

Ví dụ như, ở môi trường thiên nhiên development, bạn sử dụng một s3-bucket có tên s3-foo-development, tuy thế ở môi trường xung quanh production các bạn lại sử dụng một s3-bucket khác có tên s3-foo-production, hãy thử tưởng tượng, các s3 access key đã có fix cứng làm việc trong code rồi thì làm sao bạn có thể sử dụng 2 s3-bucket không giống nhau trên 2 môi trường khác biệt như vậy. Cách giải quyết và xử lý ở đó là bạn đề xuất lưu đông đảo s3 access key đó ở trong biến môi trường xung quanh cho từng môi trường thiên nhiên cụ thể.

10. Soft Coding

Nếu như cứ cố gắng quá mức nhằm tránh hard coding, bạn cũng có thể vô tình va trán với một antipattern trái lại với nó điện thoại tư vấn là "soft coding".

Trong soft coding, bọn họ đưa đều thứ nhưng đáng ra nó phải được để ở trong mã nguồn ứng dụng ra phần nhiều tài nguyên mặt ngoài, ví dụ bọn họ lưu trữ business súc tích trong database ==". Vì sao phổ biến nhất mà họ thường làm cho thế, là do băn khoăn lo lắng những business rules sẽ đổi khác trong tương lai, cùng lúc đó sẽ phải viết lại codes.

Trong phần nhiều trường hợp rất đoan, một vận dụng với đông đảo soft coded có thể trở nên quá trừu tượng và tinh vi đến mức gần như không thể phát âm được nó (đặc biệt là so với những thành viên bắt đầu vào team), cùng cực kỳ khó để debug cùng bảo trì.

Xem thêm: Pm2.5 Là Gì - Tìm Hiểu Bụi Mịn Pm 1

Kết luận

Bài chia sẻ trên đã trình làng qua mọi Antipatterns mà bọn họ thường phạm phải trong vượt trình cải tiến và phát triển ứng dụng cũng như cách để khắc phục chúng. Mong muốn bạn hiểu sẽ để ý để tránh phạm phải chúng trong sự nghiệp lập trình của bản thân mình nhé ^_^.