Giới thiệu về chống mẫu

Anti-patterns hoàn toàn ngược lại với pattern. Hãy nhớ lại rằng các mẫu thiết kế là ví dụ về thực hành lập trình tốt, nghĩa là các mẫu để giải quyết các vấn đề nhất định. Nhưng các phản mẫu hoàn toàn trái ngược với chúng, đó là các mẫu sai lầm mắc phải khi giải quyết các vấn đề khác nhau.

Một phần của thực hành lập trình tốt chính xác là tránh các mẫu chống đối. Đừng nghĩ rằng đây là một mớ lý thuyết rác rưởi khó hiểu - đây là những vấn đề cụ thể mà hầu hết mọi nhà phát triển đều gặp phải. Ai nhận thức được, anh ta được trang bị vũ khí!

Hãy xem xét một số anti-pattern phổ biến ở những người mới bắt đầu:

  • Số ma thuật và chuỗi
  • lớp thần
  • tối ưu hóa sớm
  • sự ra đời của chiếc xe đạp
  • Phát minh ra xe đạp một bánh

Số ma thuật và chuỗi

Số ma thuật là một hằng số được sử dụng trong mã cho một thứ gì đó (thường là nhận dạng dữ liệu), bản thân số đó không có ý nghĩa gì nếu không có nhận xét tương ứng. Các con số hoàn toàn không có ngữ nghĩa.

Khi các con số bắt đầu xuất hiện trong mã dự án của bạn, ý nghĩa của chúng không rõ ràng, điều này rất tệ. Một lập trình viên không phải là tác giả của mã như vậy sẽ gặp khó khăn trong việc giải thích cách thức hoạt động của nó. Theo thời gian, ngay cả tác giả của mật mã với những con số kỳ diệu cũng không thể giải thích được.

Java webinar

Các con số làm cho mã khó hiểu và cấu trúc lại. Những lý do chính cho lỗi này là sự vội vàng trong quá trình phát triển và thiếu thực hành lập trình. Phản mẫu này nên được loại bỏ từ trong trứng nước bằng cách quy định việc sử dụng các hằng số trước khi bắt đầu phát triển.

Để giải quyết vấn đề này, bạn cần tạo một biến có tên giải thích mục đích của hằng số và gán cho nó giá trị mong muốn.

lớp thần

Đối tượng thần thánh là một anti-pattern khá phổ biến đối với các nhà phát triển OOP. Một đối tượng như vậy đảm nhận quá nhiều chức năng và/hoặc lưu trữ gần như toàn bộ dữ liệu. Kết quả là, chúng tôi có một mã không di động, hơn nữa, rất khó hiểu.

Ngoài ra, mã như vậy khá khó bảo trì, vì toàn bộ hệ thống hầu như chỉ phụ thuộc vào nó. Lý do cho lỗi này: sự kém cỏi của nhà phát triển, một nhà phát triển đảm nhận phần lớn công việc (đặc biệt khi khối lượng công việc vượt quá mức kinh nghiệm của nhà phát triển đó).

Cần phải đối phó với cách tiếp cận này bằng cách chia các nhiệm vụ thành các nhiệm vụ con mà các nhà phát triển khác nhau có thể giải quyết.

tối ưu hóa sớm

Tối ưu hóa sớm là tối ưu hóa được thực hiện trước khi lập trình viên có tất cả thông tin cần thiết để đưa ra quyết định sáng suốt về địa điểm và cách thức thực hiện.

Trong thực tế, rất khó để dự đoán nơi nút thắt cổ chai sẽ xảy ra. Nỗ lực tối ưu hóa trước khi có kết quả thực nghiệm sẽ dẫn đến độ phức tạp của mã và xuất hiện lỗi, nhưng sẽ không mang lại bất kỳ lợi ích nào.

Làm sao để tránh? Đầu tiên, hãy viết mã rõ ràng, dễ đọc, hoạt động được bằng các thuật toán và công cụ nổi tiếng và đã được chứng minh. Nếu cần, hãy sử dụng các công cụ định hình để tìm các nút thắt cổ chai. Dựa vào các phép đo, không phỏng đoán và giả định.

Ví dụ và tính năng

Bộ nhớ đệm trước khi lập hồ sơ. Sử dụng các kinh nghiệm phức tạp và chưa được chứng minh thay vì các thuật toán chính xác về mặt toán học. Một lựa chọn các khung mới, chưa được kiểm tra có thể hoạt động sai khi tải.

