Cách mà Google tạo ra frameworks cho Web của họ

Ai cũng biết rằng Google sử dụng duy nhất một Repository để lưu trữ và chia sẽ tất cả 2 tỉ dòng code của hãng – với phương thức trunk-based development – phát triển từ một nhánh mã nguồn chính

Codebased của Google được dùng bởi hơn 25000 nhân viên lập trình của hãng từ mọi chi nhánh. Trung bình một ngày, hơn 16000 dòng code được chỉnh sửa.

Bài viết sẽ tập trung nói về ngôn ngữ AngularDart – một mã nguồn mở chạy trên đa nền tảng như Windows, Mac OS X và Linux OS(s).

Chỉ sử dụng một phiên bản

Khi cả một đội ngũ tập trung vào việc phát triển một nhánh chính của mã nguồn (trunk-based development) thì tức là họ đang làm việc với một phiên bản duy nhất. Điều đó nghĩa là bạn không thể dùng các ứng dụng mà có web frame work version khác nhau được. Tất cả các ứng dụng đều phải chạy trên cùng một version của web frame work.

Vì vậy mà đôi khi Google vẫn nói là tất cả các phần mềm của hãng đều chạy trên phiên bản web framework mới nhất.  Điều đó cũng có nghĩ là đôi khi những phiên bản quá mới này tồn tại nhiều lỗi và không được ổn định.

Đọc đến đây thì chắc các bạn sẽ nghĩ rằng “Không phải nó nguy hiểm quá sao?”. Và đúng là cái việc tất cả các phần mềm đều dựa trên một nhánh nguồn chính là rất nguy hiểm nếu có lỗi xãy ra. Nhưng mà hóa ra không chỉ đơn giản là vậy.

Cứ mỗi lần thay đổi 1 dòng code, Google sẽ test tới 76000 lần

Khi một dòng code được thay đổi trong repository của Google thì hệ thống sẽ tự động test cho tất cả các ứng dụng đang sử dụng trên framework đó luôn. Hiện tại, con số test là 76000 lần (Tùy vào mức độ thay đổi mà các ứng dụng không bị ảnh hưởng sẽ không cần test nhằm tiết kiệm thời gian)

Để cho bạn dễ hình dung nhất, tôi đã thử thay đổi một thuật toán nhỏ trong mã nhánh nguồn chính của google (Thêm dòng ‘&& random.nextDouble() > .05’ vào dòng code này). Kết quả là, hơn 1601 bài test được diễn ra và hàng tá ứng dụng cũng như client bị lỗi.

Điều quan trọng là các bài test đều chạy dựa trên các app của người dùng. Nói cách khác, nó phản ánh cách mã nguồn được sử dụng bởi các developer. Đây là điều rất quan trọng bởi nó giúp google hiểu được mã nguồn của họ được các developer sử dụng như thế nào.

Nhờ mà nó giúp cho các app ứng dụng có tính đồng nhất cao. Đó là điều khác biệt giữa việc app được phát triển bởi chỉ một cá nhân với framework tự tạo và một app có tính tương thích cao nhờ vào sự phát triển bởi hàng ngàn người. Vì vậy để phát triển các ứng dụng web thì chúng ta phải sử dụng lựa chọn thứ hai : cùng dùng một web framework.

Nhưng nếu vào một ngày đẹp trời, tự nhiên mã nguồn của web bị lỗi thì sao?

Bạn làm hư thì bạn phải sửa

Khi mà các nhà lập trình của AngularDart đưa ra bất cứ thay đổi nào thì đồng thời họ cũng phải sửa những lỗi xảy ra bởi sự thay đổi đó cho người dùng. Cũng bởi vì tất cả mọi thứ của Google đều thuộc trên một mã nguồn chính nên phải xác định được app ứng dụng nào bị lỗi và sửa ngay luôn.

Nói cách khác, khi mà một thay đổi được diễn ra thì tất cả các ứng dụng cũng được update các bản patch và sửa đổi để có thể chạy được trên phiên bản framework đó. Quá trình vừa thay đổi vừa chỉnh sửa diễn ra liên tục và tuần hoàn sau khi được kiểm tra kĩ lưỡng từ nhiều nhóm developer khác nhau.

Một ví dụ điển hình, khi một thành viên từ nhóm AngularDart muốn thực hiện một sửa đổi gây ảnh hưởng đến ứng dụng Appwork thì nhóm phải vào tận mã nguồn để chỉnh sửa cho ứng dụng đó luôn. Sau đó nhóm phải chạy test để kiểm tra. Chỉ khi bảo đảm được kết quả thì mới lập một danh sách liệt kê các thay đổi và yêu cầu sự chấp thuận từ cả 2 nhóm developer của AngularDart và ứng dụng Appwork. Và nếu được thông qua thì thay đổi mới thật sự được thực hiện.  

Hằng ngày, các developer của AngularDart framework phải tiếp xúc với hàng triệu dòng code từ các ứng dụng được phát triển trên framework của họ. Vì vậy việc phát triển framework sẽ chở nên hiệu quả hơn.

