Tư duy tối ưu

Tại sao nên đọc bài này

Làm nhanh hơn > Hiệu quả hơn > Tăng lương > Nhiều thời gian hơn > Chill hơn

Nghe về tư duy tối ưu

Lâu rồi không viết gì về technical, có khi mọi người quên mất mình vẫn code hàng ngày, code sml nên muốn viết một vài suy nghĩ về tư duy tối ưu.

Mình là một thằng siêu thích optimize, mọi thứ chạy trong đầu mình khi code luôn là làm sao để code nhanh hơn (deliver nhanh hơn), làm sao để code hiện tại chạy nhanh hơn (BigO gì đó bé nhất), làm sao để làm cho nó “có vẻ nhanh hơn”. May mắn hồi xưa đi làm công ty cũ thì cũng toàn làm những việc như vậy. Hồi đó thì chỉ nghĩ về mấy thứ như vậy, cho tới khi mình gặp một người anh, có mind set optimize tới từng chi tiết trong cuộc sống. Vậy là mới ồ ra hóa ra mình trình vẫn đang còn còi lắm.

Anyway, let’s start.

Start with WHY

Tối ưu hơn nghĩa là hồi trước task A cần 2H, thì bây giờ task A chỉ cần <2H thì đã gọi là tối ưu, hoặc vẫn 2H nhưng tốn ít năng lương hơn. Cùng kết quả, chất lượng output mà chi phí ít hơn là tối ưu (thường là thời gian). VD api trả về response của bạn vẫn y vậy, nhưng sau khi qua tay bạn phù phép, response time ít hơn…

Tại sao tối ưu quan trong? Vì thời gian quan trọng. Tới cuối thì một giờ của bạn làm được bao nhiêu value? Nên Optimize là một cách bắt buộc để có thể trở thành một người tạo ra nhiều value hơn.

Optimize pattern

Sequence to parallel/concurrency

Cái gì bạn đang làm tuần tự, hãy biến nó thành tác vụ song song. Eg

function login(email: string, password: string) {
	await validateEmail(email);
	await validatePassword(password);

	await login();
}

Có thể trở thành

