Cách đây 3 năm Ruby on Rails bắt đầu tấn công vào cộng đồng Java nhờ
những lời lẽ khoa trương về sức mạnh của nó. Dereck của CDBay đă bị
xao động và quyết định viết lại website của ông ta dựa tên Rails sau
khi tuyển mộ một trong các nhân vật chủ chốt của cộng đồng Rails:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back... . 2 năm sau đó Dereck đă thấm đ̣n . Ruby và Rails không phải là các
viên đạn bạc (
http://paul-m-jones.com/blog/?p=259) cho các ứng dụng
web. Ông ta đă tiến hành viết lại site của ḿnh bằng PHP trong 2 tháng
và giảm số ḍng code từ 90 000 ḍng Ruby/Rails xuống c̣n 12 000 ḍng
PHP với những bài học rút ra được từ cách tổ chức ứng dụng theo tinh
thần của Rails. Những ǵ ông ta có được đều rất đáng kể: tốc độ, khả
năng bảo tŕ của ứng dụng, không c̣n ác mộng về Rails.
Trên thực tế Dereck trở về với PHP không phải là ko có lư do. Rails đă
cho ông ta bài học khá tốt về lập tŕnh hướng đối tượng theo phong
cách mới khi mà năm 2005, cộng đồng PHP chưa đủ chín cho việc đó. Năm
này, tôi có bài viết đầu tiên của ḿnh về PHP5 với các tính năng hướng
đối tượng trên PCWorld nhưng 2 năm sau đó cộng đồng PHP ở VN vẫn dẫm
chân tại chỗ. Nhưng cũng phải mất 2 năm tôi mới thực sự hiểu lập tŕnh
hướng đối tượng trong PHP khi đánh vật với framework của riêng ḿnh
trong 16 tháng qua. Mọi vấn đề chỉ có thể được đào xới thông qua lao
động thực sự. Nhưng những điều tốt đẹp đă hẳn không thể đến sau vài
năm ngắn ngủi nếu như đă không có sự chuyển biến rất lớn trong cách tư
duy của cộng đồng PHP: đó là mô h́nh hướng đối tượng ngày càng được
hoàn thiện từ bản 5.0 sang 5.1. Hiện tại chúng ta đă có bản 5.2 ổn
định hơn rất nhiều. Bản 5.3 sẽ xuất hiện sau 3-4 tháng nữa với Late
static binding và name space hứa hẹn sẽ hoàn thiện hơn mô h́nh OOP của
PHP. Cùng lúc đó người dùng không cần chờ đến PHP6 để có được sự hỗ
trợ Unicode buit-in trong PHP mà extension intl đă được back port sang
PHP5. Và lập tŕnh viên PHP (như tôi) đă có 2 năm để đánh vật với lập
tŕnh hướng đối tượng trong PHP5 đủ để hiểu những chi phí ẩn và lợi
ích đi kèm. Nhiều người đă phải cần đến một công nghệ khác làm nền
tảng (với tôi là Java) khi mà common sense trong cộng đồng PHP c̣n khá
khiêm tốn. Mọi người cũng đă thấy sự hoàn thiện dần của Zend
Framework, SolarPHP, CakePHP, Symfony, sự ra đi của Mojavi, Phrame,
Blueshoes ... và vô số các framework khác như là sự kết thúc các thử
nghiệm thất bại trong việc t́m ra một mô h́nh phát triển đúng đắn cho
PHP framework. Mặc dù tất cả các web framework đương đại đều có các
điểm yếu riêng của nó khiến một ai đó trong chúng ta không hài ḷng
(trong đó có tôi) th́ chúng ta cần thừa nhận rằng sự phát triển đó đă
rút ngắn khoảng cách công nghệ giữa Ruby và PHP trên một số phương
diện thuần ngôn ngữ. Dereck vốn có quan hệ thân thiết với một số key
figure trong cộng đồng PHP và hiển nhiên đă nhận thức được điều này.
Thế là cuộc phiêu lưu với Rails chấm dứt.
Bài học của Dereck để lại vài nhận thức:
+ Thế giới PHP đă có quá nhiều thay đổi: các lập tŕnh viên PHP nên
ngừng code và nghe ngóng đi kẻo tư duy của bạn đă lạc hậu so với phần
c̣n lại của thế giới.
+ Đứng cố theo đuổi một công nghệ cho một dự án nếu như với loại dự án
đó nó không work. Hăy cân nhắc nó trong tương lai. Hăy nhận thức điều
đó sớm hơn nếu muốn tránh hiệu ứng hệ thống thứ 2 trong công nghệ phần
mềm.
+ Chọn công cụ đúng. Ngôn ngữ là một công cụ nhưng framework cũng là
một công cụ theo nghĩa hẹp hơn hơn nhiều. Nó không phải là viên đạn
bạc. Ví dụ dùng PHP để lập tŕnh Desktop application vào thời điểm
hiện tại là dở hơi. Ví dụ PHP có thể không hiệu quả như Perl trong các
ứng dụng system scripting. Và nó chỉ đúng khi nó vừa tay với bạn. Tôi
đố bạn trở thành chuyên gia của mọi loại ngôn ngữ nhất là khi đối với
bạn, ngôn ngữ lập tŕnh hay công nghệ chỉ là cái tivi, bật nó trong 8
tiếng xem qua ngày rồi tắt nó đi. Một chuyên gia công nghệ không thể
chỉ là người thành thạo API (các bạn có các certification cho ngôn ngữ
nọ kia dừng xúc động) mà bạn c̣n cần đến sự hiểu biết ở mức low-level
mới mong xây dựng được các hệ thống high traffic kiểu như CDBaby. Đây
chính là một trong các lư do khiến dự án Rails thất bại.
+ Liên tục theo dơi sự phát triển của công nghệ. Dereck hiển nhiên đă
thấy bứt rứt v́ thành công của Digg, Facebook, Friendster, Technorati,
Flickr, Wikipedia... các ứng dụng PHP khổng lồ về phương diện traffic
và sự ngao ngán của những người sáng lập Twitter về sự yếu kém của
Rails trong vấn đề tương tự.
+ Ngôn ngữ là cái ǵ đó cố định: Tôi là người thừa nhận "language
matters" chứ không như một số em chă khác. Cho dù quảng cáo ǵ về tính
general purpose của 1 language th́ rút cục thông qua lao động, người
ta luôn thấy một ngôn ngữ đều làm tốt một số vai tṛ của nó tốt hơn
một số ngôn ngữ khác. Đây chính là tiền đề cho DSL của Martin. Nhận
thức được điều này đồng nghĩa với việc bạn chọn được công cụ đúng.
Tính mềm dẻo của một ngôn ngữ thể hiện ở chỗ nó có ḥa hợp được với
các chuẩn công nghiệp thường gặp hay không: hỗ trợ XML/JSON/SWX,
design pattern, OOP, AOP, SOAP, SOA. Cú pháp của PHP có thể xấu xí
nhưng khi đi vào lập tŕnh hướng đối tượng nó không khác ǵ Java về cả
phương diện tổ chức lẫn cú pháp v́ Java đẻ ra mô h́nh hướng đối tượng
cho PHP. PHP là đủ mềm dẻo để lập tŕnh viên lựa chọn mô h́nh lập
tŕnh cho ḿnh. Những ai nh́n thấy tính cố định của một mô h́nh lập
tŕnh (ví dụ nhiều người code Java thấy PHP toàn được mix vào HTML và
coi đó là cách phát triển PHP duy nhất) chỉ cho thấy là họ có hạn chế
nhất định về mặt tư duy công nghệ trên các ngôn ngữ mục đích chung.
Trường hợp của Dereck cho thấy ông ta đă thu nhận được kiến thức từ
chuẩn công nghiệp của ngành và nhanh chóng áp dụng nó một cách thành
công sau 2 tháng với PHP. Nhưng để học được kiến thức đó, ông ta cần
đến 2 năm trả giá.
+ Tooling: đây là một vấn đề mà Dereck đă mắc phải và phải trả giá cho
nó. Không có một tool nào là viên đạn bạc. Rails là một loại cool tool
dành cho một lớp các vấn đề. Nó có thể giúp giải quyết 95% vấn đề
thường gặp chỉ bằng 5% nỗ lực nhưng khi miền vấn đề của ứng dụng đă
vượt ra khỏi 5% đó, chúng ta sẽ phải lấp kín 95% c̣n lại bằng sự đau
đớn. Trường hợp ASP.NET cũng như vậy. Không có ǵ khiến chúng ta thất
vọng hơn là sự phụ thuộc vào một IDE, một thứ kiến trúc trâu chẳng ra
trâu ngựa chẳng ra ngựa và một cộng đồng toàn những morons. Hiệu suất
của tooling luôn đi kèm với tính độ sâu của abstraction, độ giảm của
flexibility và nhiều khi nó làm cho ứng dụng dựa trên tool như là một
black hole. Điều này dễ hiểu tại sao lập tŕnh viên Rails là morons và
lập tŕnh viên ASP.NET là những morons cấp "cao" hơn.
+ Khi bạn lập một dự án hoàn chỉnh để kiếm tiền, bạn chọn một hệ
thống, một cộng đồng chứ không phải là một framework, một ngôn ngữ.
Dereck sai lầm v́ chọn Rails thay v́ chọn một hệ thống trong khi cái
phục vụ người dùng là hệ thống chứ không phải là Rails. Dereck bị
quyến rũ bởi API trong khi ông ta không tính toán kĩ API đó sẽ đem lại
user experience như thế nào và chi phí của nó là bao nhiêu. Khi Rails
phù hợp với một hệ thống không work theo nhu cầu của ông ta th́ dự án
thất bại. Dereck sai lầm v́ chọn một cộng đồng quá nhỏ, mọi thứ đều
rất mới và khi cộng sự của ông ta ra đi, di sản để lại là không thể
gánh được. Quay trở lại cộng đồng PHP, ông ta sẽ đối mặt với một thách
mức mới: dân cư PHP đông đến mức nếu ông ta để lộ mă nguồn th́ tôi tin
rằng ngay ngày mai sẽ có CDBaby đánh số từ 1 đến 1000 xuất hiện. Kinh
nghiệm triển khai các hệ thống lớn với PHP đă được đăng tải trên web
công cộng dày đặc đến mức có lẽ cần lập riêng một nhà xuất bản để in
lại. Dereck rời bỏ một cộng đồng đă quá chín muồi và đang nâng cấp
level để đến một cộng đồng c̣n quá trẻ nhưng không đóng bảo hiểm tai
nạn. Thế có buồn không?
Dù sao xin chúc mừng đứa con xa quê trở lại.
