Lời nói đầu
Tóm tắt tiểu sử cá nhân chút thì tôi xuất thân là một cậu sinh viên học khoa Vật lý, chuyên ngành Vật lý lý thuyết, với ước mơ ban đầu trở thành một nhà nghiên cứu, tiến thân theo con đường học vị, lên thạc sĩ, rồi tiến sĩ, rồi gì ko biết nữa. Ấy là khi tôi còn đam mê với vật lý. Nhưng khi đam mê ấy dần suy thoái, tôi trở nên vô hướng, ko có mục tiêu rõ ràng.
Nguyên nhân chính thì do tôi tự đánh mất bản thân mà thôi, chẳng đổ lỗi cho ai ngoài chính mình được. Trong cơn khủng hoảng của một sinh viên năm cuối ko ra được trường, tôi nhận thấy rằng mình có khả năng lập trình, ít ra code ko làm tôi chán. Thế là tôi đã tự học lập trình web (vì làm web dễ kiếm việc hơn), rồi ứng tuyển vào một công ty nhỏ.
Hồi đầu vào công ty, tôi còn khá tự ti vì mình không phải dân chuyên công nghệ thông tin. Ngày xưa còn học ở đại học, tôi có học ngôn ngữ C để lập trình tính toán trong vật lý. Nhưng lập trình để tính toán, mô phỏng rất khác với lập trình thành sản phẩm thật.
Từ những điều nhỏ nhất như cách đặt tên biến, cách tách hàm và tái sử dụng code, cho đến tác phong công nghiệp, cách làm việc nhóm và tương tác trong team. Để làm quen được, điều quan trọng nhất là tôi phải phá bỏ những thói quen xưa cũ, và học cách gạt bỏ đi những cảm xúc tiêu cực cá nhân.
Việc teamwork với nhóm ko tránh khỏi va đụng bởi những cái tôi. Dù rằng tôi thay đổi khá chậm, nhưng ko có gì là ko thể cả. Nhìn xung quanh thì trong công ty cũng có khá nhiều người trái ngành như tôi thôi.
Có nhiều người cũng xuất thân học khoa học giống như tôi, có người học ngoại ngữ, có người học kinh tế, có người học kĩ sư,… Nhìn những con người tài giỏi đang nỗ lực liên tục như thế, tôi ko dám rêu rao mình làm trái ngành nữa, mà thay vào đó chính chuyên ngay từ bây giờ.
Nhiều người bạn, anh chị em chia sẻ với tôi rằng đi làm rồi thì kiến thức đại học gần như vứt đi hết, nhất là những ai làm trái ngành. Ví dụ làm lập trình web thì cần biết đếch gì tích phân, đạo hàm đâu, có phải tính toán lực va chạm, tính ứng suất dòng chảy, năng lượng điện trường, hay quang điện phát xạ bước sóng bao nhiêu.
Nhận xét này không sai! Tùy mỗi ngành nghề mà kiến thức bạn được học có áp dụng được không. Sau hơn 1 năm làm lập trình viên, tôi nhận ra rằng cho dù tôi ko dùng những tính toán kia vào thực tế công việc, nhưng có những điều tôi học được ở vật lý có thể áp dụng được ở muôn nơi, thậm chí tôi coi đây là lợi thế của tôi.
If everyone is thinking alike, then no one is thinking.
BENJAMIN FRANKLIN
Bất biến và sự phổ quát
Trong vạn biến sẽ luôn tồn tại thứ bất biến. Các định luật vật lý, các phương trình, các đại lượng ko đổi chính là mô tả cho sự bất biến đó.
Trong lý thuyết về chuyển pha, khi nghiên cứu sự chuyển pha lỏng-khí của nước với sự chuyển pha sắt từ của vật liệu sắt từ, người ta nhận thấy hiệu số nồng độ của 2 pha ở cả 2 hệ đều tỉ lệ với nhiệt độ với hệ số như nhau, mặc dù đây là 2 hệ vật lý hoàn toàn khác nhau.
Thực nghiệm: 
. Lý thuyết: 
.
Bất biến 
này ko hề phụ thuộc vào hệ gì, chất gì, nó bất biến trong các hệ vật lý khác nhau. Thứ duy nhất nó phụ thuộc đó là số chiều không gian của hệ (thường là không gian 3 chiều).
Từ một lý thuyết thuần túy là toán hình học đã được ứng dụng vào vật lý để giải thích các hiện tượng chuyển pha khác nhau, đó là lý thuyết topo và bất biến topo, mở ra một cái nhìn phổ quát cho các phạm vi vật lý khác nhau, thậm chí là các ngành khoa học khác nhau.
Các bức tranh nhỏ lẻ dần được khái quát thành một bức tranh chung, ở đó có những bất biến, có những định luật trở nên phổ quát. Chúng ta đã thống nhất quang, điện và từ vào một lý thuyết điện động lực học, kết nối cơ và nhiệt thành nhiệt động lực học, rồi kết nối cơ nhiệt điện quang bằng cơ học lượng tử và cơ học thống kê. Một bức tranh chung cho tất cả, lý thuyết của vạn vật, vẫn đang được các nhà vật lý phác thảo.
Trong số các ngành khoa học cơ bản, vật lý là ngành gần với triết học nhất. Cách mà vật lý nhìn vào bản chất của thế giới, nhìn vào quy luật của sự vận động của thế giới, đều mang tính triết học và áp dụng tương tự vào các lĩnh vực khác trong đời sống.
Khi bạn code một hàm formatDate như một hàm common cho các màn hình khác nhau sử dụng chẳng hạn, có thể coi hàm formatDate như một bất biến trong “hệ” project của bạn. Mở rộng hơn chút, màn hình muốn thể hiện các field, nhưng các field này phải là động (tức là ko code cứng field này là tên, field kia là tuổi vào màn hình).
Thì bạn phải xác định các loại field là bất biến, còn người dùng chọn field nào, đặt ở đâu, ấy là sự tùy biến. Hoặc như dự án mới đây của mình, khách hàng muốn tùy biến hiển thị các field trên trang web. Ko những tùy biến vị trí hiển thị (tức là tùy biến layout đó) thì còn muốn tùy biến được cả field, cho chữ to chữ nhỏ, màu sắc tùy ý.
Ô thế cơ chế nào đáp ứng được đây? Tôi đã đề xuất lên anh leader phương án “định nghĩa container” và “tùy biến CSS”. Container là những component dùng để render ra các khung định hình bố cục, mà mỗi ô trong đó mình có thể truyền component khác vào được (field hoặc container con lồng vào trong).
Còn tùy biến CSS thì nếu bạn đã quen việc sử dụng các thư viện CSS như Bootstrap, Tailwind thì sẽ hiểu ngay ý tưởng của tôi. Đó là sử dụng chuỗi các class CSS được định nghĩa bởi thư viện để làm biến đổi hình thái của field, các chuỗi class CSS sẽ được lưu vào DB và truyền cho màn hình thông qua API.
Bởi tôi nhận thấy rằng, biến đổi hình thái của field thì chỉ cần CSS là đủ, chức năng cũng như data hiển thị vẫn thế, chớ có dại mà đi viết tầm chục cái hàm render trong code. Như vậy tôi đã xác định cái bất biến là hàm render của field.
Chỗ truyền className tôi sẽ ko viết cứng, mà thay bằng biến lấy từ api, khi api trả về dữ liệu tự nó đắp vào và thế là hiển thị được như tôi mong muốn. Ý tưởng đó của tôi còn đưa đến ưu điểm ko ngờ, đó là có thể apply trực tiếp được sự thay đổi CSS khi người dùng click chọn các option khác nhau mà chưa cần phải save hay reload trang.
Cổ nhân có nói: “Dĩ bất biến, ứng vạn biến”, lấy cái bất biến để ứng phó với những yêu cầu khác nhau của khách hàng.
Bất biến sẽ luôn đi cùng với sự phổ quát. Trong một nghĩa hẹp, khi tôi tìm được bất biến, tôi sẽ tạo ra (hoặc tìm ra) được cơ chế vận động chung của các đối tượng khác nhau có chung bất biến đó. Cụ thể trong bài toán thực tế trên của tôi, container tôi cũng có thể xem như là field.
Tôi có thể tùy biến CSS cho nó, cho nó hiển thị dạng 2 cột, 3 cột, vân vân, tùy vào số lượng các field con nằm bên trong và class CSS mà tôi sẽ truyền cho nó. Trong nghĩa rộng hơn, sự phổ quát có thể mở rộng sang bất kì lĩnh vực nào.
Ví dụ, nói về responsive, những ai code web đều biết đó là kĩ thuật code frontend sao cho bố cục màn hình cũng như kích thước các phần tử sẽ thích ứng với các kích thước màn hình khác nhau. Các phần tử sẽ thay đổi kích thước liên tục, cho đến điểm breakpoint thì sẽ biến đổi sang trạng thái mới.
Ví dụ như sidebar đang mở rộng thì đến điểm breakpoint nào đó thì co lại thành một thanh lề nhỏ. Trong câu chuyện bên trên về sự chuyển pha của các hệ vật lý, mô tả cho các pha và sự chuyển pha bằng giản đồ pha.
Hiệu số nồng độ vật chất 2 pha biến động liên tục, cho đến điểm chuyển pha thì chúng biến đổi hoàn toàn thành pha khác. Khi có sự liên tưởng kết nối các câu chuyện khác nhau, bạn sẽ thấy chúng có thể có chung quy luật vận động.
Và biết đâu, hiểu biết và kinh nghiệm ở câu chuyện này có thể gợi mở giúp bạn tìm ra giải pháp cho câu chuyện kia. Ví dụ như hiểu về quá trình dịch mã RNA trong sinh học có thể giúp bạn hiểu về cơ chế render từ template của các framework như Magento, Nodejs.
Tổng quát hóa. Đại thể và tiểu thể
Nói ngắn gọn thì tổng quát hóa là tư duy làm sao để tái sử dụng code và làm tăng tính mở rộng của code. Khi code 2 màn hình khác nhau, bạn nhận thấy có vùng giống nhau hoặc trong quá trình code logic gì đó, bạn nhận thấy rằng 2 logic này chức năng giống nhau, đầu ra giống nhau, chỉ khác nhau mỗi đầu vào. Hãy nghĩ đến chuyện tách ra thành thành phần chung, rồi cho chúng kế thừa thành phần chung ấy, hoặc tổ hợp chúng lại thành một nếu có thể.
Đại thể là những thành phần chung, có thể áp dụng ở nhiều nơi và có tính bảo tồn. Còn tiểu thể là những thành phần nhỏ vụn vặt, chỉ tồn tại trong phạm vi hẹp, và mục đích sử dụng cá biệt. Ví dụ khi tôi code vùng thiết định tùy biến field, tôi tính rằng field nào thì cũng sẽ có trường field label và trường field item, thì tôi sẽ coi vùng render ra các option cho field label và field item là đại thể. Một số loại field khác có thể có thêm trường khác, ví dụ field ảnh thì có chỉnh tùy biến cho ảnh, cho dòng mô tả ảnh, thì 2 cái này là tiểu thể.
Đấy là lối tư duy khó, nhưng cực kì quan trọng và nên được rèn luyện thường xuyên. Nó khó bởi vì nó đòi hỏi bạn phải tư duy có chiều sâu vào thiết kế. Đầu tiên phải xác định những bất biến (ko nhất thiết bất biến phải là tuyệt đối, một thành phần common code một lần có thể tái sử dụng ở nhiều nơi cũng có thể coi là bất biến), sau đó xác định đại thể bao trùm bên ngoài bất biến, còn lại những thứ cá biệt thì là tiểu thể. Ngoài ra nó khó còn vì ko phải ai cũng có tư duy ấy, hoặc quan điểm của mỗi người là ko giống nhau. Do đó, team cần ngồi lại thảo luận với nhau về cách tổng quát hóa cho project của dự án.
Vì sao.
Trong một status của anh Hoàng – Tôi đi code dạo, anh nói đừng chỉ hỏi “How”, hãy tập hỏi và trả lời cho “Why”. Đúng như vậy. Khi ta hỏi “Why” tức là ta muốn hiểu bản chất, hiểu vì sao phải thế, vì sao chọn cái này mà ko chọn cái kia.
Tôi chợt nhận ra rằng, với dân Vật lý chúng tôi, đó đã là câu hỏi thường trực. Từ những câu chuyện về một nhà khoa học nổi tiếng nào đó, hay phát kiến khoa học vĩ đại nào đó làm thay đổi hiểu biết của con người về vũ trụ này, tất cả đều xuất phát từ những câu hỏi vì sao.
Albert Einstein đã tự hỏi vì sao vận tốc ánh sáng đo được trong giao thoa kế của Fizeau là như nhau, mà đáng lẽ chúng phải lệch nhau đúng bằng 2 lần vận tốc dòng chảy của môi trường chứ, theo công thức cộng vận tốc.
Ông đặt ngược lại vấn đề, bất biến không phải là thời gian, mà là vận tốc ánh sáng, từ đó đưa ra lí thuyết vĩ đại nhất của thế kỉ 20, lí thuyết tương đối hẹp của Einstein. Chỉ có đặt câu hỏi “Vì sao”, bạn mới thúc giục bản thân đi tìm lời giải đúng đắn nhất và toàn diện nhất.
Trích: Mai trời sáng – Một dân IT trái ngành từ FPT