function login(email: string, password: string) {
	await Promise.all([validateEmail(email), validatePassword(password)];

	await login();
}

Cái này thì chắc là rất rất phổ biến rồi, thay vì bạn làm 1 xong làm 2, xong làm 3. Thì coi xem trong đống đó có cái gì làm cùng lúc được thì đẩy qua parallel.

Ở code thì mình nghĩ nó cũng khá phổ biến không phải thứ gì quá cao siêu nhưng còn cuộc sống thì sao? Vừa nghe podcast vừa chạy bộ, vừa ăn cơm vừa đọc tin về công nghệ, vừa đi lên cầu thang vừa lấy chìa khóa…

Chà mấy cái kết hợp này đúng là blow my mind luôn, vì trước h mình chỉ nghĩ tới code thôi mà lại không thèm optimize mấy cái trong cuộc sống kiểu như vậy. Mình thấy rất nhiều người tối ưu theo kiểu kết hợp công việc và giải trí. Kiểu như vừa làm việc vừa facebook, vừa tập thể thao vừa xem tiktok. Cũng là một dạng tối ưu! Có điều mọi người mặc định có năng lực tối ưu công việc và giải trí mà lại toàn bỏ qua tối ưu công việc và công việc.

Đối với mình thì tối ưu cho công việc để dành full thời gian giải trí sẽ ok hơn.

Sẽ có một ý phản biện là não người chỉ optimize cho việc tập trung và nếu phải chuyển qua chuyển lại qua nhiều task qua nhiều thì sẽ bị kém hiệu quả rõ rệt. Cái này thực tế mình cũng bị và cũng thấy nhiều. Tuy nhiên việc biến bản thân từ sequence thành parallel là khả thì vì mình thấy không ít người xung quanh của mình tập được skill này. Mình thì cũng vẫn đang tập

Indexing - Ngăn nắp

Cái này chắc ai làm backend cũng biết, ai làm FE thì chắc chưa có cơ hội được nghe qua nhiều. Hiểu cơ bản về indexing thì giống kiểu bạn thiết kế một cuốn từ điển. Nếu bạn bỏ từ ngữ lộn xộn vào trong cuốn từ điển đó thì mỗi khi cần tìm từ gì đó chắc phải dò từng trang cho tới khi tìm được từ đó. Còn nếu cuốn từ điển đã được index thì các từ được kí hiệu theo alphabel, có thêm cái mực ở sách để dễ tìm nữa. Sau khi được index thì bạn tìm từ gì, bạn xem coi ký tự bắt đầu nó nằm ở khoảng nào trong từ điển, tiếp tới kí tự tiếp theo, tiếp theo cho tới khi tìm được đúng từ cần tìm.

Thôi nói cách khác để tối ưu theo kiểu indexing, nghĩa là bạn sắp xếp mọi thứ một cách ngăn nắp, có quy tắc phổ biến. Việc bạn code đúng structure, đúng format cũng là một dạng tối ưu như vậy.

Cuộc sống thì sao? Cái tips này đặc biệt hiệu nghiệm với những người hay quên đồ nè. Hồi xưa mình hay quên lắm còn giờ thì gần như không bị nữa. Mình hay có cái balo đi làm, và mỗi ngăn mình đều quy hoạch cho nó đựng gì luôn. Ngăn nào đựng ví, ngăn nào để chìa khóa, ngăn nào để dây sạc. Mỗi lần sử dụng xong thì mình đều lại để đúng ngăn đó. Nhờ có việc ngăn nắp như vậy nên mình chả bao giờ tốn thời gian đi kiếm đồ vì nếu nó ko ở đó nghĩa là nó bị mất rồi. Mỗi khi có đồ gì mới thì mình đều phải suy nghĩ chỗ riêng cho nó, và tập thói quen để nó ở đâu. Vd như kì này mính mới mua kính, cách để không làm mất kính là mỗi lần ko đeo mà không phải ở nhà mình đều treo vào cổ áo hết.

Phản hồi nhanh, keep update

Cái này không phải là tối ưu lắm, mà kiểu đánh lừa não bộ hơn, mấy bạn làm frontend thì chắc biết cái technique này.

Trong bay này mình có liệt kê một số tips để mang lại cảm giác nhanh hơn

https://thanhle.blog/blog/frontend-performance-pattern-en

Một VD về optimize cho Nimbus. Trước đây nếu query token holding, tụi mình sẽ gom tất cả các chain vào một request. Cái này user phải đợi tới khi có response ở tất cả các chain thì mới xem được portfolio của họ. Sau này tụi mình quyết định tách request thành nhiều chain. Bằng cách này có chain nào trả về data trước là mình có thê update được cho users. Về tổng thời gian kiểu gì cũng chậm hơn cách cũ nhưng về UX thì users cảm thấy nhanh hơn rất nhiều Trong cuộc sống thì sao? Khi khách hàng hay sếp hỏi/yêu cầu bạn làm một việc gì đó, hãy phàn hổi ngay lập tức, update progress cho người ta. Làm cách này sẽ giúp khách hàng/sếp của bạn nghĩ là bạn đang làm nhanh. Trong khi thực tế bạn im luôn xong làm xong thì thờ gian cũng như nhau. Nhưng mà trong đầu mỗi người gần như được lập trình rồi, tôi thấy có phản hồi sớm, tôi nghĩ nó nhanh hơn và tốt hơn.

Chuẩn bị kịch bản

Mình nhớ hình như trong sách “Những kẻ xuất chúng” có một thí nghiệm như này:

Trong một đội bóng rổ, sau đó chia thành 2 nhóm. 1 nhóm luyện tập việc ném bóng vào rổ ngoài thực tế, nhóm con lại được cho về phòng chỉ cần tưởng tượng mình đang luyện tập việc ném bóng trong đầu. Sau một khoảng thời gian, 2 đội sẽ làm bài test xem hiệu quả ntn. Kết quả là 2 nhóm có bài test với số điểm bằng nhau.

Nghĩa là tưởng tượng mình đang làm một thứ gì đó cũng là một dạng luyện tập hiệu quả. Vì vậy nếu bạn tưởng tượng và tập luyện cho các kịch bản khác nhau thì tới lúc thực tế sẽ giúp ích rất nhiều. Vd trước khi gặp một người mới mình đều dành một ít thời gian gọi là background-check để xem người này ntn, cách tiếp cận và nói chuyện ntn,…

Không phải tự nhiên mà khi đi làm lúc nào bạn cũng phải Plan trước cho nhưng việc mọi người sẽ làm. Nó là một cách để tối ưu đó, việc chuẩn bị nhưng công việc sắp tới, dead line cần hoàn thiện sẽ khiến bạn tự co dãn bản thân để fit vào các kịch bản đó. Nếu bạn không plan, nghĩa là bạn có nguy cơ rất lớn chỉ làm được một vài việc và đôi khi những việc như vậy còn không có value nữa.

Còn trong việc code thì sao? Mình luôn chạy kịch bản khi một component này chết thì sẽ xử lý ntn, con DB chết thì làm sao,… Nó không khiến hệ thống của mình build stable hơn, nhưng nó giúp mình mau chóng có biện pháp để xử lý hơn. Có một cái hơi bad là mình thường không ghi lại mà toàn nghĩ trong đầu, nêu hầu hết khi có issue chỉ có mình là giải quyết hiệu quả nhất.

Tối ưu cần sự suy nghĩ, chuẩn bị, luyện tập và sáng tạo

Mình nghĩ chắc là còn cả tỉ cách để một cá nhân tối ưu, nhưng nó xuất phát từ nhu cầu của mỗi người, cũng cần customize lại theo tùy người. Do đó để tối ưu công việc, hay thậm chí là cuộc sống cần rất nhiều năng lượng cho suy nghĩ. Suy nghĩ để xem coi đang có vấn đề ở đâu, suy nghĩ xem chỗ nào đang thừa thãi,… Rồi cả chuẩn bị và tập luyện, vì việc tối ưu là bạn đang bỏ đi những cái cũ, suy nghĩ cũ, cách làm cũ, thói quen cũ,… để thay nó bằng những thứ “có thể” là tốt hơn - hoặc không. Và cuối cùng, tối ưu cần sự sáng tạo, đối với mình, sáng tạo là đỉnh cao nhất của tối ưu. Bạn thử nghĩ xem có pattern nào mà Elon Musk nghĩ ra việc phóng tên lửa thì không cần vứt luôn cái hệ thống đẩy đi? Dẫn tới tối ưu về chi phí một cách đáng kinh ngạc

Quy trình để optimize

Có một cái là đôi khi suy nghĩ về optimize quá sớm sẽ là là một cách siêu deoptimize. Cái này đặc biệt hay thấy ở mấy bạn hay over-engineer. Do đó Optimize cần một process để đảm bảo thứ mình nghĩ là optimize thực sự là optimize

Thường thì mình follow theo cái này. Cái của bác e lươn thì chưa thử

Quickly test the idea

Make it work

Make it fast

Make it scalable

The bad side

Mình nghĩ là để tối ưu thì rất khó vì bạn phải hiểu nhiều thứ, hiểu cách mọi thứ đang vận hành như thế nào, hiểu bản thân, hiểu cả team hay công ty mình đang làm, có khi là hiểu đất nước mình đang sống, hiểu cả nền kinh tế đang vận hành. Vì vậy tối ưu cần sự hiểu biết, thử sai và rèn luyện rất rất nhiều. Nên đôi khi cố làm mà không được.

Thôi thì cái gì cũng có giá của nó, giá trá không đủ nên có lẽ chưa học được skill đó thôi. Không optimize cái này thì còn cái khác. Miễn là bạn ám ảnh về điều đó thì mình tin kiểu gì bạn cũng sẽ tối ưu được 😃

Sắp tết rồi chúc mọi người ai về quê thì thượng lộ bình an, an yên cùng gia đình nhé!