Tự sự coder iFan: Bạn đã bao giờ nhìn cuộc đời kiểu "đóng gói" phần mềm hay chưa?

Lê Hoàng , Theo Trí Thức Trẻ
Bình luận 0

Khi bạn nhìn vào người khác, bạn chỉ cần biết hai điều: 1, bạn cần gì từ họ và 2, họ đã làm thật tốt công việc của họ hay chưa. Những module phần mềm, thiết bị công nghệ cũng vậy.

Một trong những lý do tôi luôn khuyên người quen của mình học code chỉ để hiểu cách code là bởi thế giới phần mềm có rất nhiều nguyên tắc hay bí quyết mà bạn có thể áp dụng vào vào chính cuộc sống của mình. Trong bài viết này, tôi sẽ kể với các bạn về "triết lý coder" mà tôi tâm đắc nhất: "tính đóng gói" của mỗi module phần mềm, mỗi người, mỗi đồ vật hay bất cứ thứ gì khác.

Mớ bòng bong của những nỗi lo

Thế nào gọi là tính đóng gói? Chắc hẳn, bạn cũng đoán ra rằng mỗi hệ thống phần mềm đều được chia làm nhiều phần thuộc về trách nhiệm của nhiều cá nhân, tổ chức. Lấy một ví dụ (có vẻ) khá đơn giản là hệ thống quản lý tài chính của một công ty chẳng hạn. Ứng dụng này cần ít nhất 2 module: module A tổng hợp chi phí, module B tổng hợp doanh thu. Cả 2 module đều lấy dữ liệu và truyền kết quả cho module C, vốn có nhiệm vụ trực tiếp quản lý kho dữ liệu (database).

Mỗi module sẽ có một đội kỹ sư phần mềm chịu trách nhiệm, và rõ ràng chỉ 3 đội là chưa đủ. Công ty trong ví dụ của chúng ta sẽ cần thêm 2 đội chuyên lập trình ra giao diện đồ họa cho người dùng cuối có thể vào xem, nhập và sửa dữ liệu: đội D làm giao diện di động và đội E làm giao diện web.


Một ví dụ điển hình về cấu trúc phức tạp của các hệ thống phần mềm.

Một ví dụ điển hình về cấu trúc phức tạp của các hệ thống phần mềm.

Như bạn có thể thấy, mỗi hệ thống phần mềm thực chất bao gồm rất nhiều thành phần chia sẻ cho nhiều bên. Điều này khiến cho mối quan hệ về trách nhiệm giữa các đội nhóm và cá nhân cùng thực hiện một hệ thống phần mềm trở nên chồng chéo.

Đi kèm với chồng chéo luôn là những nỗi lo vu vơ. Thử tưởng tượng bạn là người đội B, nếu đội C sử dụng cách truy xuất cơ sở dữ liệu quá chậm chạp thì kết quả module B trả ra cũng sẽ chậm chạp. Nếu đội D và đội E không thực hiện kiểm tra dữ liệu người dùng nhập vào (không bắt lỗi nhập chữ cái khi phải nhập con số) thì hàm xử lý của bạn có thể gặp lỗi chết "bất thình lình". Đáng sợ, đúng không?

Tính đóng gói

Thực tế là chẳng có một coder nào lo lắng theo kiểu vậy cả. Một thiên tài công nghệ nào đó đã đưa ra một quyết định quan trọng: khi nhìn vào phần việc (module) của người khác, bạn sẽ không bao giờ đặt câu hỏi họ đang làm việc đó như thế nào. Công việc của họ, module của họ là một cái hộp đóng chặt – bạn chỉ nên nhìn thấy những gì ở bên ngoài, chỉ nên biết chiếc hộp đó sẽ làm được gì chứ không bao giờ được mở ra.

Tại sao lại nói cách nghĩ này là "thiên tài"? Hãy nghĩ xem: nếu bạn có lo lắng về chất lượng công việc của đội A thì nỗi lo này sẽ giải quyết điều gì? Bạn ở đội B, có dám thuyết phục "sếp" đội khác rằng bạn mới là người hiểu rõ về chuyên môn của họ? Tai hại nhất, cứ mải mê nghĩ xem liệu các module khác có hoàn thành trách nhiệm với module của bạn hay không thì bạn sẽ phân tâm về công việc của chính mình - vốn là thứ duy nhất thuộc trách nhiệm của bạn, là kết quả để "sếp" bạn đánh giá.

Hay dùng biểu tượng cái hộp mở nhưng các package/module phần mềm thực chất lại là những chiếc hộp đóng. Chỉ duy nhất cha đẻ của chiếc hộp đó biết được cơ chế hoạt động bên trong.
Hay dùng biểu tượng cái hộp mở nhưng các package/module phần mềm thực chất lại là những chiếc hộp đóng. Chỉ duy nhất "cha đẻ" của chiếc hộp đó biết được cơ chế hoạt động bên trong.

Tư duy "đóng gói" bởi vậy đã trở thành một trong những tôn chỉ quan trọng của ngành phần mềm. Khi bắt tay vào thực hiện một module mới, người kỹ sư đều phải mang tâm thế rằng tất cả những người khác, những module khác đều đã làm tốt phần việc của họ (và sẽ không can thiệp vào phần việc của mình). Bằng cách này mỗi lập trình viên sẽ loại bỏ những nỗi lo vu vơ và thực sự giải quyết bài toán của riêng mình bằng toàn bộ trí lực. Càng ngày họ sẽ càng tinh thông lĩnh vực của riêng họ thay vì là kẻ vừa "biết tuốt nhưng không biết gì" lại còn hay "lo bò trắng răng".