khó khăn là gì

Không dễ để xác định khi nào quá trình tối ưu hóa còn quá sớm. Điều quan trọng là phải chừa chỗ cho sự phát triển trước. Bạn cần chọn các giải pháp và nền tảng cho phép bạn dễ dàng tối ưu hóa và phát triển. Ngoài ra, đôi khi tối ưu hóa sớm được sử dụng như một cái cớ cho mã xấu. Ví dụ: họ chỉ sử dụng thuật toán O(n2) vì thuật toán đó sẽ khó hơn O(n).

sự ra đời của chiếc xe đạp

Ý nghĩa của mô hình chống đối này là lập trình viên phát triển giải pháp của riêng mình cho một vấn đề mà các giải pháp đã tồn tại và thường là những giải pháp thành công hơn nhiều.

Nhà phát triển cho rằng mình thông minh hơn nên cố gắng đưa ra giải pháp của riêng mình cho từng nhiệm vụ, bất chấp kinh nghiệm của những người đi trước. Thông thường, điều này chỉ dẫn đến mất thời gian và giảm hiệu quả của lập trình viên. Rốt cuộc, giải pháp có thể không tối ưu, nếu được tìm thấy.

Tất nhiên, bạn không thể loại bỏ hoàn toàn khả năng có một giải pháp độc lập, vì điều này sẽ dẫn đến việc sao chép-dán chương trình theo cách trực tiếp. Nhà phát triển phải điều hướng các nhiệm vụ có thể xuất hiện trước mắt để giải quyết chúng một cách thành thạo, sử dụng các giải pháp làm sẵn hoặc phát minh ra giải pháp của riêng mình.

Rất thường xuyên, lý do cho sự phản mẫu này đơn giản là do thiếu thời gian. Và thời gian là tiền bạc.

Phát minh ra xe đạp bánh vuông

Phản mẫu này có liên quan rất chặt chẽ đến việc chỉ đơn giản là phát minh lại bánh xe - tạo ra giải pháp tồi của riêng bạn khi có giải pháp tốt hơn.

Việc chống mẫu này mất gấp đôi thời gian: đầu tiên, thời gian dành cho việc phát minh và triển khai giải pháp của riêng bạn, sau đó là tái cấu trúc hoặc thay thế giải pháp đó.

Lập trình viên phải nhận thức được sự tồn tại của các giải pháp khác nhau cho các phạm vi nhiệm vụ nhất định, được hướng dẫn bởi những ưu điểm và nhược điểm của chúng.

Tất cả các vấn đề mà bạn sẽ gặp phải với tư cách là một lập trình viên có thể được chia thành hai phần:

  • những người thông minh đã giải quyết vấn đề này 30 năm trước
  • những người thông minh đã giải quyết vấn đề này 50 năm trước

Hầu hết các vấn đề lập trình đã được giải quyết thành công trước cả khi bạn được sinh ra . Không cần phải phát minh ra bất cứ điều gì - chỉ cần nghiên cứu kinh nghiệm của người khác (đây là mục đích viết sách).

Vào năm 2022, chúng ta có thể tổ chức các ngày sinh nhật sau:

  • Ngôn ngữ lập trình
    • Ngôn ngữ C bước sang tuổi 50 (1972)
    • Ngôn ngữ Java bước sang tuổi 27 (1995)
    • Python bước sang tuổi 31 (1991)
  • Sự liên quan
    • Internet bước sang tuổi 39 (1983)
    • Điện thoại di động bước sang tuổi 49 (1973)
    • Tin nhắn SMS đầu tiên được gửi cách đây 30 năm (1992)
  • hoa văn
    • Mẫu MVC bước sang tuổi 44 (1978)
    • SQL được phát minh cách đây 48 năm (1974)
    • Đậu Java được phát minh cách đây 26 năm (1996)
  • thư viện
    • Hibernate được phát minh cách đây 21 năm (2001)
    • Mùa xuân được phát minh cách đây 20 năm (2002)
    • Tomcat phát hành 23 năm trước (1999)
  • hệ điều hành
    • Unix được phát hành cách đây 51 năm (1971)
    • Windows đã nhìn thấy ánh sáng 37 năm trước (1985)
    • Mac OS phát hành 21 năm trước (2001)

Và tất cả những thứ này không chỉ được phát minh ra, chúng được phát triển như một giải pháp cho những vấn đề rất phổ biến và phù hợp vào thời điểm đó.