7 chiêu lập trình xấu xí nhưng được việc

Logic là nền tảng của thế giới máy tính, trong đó mọi thứ đâu ra đó, không có chuyện đảo điên hay nhập nhằng như thế giới ngoài đời. Chẳng ai gán "1" cho một ‘bit’ ... Logic là nền tảng của thế giới máy tính, trong đó mọi thứ đâu ra đó, không có chuyện đảo điên hay nhập nhằng như thế giới ngoài đời. Chẳng ai gán "1" cho một ‘bit’ để dùng như "0"; cũng không ai gõ câu lệnh if x = 0 khi điều thực sự muốn là if x! = 0 (x không bằng 0).

Thế nhưng ở cấp độ cao hơn thì khoa học máy tính không rõ ràng như vậy. Một số ý tưởng, cơ chế hoặc kiến trúc không hay nhưng có thể là lựa chọn tốt nhất cho dự án của bạn. Chúng có thể rẻ hơn hoặc nhanh hơn, hoặc dơn giản hơn so với việc làm mọi việc đúng chuẩn. Nói cách khác, đôi khi không hay có nghĩa là đủ tốt.

Đôi khi ý tưởng tồi có cái hay của nó. Nó có thể không phải là phương pháp tốt nhất, nhưng nó có những “tác dụng phụ” tốt đến mức khiến nó được chọn. Nếu buộc phải đi theo một hướng lập trình kém tối ưu, chúng ta có thể tìm cách khai thác “ngọc trong đá”.

Dưới đây là 7 cách thức lập trình thực sự tệ nhưng cũng thường được việc.

Code nhanh và luộm thuộm
Code thiết kế kém và thiếu tài liệu có thể giết chết dự án. Ngay cả khi hệ thống chấp vá của bạn chạy được thì việc duy trì nó cũng sẽ là cơn ác mộng, và bất cứ ai thừa hưởng nó hẳn sẽ nguyền rủa bạn suốt.

Nhưng code viết nhanh và luộm thuộm có cái hay của nó. Trong thực tế, việc theo đuổi code chỉnh chu, thiết kế kỹ lưỡng có thể rất tốn kém. Dĩ nhiên, nếu ngân sách và thời gian cho phép, ai cũng muốn có các dòng code gọn gàng, chỉnh chu. Nhưng không phải ai cũng có điều kiện như vậy.

Hơn nữa, khái niệm gọn gàng, chỉnh chu thường khó xác định. Code gọn gàng của một lập trình viên này có thể quá phức tạp với một lập trình viên khác. Thường việc làm gọn code có nghĩa là thêm các lớp mới để làm rõ chức năng của nó. Việc này có thể khiến thông tin nhanh chóng trở nên thừa mứa. Đôi khi viết code nhanh và luộm thuộm lại tốt hơn so với code "gọn" mà phức tạp đi cùng với tài liệu dài lê thê.

Bất cứ ai từng ngụp lặn qua hàng đống trang code được thiết kế kỹ lưỡng đầy các lớp đều biết đôi khi đoạn code ngắn chỉ với một dữ liệu đầu vào và một mô tả chức năng đơn giản tốt hơn đống tuyệt tác của kỹ thuật và khoa học máy tính. Code tệ nhưng được việc có thể chỉ cần 10 giây là hiểu, còn kiến trúc phức tạp có thể mất vài tuần.

Thuật toán phung phí
Mọi người đều biết những bài học ở trường lớp. Với cấu trúc dữ liệu thông minh, thời gian xử lý sẽ tỷ lệ với kích thước của dữ liệu. Còn cấu trúc dữ liệu kkhông tốt, tốc độ có thể chậm hơn tỷ lệ với luỹ thừa 2 hay thậm chí luỹ thừa 3 của số phần tử dữ liệu. Khi số lượng dữ liệu tăng lên, việc chậm hơn theo cấp số mũ thực sự khủng khiếp. Bài học từ trường lớp không thể bỏ qua: thuật toán kém thật sự chậm.

Vấn đề là các thuật toán thông minh hiệu quả về mặt lý thuyết cũng có thể chậm. Chúng thường đòi hỏi các cấu trúc dữ liệu phức tạp đầy các “con trỏ” và hàng đống giá trị trung gian, chiếm hết bộ nhớ.

Một phần của vấn đề đó là hầu hết các mô hình lý thuyết phân tích hoạt động của các thuật toán với tập dữ liệu thật lớn. Nhưng ngay cả trong thời đại của dữ liệu lớn, chúng ta có thể không được làm việc với tập dữ liệu đủ lớn để tận hưởng tất cả các lợi ích về mặt lý thuyết.