Tuy vậy, việc phải update cho các ứng dụng của người dùng sẽ khiến việc phát triển bị chậm lại (thật sự là không nhiều lắm đâu). Điều đó cũng có lợi và hại tùy vào mục đích sử dụng framework của bạn.

Thế nên giờ thì khi nghe Google nói là họ đã update một phiên bản alpha của library ổn định và bắt đầu áp dụng vào mã nguồn chính thì bạn đã hiểu ý họ là sao rùi nhé.

Khi các bản cập nhật lớn xảy ra

Các bạn chắc sẽ thắc mắc rằng đối với các bản cập nhật lớn với sự thay đổi gần như là tất cả khiến cho 74000 bài test đều hiển thì lỗi thì AngularDart phải làm gì? Không lẽ phải sửa hết cả ngần ấy lỗi?

Chính xác đấy!

AngularDart sử dụng một hệ thống đặc biệt gọi là Sound Dart – với tính năng tự sửa đổi tự động mà không cần tới sự xác nhận của developer. Để dễ hình dung thì khi developer muốn thay một đoạn code ‘bar()’ thành ‘baz ()’ thì thay vì cứ phải thực hiện thao tác thủ công lập đi lập lại thì developer sẽ sử dụng Sound type system của Dart và tất cả các đoạn code ‘bar ()’ sẽ tự động đổi thành ‘baz ()’. Vì vậy nếu không có sự trợ giúp của Sound type thì ngay cả một thay đổi nhỏ cũng cực kì nguy hiểm.

Ngoài ra, Google cũng sử dụng dart_style (định dạng mặc định của Dart) để bảo đảm việc update trên diện rộng. Nói cách khác tất cả dòng code của Dart đều được để ở định dạng trên. Nhờ vậy mà việc thay đổi luôn đồng nhất và không bị lỗi.

Chỉ số hiệu suất

Như bài viết đã đưa ra, Test là một tính năng rất có lợi ích cho AngularDart. Nhưng Test còn giúp cung cấp thông tin về hiệu suất của app. Điều mà Google luôn rất chú trọng vì thế mà hầu như tất cả các app đều có bảng ghi chép lại hiệu suất của chúng.

Vì thế mà khi AngularDart đưa ra các bản thay đổi cấp nhật khiến cho AdWords bị chậm load lại khoảng 1% thì họ đã biết kết quả trước khi việc thay đổi xảy ra rùi. Thế nên khi họ đưa ra thông tin rằng các ứng dụng chạy trên AngularDart nhẹ hơn 40% và nhanh hơn 10% so với 2 tháng trước. Thì đó là số liệu thực tiễn từ các app với hàng triệu người sử dụng.

Công cụ build Hermetic

Vậy trong số hơn 74 ngàn bài test đó thì test nào là quan trọng nhất để các developer theo dõi? Mà cũng không thể chọn từng loại test thích hợp để kiểm tra cho từng thay đổi được? Giải pháp nằm ở một phần mềm gọi là Bazel.

Bởi với hơn 2 tỉ dòng code thì bạn không thể chỉ đơn giản lên từng script được nữa bởi nó quá tốn thời gian. Vì vậy mà bạn phải dùng Hermetic build tool.

“Hermetic” ở đây có nghĩa gần giống như Pure function. Khi mà các bước bạn thực hiện một build không được phép có side effect (như temp files, thay thành PATH etc.) và Input giống nhau thì output cũng phải giống nhau. Nói cách khác, bạn có thể chạy nhiều build khác nhau, từ các máy khác nhau, từ bất kì thời điểm nào mà vẫn có output nhất quán.

Google đã bỏ nhiều năm để tạo ra một tool như vậy. Đó chính là Bazel (open sourced)

Nhờ đó mà các chương trình test cũa hãng có thể chọn build hoặc bài test phù hợp với từng thời điểm và loại thay đổi.

Điều đó có nghĩa là gì?

AngularDart được tạo ra bởi Google với mục đích trở thành mã nguồn mở hiệu quả nhất, tốt nhất với độ tin cậy cao trong việc lập trình tạo website. Và cũng giải thích nguyên nhân vì sao mà các app của google như AdWords và AdSense đều phải sử dụng framework này. Bởi tính tin cậy cao cho người dùng.

Nói cách khác, bởi có lượng lớn khổng lồ các ứng dụng chạy trên AngularDart  mà việc sửa đổi cập nhật lớn sẽ không diễn ra thường xuyên nhằm bảo đảm tính ổn định. Nhờ vậy mà mã nguồn mở cũng trở nên đáng tin cậy hơn bởi mọi thay đổi đều được tính toán kĩ lưỡng.

Theo tôi điều làm nên sự thành công của một mã nguồn đến từ sự bảo trì thường xuyên. Vì vậy mà tôi rất mừng khi Dart có sự tập trung kĩ lưỡng vào các mã nguồn của họ. Bởi nó đều đi theo model của Google trong kinh doanh – tập trung vào chất lượng.

Nguồn: blog.topdev.vn via medium