Như một thói quen, tôi hay lang thang trên Github, LinkedIn từ lúc còn đi học. Dạo này, tôi thấy càng nhiều kỹ sư tự gắn cho mình mác Full-stack engineer. Nếu để ý thì cũng dễ nhận ra các kỹ sư phần mềm rất thích cái mác này để mô tả khả năng của mình. Dễ hiểu thôi, vì đó là một cái mác khá ấn tượng trong lĩnh vực công nghệ, như một cách để quảng cáo bản thân mình. Và nếu bạn chưa biết Full-stack engineer là gì, thì nghĩa nôm na kiểu là “kỹ sư toàn năng”. Đi học thì tài năng, đi làm thì toàn năng, kiểu vậy. Theo định nghĩa chung của giới công nghệ thì full-stack là một kỹ sư phần mềm, nhưng là một kỹ sư lành nghề, có kinh nghiệm lập trình trên mọi lĩnh vực trong công nghệ phần mềm. Có nghĩa là full-stack có thể làm mọi thứ từ thiết kế giao diện người dùng (front-end) đến lập trình các API hỗ trợ tích hợp với giao diện người dùng (back-end) và anh ta cũng kiêm luôn cả việc mô hình hóa, thiết lập và quản trị cơ sở dữ liệu.
Song, dù có chủ ý hay không thì các kỹ sư phần mềm thường được đào tạo hay tự đào tạo chỉ tập trung vào một vài chuyên môn cụ thể. Những năm trước đây, họ thường được đào tạo để làm kỹ sư back-end, chịu trách nhiệm về những thứ liên quan đến services và databases. Hiện nay, giao diện người dùng (UI) càng trở nên phức tạp, dẫn đến nhu cầu front-end tăng cao. Và thế là back-end + front-end = full-stack!
Nhưng theo ý kiến riêng tôi, một full-stack thực thụ phải là một kỹ sư chịu trách nhiệm tích hợp sản phẩm phần mềm, cũng là người có thể làm việc ở bất kỳ khâu nào trong kỹ thuật phần mềm, nắm vững các giai đoạn trong vòng đời sản phẩm và hiểu rõ tất cả sự phức tạp của nó. Đó là định nghĩa của riêng tôi. Và tôi cảm thấy rằng nhiều kỹ sư phần mềm không nhất thiết phải gắn cho mình cái mác đó. Ý kiến chủ quan này của tôi không liên quan đến danh hiệu nghề nghiệp mà liên quan đến sự chuyên nghiệp. Nó thể hiện ở các lĩnh vực sau đây:
1. Cơ sở dữ liệu
Nói đến tầng dữ liệu, điều quan trọng là ta phải am tường RDMS và cả nắm vững các giải pháp triển khai cho cơ sở dữ liệu phân tán. Việc am tường cả hai lĩnh vực này cho ta khả năng có được sự cân bằng trong việc đưa ra các quyết định sáng suốt và có kiến thức khi lựa chọn giải pháp lưu trữ dữ liệu. Một khi đã chọn, nó sẽ trở thành quyết định quan trọng nhất mà ta từng thực hiện trong suốt vòng đời sản phẩm. Đây là điều quan trọng nhất vì cơ sở dữ liệu là thứ cực kỳ khó thay đổi một khi đã đưa vào hoạt động. Và khi đã triển khai cho khách hàng, dữ liệu vĩnh viễn là của họ. Mọi thứ liên quan như di chuyển cơ sở dữ liệu, cập nhật lược đồ, tối ưu hóa,.. đều trở nên khó khăn hơn rất nhiều. Điều đương nhiên bắt buộc là phải giữ cho dữ liệu khách hàng được bảo mật, an toàn và nguyên vẹn. Bất kỳ thay đổi nào đối với cơ sở dữ liệu đều khiến khách hàng gặp rủi ro.
Khi nhận thức được như vậy, điều buộc ta khi bắt đầu bất kỳ dự án hay sản phẩm mới nào, là phải dành đủ thời gian để thiết kế mô hình dữ liệu và cấu trúc dữ liệu. Ví dụ, tôi đã từng là một trong ba kỹ sư đã bỏ ra cả tháng trời chỉ để tinh chỉnh các mô hình cơ sở dữ liệu và lược đồ của một ứng dụng. Hiện nay, do có quá nhiều giải pháp hỗ trợ tự động về NoSQL và DaaS/PaaS, thiết kế cơ sở dữ liệu đôi khi ít được quan tâm và đó chính là yếu huyệt với hầu hết các kỹ sư full-stack (tôi cũng vậy). Và ví như ta nhận ra khiếm khuyết trong các lược đồ cơ sở dữ liệu và một quyết định thay đổi được đưa ra, ta sẽ phải chấp nhận tốn kém không những tiền bạc mà còn mọi nguồn lực. Do vậy, nắm rõ và dành đủ thời gian cho tầng dữ liệu là cực kỳ quan trọng. Và các full-stack cũng nên biết rằng để đạt được các chứng chỉ chuyên nghiệp của Oracle DBA thì tốn kém thế nào.
2. Các dịch vụ máy chủ
Làm ở vị trí back-end trong một sản phẩm phần mềm, trách nhiệm của ta thường xoay quanh việc nạp/gửi (fetch/send) dữ liệu và giám sát việc thực thi một số thuật toán ở tầng nghiệp vụ (Business logic). Đương nhiên là có nhiều cách để nạp/gửi dữ liệu từ server đến client và cũng có nhiều cách để triển khai Business logic. Tuy nhiên, thực sự nắm rõ server-side services liên quan đến việc hiểu cách tương tác đúng đắn với cơ sở dữ liệu, cách áp dụng hiệu quả các quy định, phương pháp triển khai mã để phù hợp với các tiêu chuẩn/quy ước/thiết kế và cách server tương tác với các loại client khác nhau. Nếu là một back-end engineer, bạn sẽ thấy rằng những thứ tôi kể lể đều quá tầm thường, là những thứ chung chung về kỹ thuật phần mềm. Hầu hết những thứ này ta đã được học ở trường. Tuy nhiên, các front-end engineer thường không nắm vững điều này.
Bất kỳ kỹ sư nào cũng có thể viết một REST API, nhưng có chắc rằng API của ta hoàn toàn RESTful? Bởi rõ ràng nó có sự khác biệt.
3. Trải nghiệm người dùng
Khi xây dựng giao diện người dùng, không đơn thuần chỉ là biết cách thể hiện nó bằng HTML, CSS và Javascript. Thực tế, không chỉ là việc sử dụng thành thạo một framework hay một library cụ thể nào đó. Tôi biết khá nhiều back-end engineer tự xưng là “chuyên gia” về giao diện người dùng, mạnh miệng rằng lập trình giao diện người dùng quá giản đơn, dễ dàng, có tools sẵn hết rồi và thậm chí còn không được xem là lập trình. Tôi thấy nhiều front-end còn không nắm vững các khái niệm căn bản về giao diện người dùng. Hiện nay, giao diện người dùng càng trở nên phức tạp hơn trên mọi thiết bị, di động lẫn desktop. Người dùng không chỉ muốn có giao diện nhanh, chính xác, rõ ràng, có các tính năng phải như nhau trên mọi môi trường, mà còn muốn đồng bộ trên tất cả các thiết bị và cuối cùng, tất cả đều phải bảo đảm tính thẩm mỹ. Để đạt được tất cả những kỳ công này, việc xây dựng giao diện người dùng phải bao gồm tập hợp các mẫu thiết kế, tiêu chuẩn, quy ước và nguyên tắc của riêng nó – là điều khác biệt hoàn toàn với những gì back-end từng biết.
Điều thú vị nhưng cũng đáng sợ khi thiết kế giao diện người dùng chính là bất kỳ ai cũng có thể nhanh chóng làm được một thứ gì đó trông đẹp đẽ và có vẻ hay ho. Tuy nhiên, khi ứng dụng ngày càng phình to, nếu không có sự thẩm định bao quát thường xuyên để thiết lập tài liệu hướng dẫn, tích hợp mã theo modul, quản lý giao diện, trạng thái, phiên bản… chắc chắn ta sẽ có những ngày dedug xuyên đêm, đầy rối loạn và người dùng sẽ phải chịu đựng hậu quả đó. Giao diện là thứ đầu tiên mà người dùng sẽ tương tác, cho dù back-end service hoặc database được xây dựng tốt đến đâu, nếu phản hồi của người dùng là tệ, thì coi như sản phẩm đã đi tong. Vì vậy, để nắm rõ giao diện người dùng, ta phải thường xuyên cập nhật, đọc các mẫu thiết kế, hiểu cách các nền tảng hoạt động (trình duyệt hoặc thiết bị di động) và cũng nên dành thời gian tìm hiểu cách xây dựng giao diện người dùng cho các ứng dụng ở quy mô lớn.
4. Kỹ sư tích hợp
Đây là điều mà tôi đã đề cập ở đầu bài viết. Gần đây, giới công nghệ hay dùng chức danh Product engineer để chỉ người nắm toàn quyền trong quá trình phát triển sản phẩm. Anh ta có quyền và có khả năng can thiệp vào mọi công đoạn trong quá trình xây dựng phần mềm và là người chịu trách nhiệm chính trong việc tích hợp sản phẩm. Chức danh này chỉ có ở các công ty quy mô lớn, nhằm tạo ra một vị trí đủ tài năng và quyền lực để huy động mọi nguồn lực cho sản phẩm.
Cuối cùng, cái giá của việc trở thành một full-stack là luôn chỉ đạo và chỉ đạo một cách chung chung hơn là biết phương pháp thực hiện như những chuyên gia. Thực tế, ta không thể nào vừa là lãnh đạo, lại vừa là chuyên gia trong mọi lĩnh vực. Trở thành chuyên gia có nghĩa là phải dành toàn bộ sự chuyên nghiệp để tập trung vào một lĩnh vực cụ thể. Nhưng full-stack thì lại có quá nhiều lĩnh vực buộc phải tìm hiểu.
Trở thành một full-stack là tham vọng của mọi kỹ sư, nó mang lại cho ta cái nhìn sâu sắc hơn, có sự đồng cảm và hiểu biết thêm một số kỹ năng ở mọi lĩnh vực công nghệ phần mềm. Nó giúp ta hiểu rõ hơn những khó khăn ở lĩnh vực chuyên môn khác và cũng giúp ta có những quyết định cân bằng, sáng suốt, phù hợp hơn.
Nếu có dịp gắn mác cho mình, tôi sẽ gắn mác CIO!