Trong những tính huống như vậy, việc dùng thuật toán luộm thuộm, ngay cả khi nó có khả năng chạy chậm, có thể là một ý tưởng tốt.

Sử dụng máy chủ cơ sở dữ liệu riêng
Khi nói đến hiệu suất phần mềm, tốc độ là quan trọng. Lời khuyên thông thường là: Để tăng tốc độ thông tin liên lạc giữa các lớp của phần mềm, nên đặt cơ sở dữ liệu trên cùng một máy với phần mềm hiển thị kết quả cho người dùng. Nhờ code truy xuất cơ sở dữ liệu và lớp trình bày liên lạc với nhau một cách nhanh chóng, bạn loại bỏ được độ trễ của việc gọi một máy chủ khác.

Nhưng điều này không phải lúc nào cũng đúng, đặc biệt là khi một máy chủ đơn lẻ không thể phục vụ hiệu quả nhu cầu của cả phần trình bày và cơ sở dữ liệu.

Các máy chủ chạy tốt cơ sở dữ liệu thường khác nhiều so với những máy chủ chạy phần giao diện (trình bày), sự khác biệt phụ thuộc vào loại và cấu trúc của cơ sở dữ liệu. Tăng thêm RAM luôn có ích, nhưng chủ yếu khi lập chỉ mục. Các bảng lớn cần nhiều RAM hơn số lượng lớn các bảng nhỏ. Nếu dự định thực hiện nhiều tác vụ JOINS (nối bảng), có lẽ tốt hơn bạn nên đi ngược xu hướng tất-cả-trong-một với máy chủ cơ sở dữ liệu riêng.

Dùng CMS “búa tạ” đập móng tay
Một trong những xu hướng hiện nay là chia nhỏ hệ thống tập trung thành các “tiểu dịch vụ” (microservice) gọn nhẹ. Thay vì xây dựng một cổng thông tin tập trung tất cả dữ liệu, bạn có thể xây dựng hàng chục hoặc hàng trăm dịch vụ web chuyên biệt để trả lời các truy vấn và thu thập những dữ liệu nhất định. Làm vậy bạn có thể tạo, gỡ lỗi và triển khai từng dịch vụ độc lập, thực hiện thay đổi liên tục mà không phải nâng cấp cả hệ thống.

Nhưng sử dụng hệ quản trị nội dung (CMS) to đùng như WordPress hay Drupal cho các tiểu dịch chẳng khác nào sử dụng JSON hay dữ liệu XML chỉ để chỉnh chút cấu hình. Thoạt nhìn điều này có vẻ như một ý tưởng khủng khiếp, nhưng sự phức tạp của CMS chẳng qua chỉ làm chậm hệ thống, vấn đề này có thể giải quyết tương đối dễ dàng bằng cách bổ sung nguồn lực tính toán. Bù lại, cách tiếp cận CMS có thể đẩy nhanh tốc độ phát triển và cải thiện việc gỡ lỗi, và đội ngũ quản trị hệ thống cũng được hưởng phần.

Tích hợp hiển thị với dữ liệu
Một trong những nguyên tắc cốt yếu của thiết kế hiện đại là chia dự án thành ít nhất ba phần: lưu trữ dữ liệu, ra quyết định, và hiển thị hay trình bày. Việc phân chia như vậy cho phép việc thiết kế lại bất kỳ phần nào đơn giản hơn và độc lập với hai phần kia.

Tuy nhiên có nhược điểm, vì tách phần hiển thị khỏi dữ liệu có nghĩa là ứng dụng phải liên tục xử lý lại dữ liệu để phù hợp với bố cục hiển thị hiện tại. Đa phần việc này là lặp lại nếu bố cục không đổi.

Gần đây các nhà kiến trúc phần mềm đã thiết kế lại các định dạng dữ liệu để code hiển thị xử lý dễ dàng hơn. Việc chuyển sang cấu trúc dữ liệu JSON và cơ sở dữ liệu JSON NoSQL chủ yếu nhằm cung cấp dữ liệu trong định dạng mà trình duyệt xử lý dễ dàng hơn. Không hẳn là trộn dữ liệu với code hiển thị mà là làm cho chúng gần gũi nhau hơn.

Thường các ứng dụng sử dụng bộ nhớ đệm (cache) để kết hợp code hiển thị với dữ liệu. Dữ liệu tích hợp với bố cục hiển thị được lưu trữ vào cơ sở dữ liệu để được phục vụ nhiều lần.

