Cộng đồng PHP: Mâu thuẫn và Tầm nhìn

Một bài viết tâm huyết từ một lập trình viên PHP. Dù bạn là developer trẻ, đang có hứng thú với ngôn ngữ lập trình này, hay một leader nhiều năm kinh nghiệm, hãy cùng Gambaru nhìn nhận góc nhìn của Neal và thảo luận ở phần comment cuối bài viết nhé.

Tôi đã lập trình với PHP được khoảng 7 năm, tự mình mày mò, khám phá về các framework, library, hệ sinh thái xung quanh các nền tảng quản lý nội dung, và quen biết một cộng đồng đông đảo lập trình viên PHP.

Rất nhiều người đã trở thành những người bạn thực sự và theo đánh giá của các bài phát biểu tại các diễn đàn tôi từng tham dự, tôi biết mình không đơn độc khi tin rằng chúng tôi có thể giúp mọi người cùng học hỏi và phát triển, xây dựng phần mềm tốt hơn, cũng như chung tay hỗ trợ lập trình viên tiến xa hơn trong sự nghiệp.

Ngôn ngữ PHP thường bị chỉ trích và chế nhạo bởi những lập trình viên cho rằng ngôn ngữ chúng ta lựa chọn chẳng khác gì một mớ hỗn độn và chỉ dân nghiệp dư mới sử dụng PHP.

(Có thể quan điểm này có lý trong quá khứ, nhưng bây giờ chỉ có người thiếu hiểu biết mới tranh luận như vậy, đặc biệt khi sự thật là PHP 7 đã đóng góp rất nhiều để giúp PHP trở thành một ngôn ngữ hoàn thiện hơn).

Tuy nhiên, cộng đồng PHP chẳng ngán gì “dăm ba lời khen chê này”, họ ngày càng bản lĩnh hơn và tiếp tục xây dựng các sản phẩm, thư viện, công cụ và tính năng mới.

Trong bài viết này, tôi muốn nói đến mâu thuẫn ngày càng gia tăng trong chính cộng đồng PHP, giữa những nhóm lập trình viên ủng hộ giữa các framework Laravel, Symfony và Doctrine ORM.

Nhiều người chuộng Symfony/Doctrine đưa ra những nhận xét chê bai về Laravel.

Đáp lại, những người ủng hộ Laravel dường như ngày càng trở nên chống đối và có xu hướng phản ứng quyết liệt với những lời chỉ trích (dù mang tính xây dựng hay không). 

Tôi chắc chắn rằng hầu hết lập trình viên chúng ta đều đã từng bị chỉ trích về cách mình code.

Chỉ trích cũng có đủ loại, có thể là “Cái quái gì thế này?” hoặc “Anh nên thử áp dụng các nguyên tắc SOLID / [x design pattern] ở đây, vì nó sẽ tiết kiệm thời gian và đỡ phải bực mình sau này đấy”.

Cách ta đưa ra và đón nhận phê bình đặt nền tảng cho cách ta phát triển như một nhà lập trình chuyên nghiệp cũng như sự nhìn nhận của những người xung quanh.

Đối với những người lãnh đạo, nó xác định cách những người theo gương và tôn trọng bạn cư xử ra sao đối với đồng nghiệp của họ.

Hiện nay, ta có thể thấy các lập trình viên ở vị trí Senior, các leader dự án và những nhân vật có tầm ảnh hưởng tham gia vào các cuộc tranh luận công khai trên các nền tảng như Twitter và Reddit.

Bạn đọc được những bình luận có tính gây hấn về khả năng mở rộng của dự án với framework x hoặc phương thức của library y chứa bao nhiêu dòng code.

Họ làm như vậy chẳng để đạt được điều gì ngoài việc thuyết phục người đọc rằng họ đã đúng khi không dùng những framework hay tool này.

Tóm lại, khi cứ mãi tranh luận như vậy, chúng ta đang cướp đi cơ hội của những lập trình viên ít kinh nghiệm hơn để thử nghiệm và trải nghiệm các cách tiếp cận khác nhau đối với các giải pháp chung.

Chúng ta phủ nhận họ có khả năng thoải mái thể hiện quan điểm và thảo luận về những cái lợi và hại của mỗi framework mà không sợ bị chế giễu.

Chúng ta ngăn họ đánh giá và học cách chọn công cụ phù hợp cho từng công việc cụ thể.

Chúng ta dần dần ngăn cản tiến trình sự nghiệp của họ. Điều này tạo ra một rào cản có hại cho họ và cho cả chúng ta như một hệ sinh thái của những nhà lập trình PHP.

Về cá nhân mình, Symfony là framework ưa thích của tôi, nhưng tôi đã làm việc chuyên nghiệp với cả Laravel [versions 4 & 5] và Zend.

Symfony sử dụng Doctrine 1, triển khai ActiveRecord pattern, bao gồm rất nhiều tính năng bổ sung theo mặc định và khiến việc liên kết business logic với framework trở nên cực kỳ dễ dàng.

Là một opinionated framework (có tính quy chuẩn và áp đặt), Symfony đặt ra các công cụ nó mong đợi bạn sử dụng ngay trước bạn và cho phép bạn nhanh chóng bắt đầu công việc.

Symfony 2 bắt đầu thay đổi tất cả những điều đó.

Lập trình viên sử dụng Symfony muốn có nhiều sự lựa chọn và tính linh hoạt hơn khi chọn các công cụ và những gì cần đưa vào dự án. Họ muốn đưa các thư viện khác vào dễ dàng hơn nếu giải pháp ban đầu không còn ổn nữa.