Đóng gói Apple và Google

Tôi hay mang tư duy "đóng gói" nhìn thế giới công nghệ. Vì là iFan nên tôi xin phép được... kể xấu Android trước tiên: các fan Android rất thích đem thông số cấu hình ra để khẳng định sự vượt trội của smartphone Android so với iPhone. Nhưng mối quan hệ giữa cấu hình và độ mượt của trải nghiệm người dùng lại là trong cái "hộp" đóng kín của Google, Samsung, LG, những cái hộp chứa đầy các thành tựu vật lý/hóa học và những dòng code không bị lộ ra ngoài... Tại sao chúng ta chẳng ai thực sự hiểu những cái hộp ấy mà lại đem chuyện trong hộp ra tranh cãi với nhau?

Tôi cũng hay bị quy chụp sai là "fan cuồng Android". Lý do là vì tôi đã nhiều lần chỉ trích Apple mà lần gần đây nhất là việc iPhone 7 chẳng mấy mới mẻ so với iPhone 6 nhưng vẫn được Tim Cook đặt tên "mới" để moi tiền người dùng. Những người phản đối nói rằng Tim Cook đường đường là CEO của một công ty lớn nên tôi không có quyền chê bai.


Phần lớn các thiết bị điện tử của chúng ta, từ đều là những chiếc hộp đóng. Với iFan, Apple cũng chỉ nên là một chiếc hộp có tính năng.

Phần lớn các thiết bị điện tử của chúng ta, từ đều là những chiếc hộp đóng. Với iFan, Apple cũng chỉ nên là một chiếc hộp có tính năng.

Hãy thử áp dụng nguyên tắc đóng gói vào trường hợp này: iFan thích thú với iPhone và iPad chứ đâu cần phải quan tâm đến những chuyện đang diễn ra tại nhà máy Foxconn, trong phòng lab của Jony Ive hay phòng họp của Tim Cook? Đó là cái hộp đóng của Apple, cái hộp trừu tượng có trách nhiệm tạo ra iPhone. Tôi chỉ quan tâm đến chiếc iPhone tôi cầm tay mà thôi.

Gỡ rối cuộc sống

Ý nghĩa của nguyên tắc đóng gói không chỉ gói trong những dòng code khô khan hay những chiếc smartphone vô tri. Kiểu nhìn "đóng gói" đã luôn giúp tôi tránh được các thông tin vô nghĩa để dành khoảng trống suy nghĩ cho những điều có nghĩa. Ví dụ: phát ngôn của các ca sĩ, chuyện tình ái của các cầu thủ ngoại hạng... Con người thì ai cũng có tính tò mò, nhưng cuối cùng thì nhiệm vụ của các ca sĩ đóng gói trong chữ "hát", cầu thủ trong "đá bóng". Nếu cứ quan tâm đến chuyện đời tư của họ thì chắc những người mê Metal như tôi phải cảm thấy xấu hổ lắm.

Quan trọng hơn, tôi thường cố gắng nhìn mọi chuyện thật rành mạch bằng cách chia tầm nhìn của mình thành những cái gói, cái hộp. Câu hỏi tự đặt ra là "người khác thực sự cần gì từ mình" chứ không phải là "người ta có biết mình đang phải làm những gì như thế nào hay không?".

Có những chuyện tưởng khó giải thích lại trở nên cực kỳ dễ giải thích.

Ví dụ, một người bạn của tôi ghen tị vì đã gắn bó với công ty được 5 năm, ngày nào cũng đi làm đúng giờ mà lương lại thấp hơn nhân viên khác ít kinh nghiệm, ngày nào cũng đi muộn. Tôi hỏi, bạn có nhìn ra sếp có một cái hộp riêng, bạn có hộp riêng, người kia cũng có hộp riêng mang tên "công việc". Sếp là... sếp nên sẽ chẳng bao giờ biết được mỗi ngày bạn đến lúc mấy giờ, phải đọc bao nhiêu mail, viết bao nhiêu sổ sách. Thứ sếp bạn thực sự quan tâm đến là gì, là kết quả công việc hay là giờ đi làm của bạn?

Bạn có nhìn ra rằng người kia đã đem về được cho công ty nhiều hợp đồng có giá trị hơn bạn? Ngồi một chỗ ghen tị thì sẽ chẳng bao giờ lên được lương, tại sao không tập trung vào cái hộp (công việc) của mình để bên ngoài người ta thấy cái hộp ấy thật bóng bẩy?

Đã 10 năm đã trôi qua kể từ khi tôi học được bài học "đóng gói" từ những dòng code C++. Đã rất nhiều lần tính đóng gói giúp cho tôi có thể nhìn mọi thứ rành mạch hơn, giúp tôi theo đuổi được những gì mình thực sự mong mỏi, giúp tôi đem lại giá trị cho người khác bằng cách cố gắng thấu hiểu nguyện vọng thực sự của họ. Không phải lúc nào mọi chuyện cũng có thể chia thành những cái gói cái hộp, nhưng sao bạn không thử một lần nhìn lại những điều nhỏ nhặt như chiếc smartphone, quyển sách đọc dở, ván CS đêm khuya hay món quà sinh nhật muộn đắt tiền bằng tư duy "đóng gói"... Tôi tin rằng bạn sẽ nhìn thế giới khác đi ít nhất là một chút.

Bình luận

Tin cùng chuyên mục
Xem theo ngày