Sử dụng nền tảng chưa tối ưu
Việc chọn "sai" kiến trúc hoặc chiến lược cho các mục tiêu tăng trưởng dài hạn từng báo trước cái chết của dự án. Tuy nhiên giờ đây việc cứu vãn lựa chọn ban đầu kém cỏi tương đối dễ dàng, miễn là vẫn có thể thuê thêm nhiều cỗ máy trên mây để giải quyết vấn đề.

Nếu hệ thống máy chủ hoặc cơ sở dữ liệu chạy ì ạch, thường bạn chỉ cần nhấc điện thoại lên và thuê thêm máy móc. Sau đó, khi qua cơn cao trào, bạn có thể trả bớt năng lực tính toán dôi dư. Khi việc thêm máy theo giờ chẳng tốn bao nhiêu, sai lầm kiến trúc không còn là thảm họa.

Tất nhiên, không phải tất cả sai lầm đều có thể sửa chữa bằng cách chi tiền. Một số quyết định tồi tệ có thể dẫn đến sự bùng nổ cấp số mũ khi công ty phát triển. Những sai lầm này có thể nhanh chóng làm bạn phá sản. Còn đơn thuần chọn một cơ sở dữ liệu nặng nề hoặc một bộ lọc phức tạp mà chỉ đơn giản làm chậm gấp đôi thì không phải là vấn đề sinh tử.

Điều quan trọng là tránh tắc nghẽn ở phần lõi, phần quan trọng nhất của thiết kế. Thiết kế các bộ phận riêng biệt và độc lập, đảm bảo chúng không “ngoéo cẳng” nhau tạo ra trạng thái chết cứng. Miễn là kiến trúc lõi không sinh ra tắc nghẽn, các quyết định sai lầm có thể cứu vãn với phần cứng nhanh hơn. Nó không được “đẹp”, nhưng thường có hiệu quả.

Hãy xem Facebook, công ty khởi đầu sử dụng PHP, một trong những công cụ phát triển ứng dụng web đầu tiên đã hơi lạc hậu vào thời điểm Facebook ra mắt. Tuy nhiên đây là vấn đề với các lập trình viên chứ không phải người dùng. Sau đó Facebook đã thúc đẩy phát triển PHP bằng cách tạo ra HHVM, một phiên bản nhanh hơn nhiều truyền cảm hứng cho việc viết lại lõi PHP. Bây giờ Facebook chạy mã cũ nhanh hơn nhiều, và người dùng không biết công ty này đã giải quyết vấn đề lựa chọn nền tảng ban đầu mà vẫn còn khiến cho một số lập trình viên tròn xoe mắt.
Việc chọn một giải pháp tàm tạm thường rẻ hơn so với việc thực hiện cách tiếp cận mới phức tạp.

Giữ lại code cũ
Từng có trường hợp một ứng dụng web được phát triển với những kiểu cách mới nhất và ngôn ngữ lập trình mới nhất (Java, thời bấy giờ). Nhưng cỗ máy tính lớn (mainframe) già cỗi lại làm việc với các thiết bị đầu cuối đơn sắc nhanh đến nỗi khiến tất cả những ai sử dụng ứng dụng mới đều phàn nàn. Chúng ta không thể quay trở lại với công nghệ thời thập niên 1960?

Có vẻ không công bằng khi so sánh ứng dụng Java mới với các ứng dụng màn-hình-xanh cũ. Java làm được nhiều thứ hơn. Như có thể dùng phông chữ ưa thích, màu sắc trang nhã, và các cửa sổ có thể thay đổi kích thước. Nhưng dữ liệu vẫn nhập bằng tay, và người ta nhớ các màn hình màu xanh lá với phông chữ cố định làm việc nhanh hơn nhiều.

Nếu code cũ có nhiều lỗi, việc viết lại là sự lựa chọn duy nhất. Nhưng đôi khi việc xây dựng lại một ứng dụng chỉ nhằm làm mới nó có thể là sai lầm lớn.

Công nghệ phần mềm mới nhất không phải lúc nào cũng là một sự cải tiến. Có lý do để các kỹ sư phần cứng cười nhạo rằng các lập trình viên tồn tại để viết hàng đống dòng code mới nhằm đảm bảo phần cứng mới chạy chậm như phần cứng cũ. Nếu không thì sẽ không nhu cầu phần cứng mới.
 

 

 

Nguồn: PC World VN