Một trong những điều khiến tôi tự hào nhất về nghề code là những bài học cuộc sống dành tặng cho tất cả mọi người - bao gồm cả những người chưa code một dòng hay thậm chí là không hề quan tâm đến công nghệ. "Lòng dũng cảm" là một trong số những bài học đó.
Bạn đã bao giờ nhận ra rằng phần mềm (và IT nói chung) chỉ là công cụ giải quyết những vấn đề hiện hữu trong cuộc sống của bất kỳ một ai? Ví dụ, bạn rất hay mất sổ y bạ và bác sĩ không thể nào biết đầy đủ lịch sử thăm khám/sức khỏe của bạn? Chúng tôi sẽ tạo ra một hệ thống "y bạ điện tử" để lưu lại thông tin khám của bạn, cho phép bác sĩ bất cứ nơi đâu có thể truy cập và xem dễ dàng thay vì trông chờ vào... trí nhớ của bạn.
Tuyệt hơn, công nghệ không nhất thiết phải luôn luôn giải những vấn đề to tát.Như tôi chẳng hạn, đi làm về hay quên khóa cổng. Bố mẹ mắng mãi cũng chả nhớ, thế là tôi dùng công nghệ (cụ thể hơn, chiếc điện thoại của mình) để đặt lịch hẹn cứ 9h tối thì ra kiểm tra lại cổng xem đã khóa chưa.
Thế là cứ đến 9 giờ, chuông điện thoại của tôi lại reo inh ỏi. Bố mẹ mấy hôm đầu còn hay hỏi: "Tối rồi ai còn gọi", đến khi biết hóa ra là con mình đặt chuông nhắc khóa cửa thì lại càu nhàu.
Đọc đến đây thì nhiều bạn chắc hẳn đã nghĩ theo kiểu giống của bố mẹ tôi: "Có mỗi cái chuyện khóa cửa mà không nhớ được. Phải tự rèn mình đi chứ".
Xin hãy nghe tôi kể 2 câu chuyện về nghề code.
Cách đây rất lâu, người ta lập trình theo phong cách “tuần tự”. Tức là, nếu tôi cần viết ra một hàm mô phỏng phép tính thuế thu nhập của một người làm bộ phận kế toán chẳng hạn, tôi sẽ phải viết ra khoảng vài chục dòng code trong cùng một “hàm” để tính thuế trên lương và thưởng theo quý của người đó. Cái dở là ở chỗ, tôi sẽ phải làm thế nào để tính thuế thu nhập cá nhân cho một người làm sale, có lương không có thưởng theo quý nhưng lại có hoa hồng – và hoa hồng bị tính tỷ lệ thuế khác với lương và thưởng thông thường?
Nếu theo cách nghĩ cũ, tôi sẽ copy hàm tính thuế cho người làm kế toán, paste ra và sửa để phù hợp với người làm sale. Tương tự, tôi sẽ copy-paste-sửa cho người làm dự án (có lương, thưởng có phụ cấp).
Vậy, điều gì xảy ra khi Nhà Nước thay đổi quy định lương cứng? Tôi sẽ phải mở tất cả các hàm tôi đã copy-paste-sửa, và sửa lần lượt từng hàm để áp dụng cách tính mới.
Bạn có thể áp cùng một cách nhìn tương tự như bố mẹ tôi và nói: Nếu làm cẩn thận thì copy-paste-sửa như thế code vẫn đúng, không sai được. Nhưng tôi là một người không hoàn hảo, tôi copy-paste-sửa thế nào rồi cũng có thiếu sót.
Mấy chục năm trước, nhiều bộ não làm phần mềm cũng thấy vấn đề tương tự. Họ thừa nhận rằng coder không phải là những người hoàn hảo. Họ đưa ra giải pháp: đừng copy paste các hàm, các “vật thể dữ liệu” tương tự nhau nữa, hãy đem những phần giống nhau “gói” lại một chỗ. Ví dụ, trong trường hợp của tôi, tôi có thể viết một hàm tínhThuếLươngCứng() và rất nhiều hàm tínhThuếChoVănPhòng(), tínhThuếChoSale()...
Các hàm cụ thể này đều sẽ kích hoạt một hàm tínhThuếLươngCứng() duy nhất khi chạy. Nếu cách tính lương cứng thay đổi, tôi chỉ sửa một chỗ duy nhất là hàm tínhThuếLươngCứng(). Không còn phải cẩn thận đi sửa từng hàm một và... tự dằn vặt khi sự cố xảy ra.
Một câu chuyện khác: đến ngày nay nhiều nơi vẫn làm phần mềm theo cách gần giống với xây nhà. Tức là, khách hàng mô tả mình muốn gì, chuyên viên phân tích/thiết kế sẽ tư vấn và ghi chép/vẽ lại những gì khách hàng muốn dưới dạng tài liệu. Tài liệu này được chuyển để coder hình dung và thực thi thành phần mềm “thật”, cũng là căn cứ để tester kiểm thử.
Vấn đề là ở chỗ phần mềm không dễ hình dung như căn nhà. Rất nhiều khi khách hàng chờ đợi chỉ để nhận ra rằng cái mà họ đã mô tả không phải là cái họ thực sự muốn. Rồi analyst cũng thường chỉ mô tả được chính xác 80% những gì khách hàng nói. Coder và tester có cách hiểu khác nhau, có cách làm việc khác nhau, thường chỉ làm đúng 80% những gì analyst mô tả và cũng thường không tuân theo quy trình đảm bảo chất lượng. Kết quả là tới 89% dự án phần mềm theo cách làm truyền thống này thất bại (báo cáo Standish 2015).
Nhưng cũng như những câu chuyện khác của tôi, thực chất mô hình làm phần mềm truyền thống vẫn có thể hoạt động tốt nếu khách hàng hiểu biết về phần mềm, analyst hiểu biết cả về phần mềm và nghiệp vụ, nếu coder và tester làm việc thực sự khoa học... Nói cách khác, nếu môi trường làm phần mềm là hoàn hảo.
30 năm trước, nhiều huyền thoại công nghệ cũng đã nhận ra điều này. Và họ nhận ra rằng người làm phần mềm không hề hoàn hảo. Để giải quyết các vấn đề của mô hình truyền thống, họ đưa ra một triết lý mới mang tên gọi “Agile” (linh hoạt). Tôi không thể mô tả về Agile chỉ trong một bài viết, nhưng người làm Agile sẽ luôn luôn hiểu 2 điều: 1, không có ai hoàn hảo cả, bao gồm cả họ lẫn khách hàng của họ và 2, không có thứ gì có thể tốt ngay từ ban đầu, bao gồm cả phần mềm lẫn quy trình của các bên liên quan.
Khi đã chấp nhận 2 sự thật quan trọng này, người làm phần mềm theo kiểu Agile đưa ra những giải pháp "đi qua" sự thiếu hoàn hảo của mình. Ví dụ như trong mô hình Scrum, tất cả các thành viên của đội phát triển đều được gọi là "developer" (nhà phát triển) - dù rằng họ có thể không viết code mà chỉ phụ trách tài liệu, thiết kế hoặc kiểm thử, dù rằng họ phụ trách công việc kiến trúc giải pháp ("cao" hơn code).
Tại sao ư? Khi "chức danh" tất cả mọi người đều là "nhà phát triển", họ hiểu rằng trách nhiệm của họ như nhau, mục tiêu cuối cùng của họ chỉ có một: phát triển ra thành phẩm phần mềm. Không còn chuyện coder đợi analyst hoàn thiện mô tả giao diện đầy đủ, không còn chuyện tester thấy config sai nhưng đợi coder vào sửa. Scrum là một trong những lời giải "đánh" vào trách nhiệm và sự chủ động của người làm phần mềm, vốn không hề... hoàn hảo.
Tỷ lệ thành công của Agile đạt 39%. Chưa quá bán, nhưng hãy nhớ làm phần mềm kịp tiến độ, đủ thời gian và làm vừa lòng khách hàng còn khó hơn xây nhà gấp vạn lần.
2 câu chuyện này đã dạy cho tôi một bài học cuộc sống quan trọng: hãy dũng cảm thành thật với con người mình. Nếu như tôi cứ chạy theo cái suy nghĩ rằng một lúc nào đó tôi có thể tự luyện để “nhớ” khóa cổng, nhớ tắt âm-li mỗi đêm, nhớ tất cả những việc phải làm trong ngày, hoặc luyện để tập trung viết hết những bài viết như thế này trong vòng 1 tiếng, tôi vẫn sẽ gặp những vấn đề tưởng dễ mà khó giải. Cuộc sống của tôi sẽ không thay đổi, bởi tôi sẽ cố suy nghĩ rằng một lúc nào đó tôi sẽ loại bỏ được điểm yếu của mình.
Nhưng hóa ra, để giải quyết các vấn đề trong cuộc sống của mình, tôi có thể chấp nhận rằng những điểm yếu đó tồn tại. Tôi thừa nhận rằng tính tôi hay quên, nên tôi dán đầy note nhớ lên cửa. Tôi thừa nhận rằng tính tôi dễ mất tập trung, nên tôi dùng pomodoro: cứ làm việc 25 phút thì nghỉ 5 phút để đi lại, để nghịch điện thoại, để làm bất cứ thứ gì. Tôi không phải là người hoàn hảo, nhưng rõ ràng là ép mình sửa những điểm yếu không bao giờ sửa được thực chất sẽ chẳng mang lại giá trị gì cho chính bản thân tôi.
Kết quả là bây giờ tôi có bài viết này để gửi tới bạn đọc, thay vì đang còn ngồi chơi nốt một màn Starcraft Remastered.
EmoticonEmoticon