HARDCODE LÀ GÌ

     

Đây là bài chia sẻ được dịch từ nội dung 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 vài chỗ được mình sửa đổi, bổ sung cập nhật để đến phù hợp.Bạn đã xem: Hardcoded là gì


*

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

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

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


*

Mặc mặc dù Design patterns là phương tiện tuyệt đối để nâng cấp quy trình trở nên tân tiến của chúng ta bằng cách sử dụng những bí quyết đã được kiểm triệu chứng tốt. Mặc dù nhiên, đôi khi những design patterns kia cũng mang lại những hậu quả tiêu cực đối với chúng. Lúc này, chúng được hotline là các Antipatterns.

Antipatterns là gì?

Thuật ngữ "antipatterns" xuất hiện thêm lần trước tiên trong một cuốn sách với tên AntiPatterns vào khoảng thời gian 1998.

Nó đề cập cho những giải pháp tái thực hiện mà ban đầu trông có vẻ hữu ích, tuy nhiên 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 vị nhiều lý do khác nhau, ví như nếu chúng ta không sử dụng những patterns đúng bối cảnh, tải đặt, tuyệt thời gian tương xứng (các giải pháp có tác dụng trong vượt khứ không hẳn lúc làm sao cũng hoạt động đúng ở thời gian hiện tại), hoặc giữa những trường thích hợp xấu rộng là cục bộ mô hình đang không giỏi ngay từ bỏ khi bắt đầu rồi (>""Antipatterns cũng thường xuyên được gọi là những mô hình thất bại. Mặc dù nhiên, tin vui là chúng ta hoàn toàn rất có thể nhận biết và nên tránh chúng.

Trong bài viết này, tôi sẽ giới thiệu qua cho chúng ta 10 antipatterns phổ cập hay gặp mặt phải trong thừa trình trở nên tân tiến web. (Chú ý rằng phần đông antipatterns tôi liệt kê tiếp sau đây không hoàn toàn giống với gần như gì bạn có thể tìm thấy trong cuốn sách tôi đang đề cập ngơi nghỉ 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ố đặc biệt quan trọng trong vấn đề tối ưu hóa những đoạn codes. Nếu bọn họ để ý tới những hiệu quả nhỏ và buổi tối ưu hóa chúng quá sớm trong quy trình phát triển, trước khi bọn họ biết chính xác những điều cần làm, rất gồm thể bọn họ sẽ dễ ợt mắc đề xuất antipattern "Tối ưu sớm".


*

Theo câu nói lừng danh của Donald Knuth: "Tối ưu mau chóng là nền tảng gốc rễ của số đông đ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 bao gồm thể cho biết thêm rằng những sự việc nghiêm trọng về tối ưu hóa sớm rất có thể gây ra trong tương lai như vậy 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 bản vẽ xây dựng hiệu quả, nó hoàn toàn có thể gây ra codes trở đề xuất khó đọc, việc debug và duy trì khó khăn hơn, cùng những đoạn codes thừa bị đẩy vào mã nguồn của chúng ta.

Một ý tưởng xuất sắc để ngăn ngừa việc về tối ưu nhanh chóng là tuân theo nguyên tắc lập trình YAGNI (You Aren’t Gonna Need It), nó khuyên chúng ta nên tuân hành "cần vật gì thì thêm loại đó", chứ đừng tất cả mà "chắc là về sau sẽ yêu cầu đến".

2.Reinventing the Wheel

Reinventing the wheel - Tái phát minh sáng tạo bánh xe có thể hiểu nôm na là chiếc bánh xe pháo nó sẽ được sáng tạo từ rất mất thời gian rồi, và nó cũng tốt nhất có thể rồi, đừng gồm mất thời hạn đi phát minh lại nó nữa

*

Reinventing the wheel không chỉ gây ra lãng phí thời gian, ngoại giả những chiến thuật tùy chọn, đặc biệt là những tính năng cơ bạn dạng hiếm khi giỏi hơn các chuẩn mà các nhà cải cách và phát triển hay người tiêu dùng đã thử nghiệm khôn xiết kĩ rồi.

3. Dependency Hell

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

Nếu, thay vì chưng cặm cụi viết những thứ từ bỏ đầu, bọn họ lại quá sử dụng quá việc thực hiện thư viện bên thứ ba dựa vào những phiên bản cụ thể của rất nhiều thư viện khác. Điều này sẽ khiến cho bạn thuận tiện phải đương đầu với những tình huống khó thống trị mỗi khi muốn cập nhật thư viện, vì đôi khi những dependencies này sau khi cập nhật lại không tương xứng với các chiếc khác.


*

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

4. Spaghetti Code

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

Xem thêm: Thuyết Minh Về Một Cuốn Sách Hay Nhất, Chia Sẻ Về Một Cuốn Sách Mà Em Yêu Thích (12 Mẫu)


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

Copy and paste programming không chỉ là thấy ở hầu như lập trình viên mới, ngoại giả ở những lập trình viên đã tất cả kinh nghiệm, bởi vì nhiều người trong số họ có xu thế sử dụng hồ hết đoạn codes đã có được viết sẵn, kiểm tra kĩ lưỡng của họ cho phần đa tác vụ nỗ lực thể, vấn đề đó dễ dàng chạm chán 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 khởi đầu từ một hiện tượng dân tộc bản địa học với tên "cargo cult". Cargo cults xuất hiện ở phái nam Thái tỉnh bình dương sau cố kỉnh chiến lắp thêm II, lúc tiếp xúc cùng với nền thanh tao tiên tiến, người phiên bản địa cứ nghĩ rằng các sản phẩm như Coca-Cola, TVs, giỏi tủ lạnh một trong những tàu chở hàng với lên đảo, đông đảo được tạo vì chưng những gia thế siêu nhiên, với họ tin rằng mỗi khi triển khai những nghi lễ ma thuật tương tự như phong tục của tín đồ phương Tây, hầu hết thùng chất đầy sản phẩm & hàng hóa đó đang lại xuất hiện thêm trở lại.


Antipattern này cũng đều có những bộc lộ 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 các design patterns,...có lợi cho việc đó ta, mà lại không thực thụ hiểu tại sao bọn họ cần buộc phải dùng đến chúng tốt những công nghệ đó vận động ra sao.

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

8. Lava Flow

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

Điều này liên tục xảy ra với các legacy codes, hoặc là lúc đ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ủ yếu xác), hoặc là khi dự án được chuyển từ quy trình tiến độ development sang production thừa nhanh.

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


Trên lý thuyết, ta hoàn toàn có thể loại quăng quật lava flows sau thời điểm đã kiểm tra và refactoring kĩ lưỡng, tuy thế trong thực tế, việc thực hiện nó dường như rất khó khăn hoặc thậm chí còn là ko thể. Vì chưng lava flows hay có ngân sách chi tiêu thực hiện tại cao, nên xuất sắc hơn không còn để ngăn chặn chúng là ta thiết lập được phong cách thiết kế thiết kế tốt và một workflow làm việc hiệu quả ngay từ lúc đầu ^_^.

9. Hard Coding

"Hard coding" là một antipattern được nói tới rất nhiều trong số những cuốn sách về cách tân và phát triển web ngay lập tức ở khẩu ca đầu. Hard coding xẩy ra khi bọn họ lưu trữ những thông số kỹ thuật hoặc là tài liệu đầu vào (ví dụ như những đường dẫn file, remote host name hay là 1 đoạn văn bạn dạng ở ngôn ngữ cụ thể nào đó) làm việc trong mã nguồn áp dụng thay bởi vì lưu bọn chúng ở một trong những file cấu hình, database, user input hay xuất phát điểm từ một 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 xung quanh nhất định như thế nào đó, cùng khi mà điều kiện thay đổi, chúng sẽ không còn hoạt động chính xác 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, nhưng mà ở môi trường xung quanh production các bạn lại áp dụng một s3-bucket khác mang tên s3-foo-production, hãy thử tưởng tượng, phần đa s3 access key đã được fix cứng sống trong code rồi thì làm sao chúng ta có thể sử dụng 2 s3-bucket khác biệt trên 2 môi trường không giống nhau như vậy. Cách xử lý ở đấy là bạn bắt buộc lưu rất nhiều s3 access key đó ở vào 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, chúng ta có thể vô tình chạm trán với một antipattern trái lại với nó call là "soft coding".

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

Trong đa số trường hợp rất đoan, một áp dụng với đều soft coded có thể trở nên quá trừu tượng và phức tạp đến mức gần như là 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ỳ cực nhọc để debug với bảo trì.

Xem thêm: Cách Phục Hồi Thư Đã Xóa Trong Gmail Bằng Điện Thoại, Xóa Hoặc Khôi Phục Thư Gmail Đã Bị Xóa

Kết luận

Bài chia sẻ trên đã ra mắt qua rất nhiều Antipatterns mà chúng ta thường phạm phải trong quá trình cải cách và phát triển ứng dụng cũng như cách để khắc phục chúng. Hi vọng bạn đọc sẽ để ý để tránh mắc phải chúng trong sự nghiệp lập trình của chính mình nhé ^_^.