Ngày nay, nói đến lập trình viên học PHP cơ bản hay những người lập trình chuyên nghiệp đều nghĩ tới 1 phương tiện là PHP Framework. Vì nó giúp lập trình viên giảm thiểu tối đa thời gian phải viết lại những thao tác cơ bản.
Thật vậy, PHP Framework hiện nay khá đầy đủ và đáp ứng hầu hết các điều kiện cần và đủ cho việc xây dựng một dự án. Nói tới Framework thì nổi bật nhất vẫn là những tay gạo cội và lão làng như: Zend Framework, CodeiGniter Framework, CakePHP Framework,.... Các framework này chú trọng những chi tiết nhỏ nhất trong lập trình. Nhằm giảm tải thời gian vận dụng cho người sử dụng chúng. Chẳng hạn như các helper giúp người dùng xây dựng form, các helper giúp người dùng sử dụng những thẻ HTML, các helper giúp người dùng validation các form và dữ liệu,....Những điều này, thực tế chỉ góp phần làm cho Framework đó trở nên thân thiện và quen thuộc với người dùng nhiều hơn thôi.
Nhưng thực tế, PHP Framework cũng để lại những hệ lụy tác động tới nhiều yếu tố của ứng dụng hay nghiêm trọng hơn vẫn là tới yếu tố con người. Trong bài này, chúng ta cùng phân tích xem. Vấn đề gì cần quan tâm và cần chú ý khi vận hành bất kể PHP Frameworknào nhé.
Cần hay không cần những helper như thế ?.
Nếu phải hỏi các lập trình viên rằng "Bạn có biết HTML hay không ?. Bạn có biết tạo form bằng HTML hay không ?." Sẽ không ít người cười và cho rằng bạn đang làm những việc dư thừa. Ở đẳng cấp một lập trình viên. Thì đó là yếu tố cơ bản bắt buộc họ phải học qua, vậy tại sao chúng ta còn đợi chờ một PHP Framework thay ta làm những công việc như thế. Có, dĩ nhiên là tốt. Nhưng không có cũng chẳng ảnh hưởng tới ai. Hơn nữa với việc cập nhật các thư viện này sẽ khiến cho ứng dụng trở nên chậm chạp và khó vận hành hơn. Một điều mà các PHP Framework luôn phải chịu tác động.
Model bài toán nan giải dành cho các framework.
Hầu hết các PHP Frameworkđều xây dựng trên mô hình M-V-C một trong những design pattern. Mô hình này sẽ tách code thành 3 phân vùng khác nhau với 3 trách nhiệm khác nhau. Controller sẽ đóng vai trò tiếp nhận request (yêu cầu) để chuyển chúng tới cho Model. Lúc này model sẽ vận hành các cấu trúc Active Record hoặc SQL thuần để lấy ra thông tin từ database sau đó đổ chúng vào dạng mảng. Lúc này khi controller yêu cầu tới request nào nó sẽ đẩy mảng thông tin đó vào view. Tại view để lấy được các giá trị trong mảng, ta lại phải duyệt mảng để lấy ra từng phần tử đơn lẻ như thế. Việc này càng làm cho ứng dụng trở nên chậm chạp. Góp phần gia tăng % "rùa" của PHP Framework.
Autoload - yếu tố chí mạng làm chậm framework.
Để giúp người sử dụng dễ dàng vận hành các thư viện, các PHP Frameworkthường cho phép tính năng autoload luôn bật on ở mọi thứ. Điều này giúp cho người lập trình không tốn thời gian khởi tạo các đối tượng khi cần dùng tới. Bởi chúng đã được triệu gọi ngay khi chúng ta truy cập tới controller mất rồi. Có vẻ lợi nhiều hơn hại các bạn nhỉ. Nhưng thực tế, chính autoload trở thành bài toán nan giải khi người sử dụng triệu gọi một đối tượng bất kỳ. Vì không phải controller nào cũng cần những thư viện giống nhau. Nó tùy thuộc vào yêu cầu của controller đó như thế nào và ra sao. Do đó, đừng bao giờ áp đặt cho PHP Frameworkcủa chúng ta phải load tất cả các thư viện. Đúng là lợi đấy, nhưng nếu lợi 1 thì hại sẽ là 10 cho ứng dụng của bạn.
Hướng đối tượng - câu chuyện muôn thuở cho các framework.
Để code được mạch lạc, được trong sáng. Người lập trình đều muốn đưa mã nguồn của họ về hướng đội tượng Để giúp họ phát huy yếu tố kế thừa và vận hành hiệu quả những gì mà họ đã từng làm với các ứng dụng trước đó. Hơn nữa, mô hình hướng đối tượng (Object-Oriented Programming) cũng là một thế mạnh của PHP. Nên cứ thế mà lập trình viên không ngừng xây dựng code của mình theo hướng đó. Đúng là OOP làm code trở nên trong sáng và rõ ràng, nhưng lạm dụng OOP một cách thiếu linh động sẽ làm gây tác dụng ngược lại với lợi ích mà chúng ta luôn mong muốn. Nên vận dụng OOP thật khéo léo với design pattern để phát huy tối đa sức mạnh mà OOP vốn có.
Và tư duy ngủ quên - mối hiểm họa đáng lo lắng cho lập trình viên.
PHP Frameworkđúng một trong những bước tiến đáng kể của PHP. Bởi việc xây dựng hàng loạt các thư viện giúp người dùng giải quyết bài toán một cách khoa học và không cần phải làm lại những thao tác đã quá căn bản. Nhưng cũng chính vì những điều này mà PHP Frameworklàm cho người lập trình có thói quen ỷ lại một cách nghiêm trọng khi vận dụng PHP Framework. Chẳng hạn ở phiên bản CodeIgniter 1.7.2, CodeIgniter đã hỗ trợ cho người sử dụng cả thư viện shopping cart, image,....Việc này vô tình làm cho Lập trình viên PHP có suy nghĩ lười nhác trong việc vận dụng và phát triển. Với họ việc tạo 1 cart online chỉ đơn giản là móc, móc, trỏ, trỏ. Gọi lớp kia, gọi lớp này là xong. Vô tình chính PHP Framework đã giết chết suy nghĩ của người lập trình.
Người ta hay đòi hỏi một món ăn thật ngon miệng, thật chất lượng và chế biến phải thật nhanh. Thế rồi khi có món ăn như thế họ luôn nghĩ rằng ăn như vậy mới là đúng cách, mới là tiết kiệm thời gian. Nhưng thực tế, những hệ lụy của việc sử dụng "fast food" luôn đem lại những bất cập về nhiều mặt. Ví như một món ăn, khi đã chế biến nhanh thì làm sao mà sạch được, mà khi đã không sạch thì dùng vào cơ thể tác hại nhiều hơn là tác dụng. PHP Framework cũng thế, nếu lúc nào lập trình viên cũng chỉ biết dựa vào PHP Framework mà quên mất PHP Framework cũng được làm nên từ những kiến thức mà họ có được. Thì chắc chắn, lập trình viên đó mãi sẽ không thể thoát khỏi cái bóng lớn của PHP Frameworkđem lại. Vậy ở khía cạnh 1 lập trình viên, chúng ta nên có cách nhìn đúng đắn. Khi PHP Frameworkcung cấp 1 thư viện mới, đừng ngần ngại vọc xem làm thế nào chúng giải quyết bài toán đó. Từ đó ta mới có thể rút ra được những cải tiến, tối ưu mà PHP Frameworkđem lại. Chưa kể nó sẽ bổ sung một lượng kiến thức khổng lồ cho bạn khi đọc sâu và tìm hiểu chu trình hoạt động của một thư viện PHP Framework bất kỳ.
Nhận xét này đã bị tác giả xóa.
Trả lờiXóa