Phát triển web 10 loại tiền mã hóa bạn phải tránh
Thiết kế kiến trúc của một trang web hoặc một ứng dụng hoặc thiết lập một quy trình mã hóa hiệu quả thường xuyên khiến chúng ta phải đối phó với các vấn đề định kỳ. Chúng ta không nhất thiết phải giải quyết các vấn đề thiết kế phần mềm này từ đầu, như giải pháp ở cấp độ kiến trúc có thể được tái sử dụng cùng một cách đoạn mã ở cấp độ vi mô.
Các mẫu thiết kế nói chung giải pháp tái sử dụng đối với các kịch bản nhất định, có thể có ích để giải quyết các vấn đề thường xảy ra, và có thể giúp chúng tôi tối ưu hóa mã của chúng tôi.
Mặc dù các mẫu thiết kế là phương tiện tuyệt vời để cải thiện quá trình phát triển của chúng tôi bằng cách sử dụng các công thức được kiểm tra tốt, đôi khi chúng tôi cũng có thể gặp trục trặc với chúng. Chúng được gọi là antipotype.
Antipotypes là gì?
Thuật ngữ “antipotype” đã được đặt ra trong một cuốn sách có tên AntiPotypes vào năm 1998. Nó đề cập đến giải pháp tái sử dụng ban đầu có vẻ hữu ích, nhưng sau đó hóa ra làm hại nhiều hơn lợi.
Điều này có thể xảy ra vì những lý do khác nhau, ví dụ: nếu chúng ta không sử dụng các mẫu trong bối cảnh, cài đặt hoặc thời gian phù hợp (các giải pháp hiệu quả trong quá khứ có thể không luôn luôn hoạt động trong hiện tại) hoặc trong các trường hợp khác, toàn bộ mô hình chỉ là xấu từ đầu.
Antipotype cũng thường được gọi mô hình thất bại. Tin tốt là nó có thể nhận ra và tránh chúng.
Trong bài đăng này, chúng tôi sẽ xem xét 10 loại tiền mã hóa phổ biến trong phát triển web có thể khiến chúng ta lầm tưởng rằng chúng ta có mã được tối ưu hóa tốt. (Lưu ý rằng các antipotype được liệt kê trong bài viết này không nhất thiết giống như những gì bạn có thể tìm thấy trong cuốn sách được đề cập ở trên.)
1. Tối ưu hóa sớm
Thời gian tốt là một yếu tố quan trọng trong tối ưu hóa mã. Chúng ta có thể dễ dàng tái tạo các antipotype của “tối ưu hóa sớm”, nếu chúng ta chú ý đến hiệu quả nhỏ và tối ưu hóa cho chúng quá sớm trong quá trình phát triển, trước khi chúng ta biết chính xác những gì chúng ta muốn làm.
Theo câu nói nổi tiếng của Donald Knuth “tối ưu hóa sớm là gốc rễ của mọi tội lỗi“, đó có thể là một cường điệu, nhưng vẫn cho thấy các vấn đề nghiêm trọng tối ưu hóa sớm có thể gây ra như thế nào.
Nếu chúng tôi tối ưu hóa hiệu suất trước khi thiết lập một kiến trúc hiệu quả, chúng tôi có thể khả năng đọc mã thấp hơn, chế tạo gỡ lỗi và bảo trì khó hơn, và thêm các phần thừa mã của chúng tôi.
Để ngăn chặn tối ưu hóa sớm, bạn nên tuân thủ nguyên tắc lập trình YAGNI (You Ar't Gonna Need It), khuyên bạn nên “luôn thực hiện mọi thứ khi bạn thực sự cần chúng, không bao giờ khi bạn thấy trước rằng bạn cần chúng.”
2. Phát minh lại bánh xe
Các “phát minh lại bánh xe” antipotype đôi khi cũng được gọi là “thiết kế trong chân không”. Nó xảy ra khi chúng ta muốn làm mọi thứ một mình và viết mọi thứ từ đầu, mà không tìm kiếm các phương thức, API hoặc thư viện đã có sẵn.
Phát minh lại bánh xe không chỉ là một việc lãng phí thời gian, mà là giải pháp tùy chỉnh, đặc biệt là cho các chức năng cơ bản, hiếm khi tốt như tiêu chuẩn đã được thử nghiệm bởi nhiều nhà phát triển và người dùng.
3. Địa ngục phụ thuộc
Sự đối lập của “phát minh lại bánh xe” antipotype là một antipotype phổ biến khác được gọi là “địa ngục phụ thuộc”.
Nếu, thay vì viết mọi thứ từ đầu, chúng tôi sử dụng quá nhiều thư viện bên thứ ba dựa trên các phiên bản cụ thể của các thư viện khác, chúng ta có thể dễ dàng gặp phải tình huống khó quản lý khi muốn cập nhật, vì trong nhiều trường hợp, các phụ thuộc này không tương thích với nhau.
Địa ngục phụ thuộc có thể được giải quyết bằng cách sử dụng các trình quản lý gói có thể thông minh cập nhật phụ thuộc lẫn nhau. Nếu chúng ta bị quá tải bởi vấn đề, tái cấu trúc cũng có thể là một ý tưởng tốt.
4. Mã Spaghetti
“Mã Spaghetti” có lẽ là antipotype mã hóa nổi tiếng nhất. Nó mô tả một ứng dụng khó gỡ lỗi hoặc sửa đổi do thiếu kiến trúc phù hợp.
Kết quả của thiết kế phần mềm kém là một loạt các mã có cấu trúc tương tự như một bát mì spaghetti, tức là. rối và rối. Khả năng đọc mã spaghetti rất thấp và thường là một nhiệm vụ gần như không thể để hiểu chính xác nó hoạt động như thế nào.
Mã Spaghetti thường bắt nguồn từ kết hợp các thực hành mã hóa xấu khác nhau, chẳng hạn như mã không chứa các khối điều kiện thích hợp, có nhiều câu lệnh goto, ngoại lệ và luồng, chứa các phần thuộc về nơi khác, có mối quan hệ tối thiểu giữa các đối tượng, có các hàm hoặc phương thức không thể được sử dụng lại hoặc không được ghi lại đúng cách hoặc ở tất cả.
5. Lập trình bằng hoán vị
“Lập trình bằng hoán vị” hoặc là “lập trình một cách tình cờ” xảy ra khi chúng ta cố gắng tìm giải pháp cho một vấn đề bằng cách thử nghiệm liên tục các sửa đổi nhỏ, thử nghiệm và đánh giá từng cái một, và cuối cùng thực hiện giải pháp đầu tiên.
Lập trình bằng hoán vị có thể dễ dàng giới thiệu các lỗi mới vào mã của chúng tôi, tệ hơn nữa, chúng là những lỗi chúng ta không nhất thiết phải nhận ra ngay lập tức. Trong nhiều trường hợp, cũng không thể lường trước được liệu giải pháp có hoạt động cho tất cả các tình huống có thể hay không.
6. Sao chép và dán lập trình
“Sao chép và dán chương trình” xảy ra khi chúng tôi không tuân theo nguyên tắc mã hóa Đừng lặp lại chính mình (DRY) và thay vì tạo các giải pháp chung, chúng tôi chèn các đoạn mã đã có vào các vị trí khác nhau và sau đó chỉnh sửa chúng để phù hợp với bối cảnh cụ thể.
Thực hành này dẫn đến một mã có tính lặp lại cao, vì các phần mã được chèn thường chỉ khác nhau ở những khác biệt nhỏ.
Sao chép và dán lập trình không chỉ được cam kết bởi các nhà phát triển mới làm quen, mà cả các lập trình viên có kinh nghiệm, vì nhiều người trong số họ có xu hướng sử dụng các đoạn mã được viết sẵn, được kiểm tra tốt của riêng họ cho các tác vụ cụ thể, dễ dẫn đến sự lặp lại ngoài ý muốn.
7. Lập trình vận chuyển hàng hóa
Tên của “lập trình hàng hóa” xuất phát từ một hiện tượng dân tộc học cụ thể được gọi là “giáo phái hàng hóa”. Các hầm hàng xuất hiện ở Nam Thái Bình Dương sau Thế chiến thứ hai, khi liên hệ bắt buộc với các nền văn minh tiên tiến khiến người ta nghĩ rằng các sản phẩm được sản xuất, như Coca-Cola, TV và tủ lạnh được đưa bởi các tàu chở hàng đến đảo, được tạo ra bởi siêu nhiên phương pháp; và nếu họ thực hiện các nghi thức ma thuật tương tự như phong tục của người phương Tây, hàng hóa chứa đầy hàng hóa sẽ trở lại.
Khi chúng tôi cam kết các mô hình lập trình tôn giáo hàng hóa, về cơ bản chúng tôi cũng làm như vậy. Chúng tôi sử dụng khung, thư viện, giải pháp, mẫu thiết kế, v.v ... hoạt động tốt cho người khác, mà không hiểu tại sao chúng ta làm như vậy, hoặc công nghệ nói chính xác hoạt động như thế nào.
Trong nhiều trường hợp, các nhà phát triển chỉ Nghi thức làm những gì là hông tại thời điểm đó mà không có bất kỳ mục đích thực sự. Cách làm này không chỉ xấu vì nó làm cho ứng dụng của chúng ta bị phình to, mà còn có thể dễ dàng đưa các lỗi mới vào mã của chúng ta.
8. Dòng dung nham
Chúng tôi nói về “dòng dung nham” antipotype khi chúng ta cần đối phó với mã có các bộ phận dư thừa hoặc chất lượng thấp cái đó dường như là không thể thiếu đối với chương trình, nhưng chúng ta hoàn toàn không hiểu nó làm gì hoặc nó ảnh hưởng đến toàn bộ ứng dụng như thế nào. Điều này làm cho nó nguy hiểm để loại bỏ nó.
Nó thường xảy ra với mã di sản, hoặc khi mã được viết bởi người khác (thường không có tài liệu phù hợp) hoặc khi dự án chuyển quá nhanh từ giai đoạn phát triển sang giai đoạn sản xuất.
Tên của antipotype xuất phát từ sự xuất hiện của nó với dung nham đến từ núi lửa, tức là lúc đầu nó di chuyển nhanh và trôi chảy mà không cần quá nhiều biện pháp phòng ngừa, nhưng sau đó nó đông cứng lại và trở nên khó loại bỏ.
Về lý thuyết, chúng ta có thể thoát khỏi dòng dung nham với Thử nghiệm rộng rãi và tái cấu trúc, nhưng trong thực tế, việc thực hiện thường khó khăn hoặc thậm chí là không thể. Vì dòng dung nham thường có chi phí hiệu suất cao, tốt hơn hết là ngăn chặn chúng bằng cách thiết lập kiến trúc được thiết kế tốt và luồng công việc âm thanh ngay từ đầu.
9. Mã hóa cứng
“Mã hóa cứng” là một antipotype nổi tiếng mà hầu hết các sách phát triển web cảnh báo chúng ta ngay trong lời nói đầu. Mã hóa cứng là thực hành không may trong đó chúng tôi lưu trữ cấu hình hoặc dữ liệu đầu vào, chẳng hạn như đường dẫn tệp hoặc tên máy chủ từ xa, trong mã nguồn thay vì lấy nó từ tệp cấu hình, cơ sở dữ liệu, đầu vào của người dùng hoặc nguồn bên ngoài khác.
Vấn đề chính với mã cứng là nó chỉ hoạt động đúng trong một môi trường nhất định, và tại bất cứ khi nào điều kiện thay đổi, chúng ta cần sửa đổi mã nguồn, thường ở nhiều nơi riêng biệt.
10. Mã hóa mềm
Nếu chúng ta cố gắng hết sức để tránh cạm bẫy của mã hóa cứng, chúng ta có thể dễ dàng chạy vào một phản hạt khác gọi là “mã hóa mềm”, điều này hoàn toàn ngược lại.
Trong mã hóa mềm, chúng tôi đặt những thứ nên có trong mã nguồn vào các nguồn bên ngoài, ví dụ chúng tôi lưu trữ logic kinh doanh trong cơ sở dữ liệu. Lý do phổ biến nhất khiến chúng tôi làm như vậy là vì sợ rằng các quy tắc kinh doanh sẽ thay đổi trong tương lai, do đó chúng tôi sẽ cần phải viết lại mã.
Trong trường hợp cực đoan, một chương trình mã hóa mềm có thể trở nên trừu tượng và phức tạp đến mức gần như không thể hiểu được nó (đặc biệt là cho các thành viên nhóm mới), và cực kỳ khó bảo trì và gỡ lỗi.