Symfony đã phát triển rất nhanh giữa các phiên bản 1 và 2 và trở nên khác biệt so với phiên bản ban đầu.

Nó chuyển từ một framework cố định với tất cả các công cụ được đóng gói bên trong và một mức độ chưa đủ tinh vi sang khả năng tương tác với các gói bên ngoài Symfony.

Symfony đã đi một chặng đường dài để chuyển mình thành một tập hợp các gói và thành phần có thể tái sử dụng và việc kết hợp các đề xuất của PHP-FIG có nghĩa là các thành phần có thể dễ dàng được đưa vào các framework, library và hệ thống CMS khác.

Lập trình viên sử dụng Symfony có quyền tự hào về Symfony và mong muốn chia sẻ cách họ làm được điều đó.

Phần lớn các nhà lập trình tôi biết đồng tình rằng tài liệu của Laravel dễ tiếp cận hơn của Symfony và cũng dễ bắt đầu với Laravel hơn nhiều.

Ngày nay, Laravel có tính áp đặt hơn Symfony, vì vậy, tài liệu hướng dẫn có thể ít trừu tượng hơn và trực tiếp hơn về cách đạt được mục tiêu với các công cụ được cung cấp.

Người ta thường có xu hướng gán Laravel là framework cho người mới bắt đầu hoặc chỉ là một công cụ cho RAD (Rapid Application Development – phát triển ứng dụng / tạo mẫu nhanh) và khuyên không dùng nó cho các dự án phức tạp hơn.

Tất nhiên, phản ứng từ người dùng Laravel là sau đó sẽ là “Chà, nó đã được sử dụng trên trang x đó nhe!”.

Người dùng Doctrine phản ứng lại “Tụi tôi đã bỏ ActiveRecord từ lâu rồi, ORM của mấy ông phèn quá”, và rồi bên kia tiếp “Muốn cãi nhau về facade pattern thật sao?”, rồi lại một hồi dài tranh cãi.

Than phiền duy nhất của tôi về Laravel và Eloquent là việc thêm các foreign key và index vào cơ sở dữ liệu sẽ tốn nhiều công sức hơn.

Tôi nghĩ đây là điều có độ ưu tiên cao khi thiết kế cấu trúc dữ liệu. Tôi đã kế thừa nhiều dự án Laravel bởi các công ty khác nhau, và không có dự án nào trong số đó có một foreign key hoặc index nào.

Điều này dẫn đến mất tính toàn vẹn của dữ liệu cũng như các vấn đề khác về hiệu suất.

Tôi cũng cảm thấy rằng Laravel và nhiều tài nguyên hướng dẫn về nó khuyến khích người dùng liên kết code ràng buộc với framework.

Một dev ở công ty tôi từng làm việc đã dành hàng tháng trời làm một việc đáng ra rất đơn giản là nâng cấp Laravel 4 lên Laravel 5. Anh chàng sao chép và viết lại các file và file logic được đặt trong controller.

Nếu như code được tách ra thì công ty hẳn sẽ chi ít tiền hơn cho việc nâng cấp này và anh ấy đã có thể chuyển sang phát triển tính năng mới sớm hơn nhiều.

Theo tôi, Laravel có thể được sử dụng cho các ứng dụng quy mô lớn, nhưng trừ khi lập trình viên đủ kinh nghiệm để biết những gì họ đang tìm kiếm trong tài liệu để cho phép scale ứng dụng, họ có thể sẽ không dùng Laravel.

Phải thừa nhận rằng rất dễ để liên kết code với Symfony controller, nhưng cộng đồng Symfony biết rằng làm như vậy là một ý tưởng tồi.

Theo trải nghiệm riêng, tôi chưa thấy người dùng Symfony chế nhạo ý tưởng tách code nhưng tôi thấy một số người dùng Laravel chế giễu cách làm này.

Lập trình viên chúng ta thường đưa ra lựa chọn về các công cụ yêu thích và hợp tác với những người khác đã giải quyết các vấn đề tương tự theo cùng cách.

Khi hạn chế bản thân bằng cách liên tục sử dụng những gì chúng ta biết và ở trong cộng đồng những người có cùng tư duy và ý tưởng, chúng ta hạn chế cách mình code và cả con đường sự nghiệp.

Tự ta buộc xích vào chân mình.

Điều khiến tôi lo lắng nhất là ảnh hưởng mà chúng ta có thể có đối với lựa chọn của các lập trình viên trẻ, ít kinh nghiệm.

Có lẽ ai cũng đều cảm thấy hài lòng khi khuyên bảo một người và sau đó thấy họ nối gót mình.

Tuy nhiên, điều ta không nên làm là khuyến khích lập trình viên trẻ tuổi đừng thử nghiệm framework x hoặc y, đừng học lập trình ngôn ngữ z vì những thành kiến ​​của riêng mình. 

Hãy để người trẻ tự thử nghiệm và cho họ lời khuyên. Hãy quan sát cách một người đưa ra và đón nhận chỉ trích.

Hãy nghĩ thử “Đây có phải là loại phản hồi đóng góp tích cực cho cộng đồng không? Đây có phải là mẫu người tôi nên lấy làm gương không? ”

Với tư cách là một leader, hãy tự hỏi bản thân “Tôi có đang buộc chiếc xích của chính mình vào chân những người xung quanh không? Tôi có ảnh hưởng tiêu cực đến người khác thông qua sự lựa chọn của chính mình không? ”

Các cuộc tranh luận gay gắt không có tác dụng gì trong việc thúc đẩy sự nghiệp chung của cộng đồng lập trình viên mà chỉ khiến mọi người e ngại gia nhập cộng đồng PHP toàn cầu mà thôi.

Theo Neal Brooks