- Gu kỹ thuật là một khái niệm khác với năng lực kỹ thuật; một người có thể rất giỏi nhưng gu kém, và cũng có thể chưa giỏi nhưng lại có gu tốt
- Gu của kỹ sư phần mềm là khả năng lựa chọn các giá trị kỹ nghệ phù hợp với dự án
- Nó bộc lộ qua cảm nhận như đoạn mã nào trông đẹp/xấu, quyết định thiết kế nào tạo cảm giác thỏa đáng, hay người đó ám ảnh với loại vấn đề nào; và điều này phản ánh tập hợp các giá trị kỹ nghệ mà bản thân coi trọng
- Mọi quyết định trong kỹ nghệ phần mềm đều là chuỗi đánh đổi; kỹ sư chưa trưởng thành thường xem một cách tiếp cận nào đó là chân lý tuyệt đối, còn kỹ sư trưởng thành thì linh hoạt điều chỉnh giá trị theo ngữ cảnh
- Gu tốt là khả năng chọn thứ tự ưu tiên của các giá trị phù hợp với một dự án cụ thể, còn gu kém thể hiện ở sự cứng nhắc khi bám chặt vào những tiêu chuẩn tuyệt đối như "best practice"
- Gu được tích lũy qua trải nghiệm với nhiều dự án khác nhau và tư duy cởi mở, và cuối cùng việc có gu tốt hay không sẽ lộ ra qua sự thành bại của dự án
Sự khác biệt giữa gu kỹ thuật và năng lực
- Gu kỹ thuật không nhất thiết trùng khớp với năng lực xuất sắc
- Cũng như ai cũng có thể phân biệt món ăn ngon và dở независимо với khả năng nấu nướng, trong phần mềm gu thường được hình thành trước cả năng lực
- Gu của một kỹ sư được phản ánh qua việc họ thấy đoạn mã nào "trông hay" hay "trông không ổn"
- Việc cảm thấy hài lòng với một số quyết định thiết kế nào đó, hay chú ý nhiều hơn tới một số loại vấn đề, cũng vận hành như một phần của gu
- Năng lực kỹ thuật có thể phát triển nhờ lặp lại và học tập, nhưng gu lại phát triển theo cách mơ hồ và trực giác hơn
-
Các dấu hiệu của gu kỹ nghệ
- Cảm giác "đoạn mã này trông đẹp/xấu"
- Cảm giác thỏa mãn mạnh mẽ hoặc dửng dưng với một số quyết định thiết kế
- Những vấn đề phần mềm vẫn khiến bạn bận tâm sau giờ làm, và những vấn đề không như vậy
- Có thể xem gu là khả năng tiếp nhận các giá trị kỹ nghệ phù hợp với dự án hiện tại
Phân biệt giữa năng lực và gu
- Có một câu hỏi rằng liệu "đoạn mã trông hay" có nhất thiết phải là đoạn mã thực sự tốt hơn hay không
- Ví dụ: người thích
map/filter coi trọng tính dễ đọc và hàm thuần, trong khi người thích vòng lặp for có thể coi trọng hiệu năng và khả năng mở rộng đơn giản
- Đây không phải vấn đề đúng sai mà là sự khác biệt về các giá trị được ưu tiên
- Vì mỗi ngôn ngữ và mỗi ngữ cảnh đều có ưu và nhược điểm riêng, nên không có lựa chọn nào mặc định là tốt hơn
- Mỗi kỹ sư coi trọng những giá trị khác nhau, và vì thế sở thích cũng khác nhau
Gu kỹ nghệ là gì
- Gần như mọi quyết định trong kỹ nghệ phần mềm đều là sự cân bằng giữa các giá trị xung đột nhau (trade-off)
- Kỹ sư non kinh nghiệm thường quá cố chấp với gu của bản thân
- Kỹ sư trưởng thành nhìn ra lợi ích từ nhiều góc độ khác nhau và coi trọng việc chọn phương án phù hợp với tình huống hiện tại
- Điều quan trọng không phải là X (công nghệ) hay Y (công nghệ) tốt hơn, mà là trong dự án hiện tại, ưu điểm của X có cần hơn Y hay không
-
Ví dụ về các giá trị kỹ nghệ
- Resiliency: hệ thống có vận hành tốt ngay cả khi gặp sự cố hay vấn đề mạng hay không
- Speed: có đạt hiệu năng gần giới hạn lý thuyết hay không, có quá nhiều công việc thừa hay không
- Readability: kỹ sư mới có thể nhanh chóng hiểu và thích nghi hay không, hàm có ngắn gọn và rõ ràng hay không
- Correctness: trạng thái sai có bị mô hình hóa hay không, test, type,
assert v.v. có đủ hay không, thậm chí có áp dụng kiểm chứng hình thức hay không
- Flexibility: hệ thống có dễ mở rộng hay không, thay đổi có thể áp dụng đơn giản hay không
- Portability: có phụ thuộc vào một môi trường cụ thể hay không, việc thay đổi môi trường triển khai có đơn giản hay không
- Scalability: khi lưu lượng tăng gấp 10, 100 lần, hệ thống có thể mở rộng hoặc auto-scaling hay không, nút thắt cổ chai nằm ở đâu
- Development speed: việc mở rộng hệ thống nhanh đến mức nào, đa số kỹ sư có thể tham gia làm việc hay không
- Ngoài ra còn có nhiều giá trị khác như elegance, modern-ness, tận dụng mã nguồn mở, chi phí bảo trì, v.v.
- Không phải mọi kỹ sư đều quan tâm tới từng giá trị ở cùng một mức độ
- Tùy theo bản thân đánh giá cao giá trị nào nhất mà ngôn ngữ, framework, pattern thiết kế được sử dụng sẽ khác nhau
Đặc điểm của gu kém
- Gu kém xuất hiện khi những giá trị mà bản thân ưa thích không phù hợp với dự án hiện tại
- Vấn đề là sự thiếu linh hoạt khi nhất quán ép ưu điểm của một công nghệ hay phương pháp luận cụ thể vào chính dự án của mình
- Những lập luận lúc nào cũng chỉ nêu "best practice" thường cho thấy sự thiếu vắng phán đoán theo tình huống
- Kỹ sư thiếu linh hoạt có thể rất hợp với một số dự án nhất định, nhưng khi môi trường hoặc công việc thay đổi thì có thể gây ra vấn đề nghiêm trọng
Đặc tính của gu tốt
- Gu tốt là khả năng chọn đúng các giá trị kỹ nghệ theo từng tình huống vấn đề
- Khác với năng lực kỹ thuật đơn thuần, nó chỉ thực sự được kiểm chứng trong ngữ cảnh dự án thực tế phức tạp
- Nếu một dự án áp dụng các quyết định thiết kế mà bản thân đồng ý và tiến triển tốt, ta có thể phần nào đo lường mức độ phù hợp của gu đó
- Trải nghiệm với nhiều dự án khác nhau, cùng thái độ cởi mở với các giá trị mới ở những thời điểm nhất định, là yếu tố học hỏi quan trọng
- Duy trì tính linh hoạt và tránh định kiến cố định với một công nghệ hay phương pháp cụ thể sẽ giúp hình thành gu tốt
Lời kết
- Gu tốt quan trọng không kém năng lực, và có thể được phát triển trong quá trình trưởng thành thông qua sự đa dạng, tính linh hoạt và tự phản tỉnh
- Một số người thậm chí còn thể hiện gu xuất sắc vượt xa mức kinh nghiệm của họ (như thần đồng trong lập trình và các lĩnh vực khác)
Thảo luận thêm
- Trong phần bình luận trên Hacker News cũng có những ý kiến hoài nghi về chính sự tồn tại của "gu"
- Một số người cho rằng mọi vấn đề chỉ có một lời giải đúng duy nhất, nhưng tác giả phản biện rằng trong thực tế có thể có nhiều lời giải, và cuối cùng lựa chọn sẽ bị chi phối bởi giá trị cá nhân và ngữ cảnh
- Một ý kiến khác cho rằng bối cảnh khách hàng và kinh doanh cũng là một phần của gu
7 bình luận
Có vẻ không chỉ đơn thuần là thứ có thể gạt đi là gu kém, mà đúng hơn là một khuynh hướng xấu có thể gây hại cho cả đội ngũ và dự án.
Ý kiến trên Hacker News
Tôi từng thấy các kỹ sư còn non thường có xu hướng quá chấp vào gu của bản thân, và sự non nớt đó đôi khi cả kỹ sư nhiều kinh nghiệm cũng mắc phải. Hồi trước khi giúp bạn bè làm bài tập lập trình trên máy tính, tôi thường có thôi thúc muốn viết lại toàn bộ chỉ vì tôi không thích đoạn code đó. Nhưng rồi tôi nhận ra làm vậy sẽ tốn quá nhiều thời gian và khiến bạn tôi không hiểu nổi kết quả cuối cùng. Vì thế tôi chọn cách chỉ chỉnh sửa vừa phải trên hướng tiếp cận của họ, và họ hài lòng hơn nhiều. Nhờ những trải nghiệm như vậy, tôi hiểu thêm các góc nhìn khác nhau và code của chính mình cũng tiến bộ hơn. Tôi thậm chí còn nghĩ mình mới là người phải cảm ơn bạn bè. Đến giờ tôi vẫn khó bỏ định kiến, nhưng tôi cố gắng hết sức để nghiêm túc hiểu quan điểm của người khác, và đôi khi chấp nhận rằng cách đó còn tốt hơn. Các nguyên tắc thực ra khá chủ quan, nên lúc nào cũng chỉ dựa vào nguyên tắc thường đồng nghĩa với việc né tránh suy nghĩ nghiêm túc về tình huống và chọn cách tiếp cận lười biếng
Ngay cả khi một kỹ sư junior đang làm gì đó theo cách kém hiệu quả, tôi tuyệt đối không nói rằng họ đang dùng cách ít tối ưu hơn. Thay vào đó, tôi luôn hỏi tại sao họ lại làm như vậy. Sau mỗi cuộc trò chuyện, một trong hai chúng tôi đều học được điều gì đó. Hoặc tôi biết thêm một cách làm mới hay lý do của họ, hoặc họ hiểu vì sao về lâu dài cách đó sẽ không hiệu quả. Dù là bên nào, những cuộc trao đổi như vậy chưa bao giờ kết thúc theo hướng đối đầu
Tôi nghĩ “gu tốt” hình thành từ việc trải nghiệm những API tuyệt vời và những đoạn code tốt. Nhìn code tốt là nhận ra ngay, và theo thời gian bản thân cũng nên viết được như thế. Nhưng khi mới bước chân vào lĩnh vực này thì rất khó có gu lập trình tốt, và có kinh nghiệm cũng không có nghĩa là tự động có gu, nên luôn cần nỗ lực tìm kiếm, nhận ra và học theo gu tốt
Cách để thoát khỏi định kiến, thiên kiến và tư duy cứng nhắc là học hỏi và tích lũy nhiều trải nghiệm đa dạng ngoài góc nhìn sẵn có của mỗi người. Chỉ khi chủ động cố gắng hiểu thế giới từ góc nhìn của người khác, ta mới trưởng thành hơn cả với tư cách con người lẫn người làm nghề và mở rộng được tầm nhìn. Với những kỹ sư như tôi, người hứng thú với nhiều lĩnh vực khác nhau, chỉ cần biết rằng tồn tại cách giải hay góc nhìn khác thôi cũng đủ làm thay đổi cách giải quyết vấn đề, giúp tìm ra lời giải tốt hơn so với phản xạ ban đầu
Đó là lý do nên thử nghiệm với nhiều ngôn ngữ lập trình khác nhau. Khi liên tục thử những ngôn ngữ mới thách thức góc nhìn hiện có của mình, sẽ luôn có những khoảnh khắc “à ha” xuất hiện. Ban đầu chúng có thể trông kỳ quặc hoặc sai sai, nhưng cần chấp nhận chúng như vốn có cho đến khi hiểu hoàn toàn lý do và cách thức đằng sau
Ý kiến hay. Đây cũng là cách suy nghĩ tôi áp dụng với những người mình trực tiếp tuyển hoặc cùng làm việc. Nếu mục tiêu hay kết quả đạt được thì không nhất thiết phải khớp với quy trình hay từng chi tiết của tôi. Tôi chấp nhận rằng có nhiều cách khác nhau
Tôi nghĩ “gu tốt” trong thời trang không nằm ở từng món đồ riêng lẻ, mà ở khả năng kết hợp những món tự thân có vẻ chẳng mang nhiều ý nghĩa thành một tổng thể mạnh mẽ và hài hòa. Tôi đã hy vọng bài này sẽ đi theo hướng đó. Tôi muốn đào sâu hơn vào việc điều gì trong quyết định của kỹ sư phần mềm thực sự thuộc về gu, chứ không chỉ là các trade-off kỹ thuật đơn thuần. Nhân tiện, bản thân bài viết này lại tạo cảm giác như một ví dụ về gu chưa tốt. Xét về nội dung thì từng phần đều được viết ổn, nhưng tổng thể không tạo ra được một “diện mạo” chung nên mang cảm giác rời rạc. Đây không phải lời công kích tác giả; tôi nghĩ chủ đề rất hay nên càng muốn góp ý để bài tốt hơn
Tôi không đồng ý với ý kiến cho rằng từng món đồ tự nó không có ý nghĩa. Quần áo mang ý nghĩa văn hóa, lịch sử và biểu tượng ngay cả trước khi được phối với nhau. Thời trang không chỉ là chuyện phối hợp đơn thuần. Ngoài ra trong thời trang cũng có nhiều trade-off khác nhau như sản xuất, mặc, phối đồ, v.v.
Điều bạn đang muốn hỏi — “chúng ta nhận ra vẻ đẹp và sự thanh nhã bằng cách nào” — đã là chủ đề của các triết gia từ thời cổ đại, quá rộng để kết luận trong một bài viết đơn lẻ. Christopher Alexander trong lĩnh vực kiến trúc đã đào sâu vấn đề này, và tư tưởng của ông cũng ảnh hưởng mạnh đến kiến trúc phần mềm. Alexander cho rằng tồn tại vẻ đẹp khách quan. Có thể tham khảo bài keynote tại OOPSLA của ông hoặc luận án tiến sĩ của Roy Fielding. “Giá trị” được nhắc đến trong bài này trong luận án của Fielding được hệ thống hóa hơn dưới tên “thuộc tính kiến trúc”
Thú vị là tôi lại thấy bài này là một bài viết hiếm hoi rất xuất sắc, xử lý chủ đề sâu và có hệ thống, kiểu rất khó tìm thấy
Tôi muốn hỏi khoảnh khắc nào mà ở một kết hợp nào đó, “gu” của kỹ sư thực sự được phân định, và đâu là “lãnh địa của gu” tách biệt với trade-off kỹ thuật đơn thuần. Theo tôi, rất nhiều quyết định rơi vào nhóm “đó là trade-off kỹ thuật nhưng không thể chứng minh dứt khoát, hoặc khác biệt nhỏ đến mức thực tế chẳng quan trọng”. Tức là khi khó phân định thì cứ để nó vào phạm trù gu
Phần lớn lập trình viên nhìn chung thiếu gu thời trang, nên cũng không thật sự hiểu rõ gu tốt nói chung là gì. Và đa số thứ trong thế giới công nghệ đối với người ngoài ngành đều không hề ngầu hay đẹp chút nào. Ngôn ngữ lập trình không ngầu. Trong thế giới dev, điểm xuất phát thậm chí là “không ngầu”, rồi từ đó còn đi xuống nữa. Ví dụ, Rust, C++ các kiểu thuộc nhóm “không ngầu”, còn những ngôn ngữ hàm ít người biết hay Bash, Linux thì thuộc hạng “cực kỳ không ngầu”
Gu tốt là viết được thứ code đơn giản mà mạnh mẽ đến mức ai cũng có cảm giác mình cũng có thể viết ra nó
Chia sẻ thêm một ví dụ khác. Khi tháo lắp rồi ráp lại chiếc Dodge Challenger đời 72, tôi luôn ngạc nhiên vì chiếc xe này được thiết kế đơn giản, trực diện, rẻ mà tốt một cách đáng kinh ngạc. Ví dụ, cụm đồng hồ cần 5 volt riêng dù điện áp toàn xe nằm trong khoảng 10~18V, nên người ta dùng một kiểu buzzer (tận dụng nam châm điện) để ngắt mạch khi quá 5 volt và đóng lại khi thấp hơn, bật/tắt cực nhanh để tạo trung bình 5 volt. Phần lớn mọi người thay nó bằng bộ điều áp điện tử, nhưng rồi bảng đồng hồ lại không hoạt động đúng. Thực tế là vì cụm đồng hồ mang tính cơ khí, nên nếu không có nhiễu nhỏ của mức 5 volt đó thì kim thường bị khựng; chính mức 5 volt “thô” này lại giúp tránh hiện tượng đó. Nếu thay bằng điện tử thì phải cố tình thêm “nhiễu” vào. Tôi rất thán phục việc một cơ cấu cơ khí đơn giản như vậy lại vượt trội đến thế cả về hiệu quả lẫn độ đơn giản
Giá trị thực sự của loại code đơn giản này, dù giúp tiết kiệm công bảo trì hay thời gian cho người làm việc, thường không được ghi nhận đúng mức. Code thực hành nguyên tắc KISS (Keep It Simple, Stupid) lại hay bị xem nhẹ vì trông như chẳng có giá trị gì. Bởi vậy mới tồn tại những team/tổ chức mà công việc thực chất chỉ là quản lý sự phức tạp không cần thiết
Đôi khi kỹ sư làm được điều phi thường thì tốt, nhưng điều thực sự quan trọng là kiểu kỹ sư thường xuyên tìm ra được lời giải bình thường, đơn giản, dù ban đầu có vẻ khó khăn
Xem múa ba lê thì người ta chỉ thốt lên “trông thật dễ!”, nhưng thực tế họ đã luyện tập hàng chục nghìn lần để có thể làm nó dễ như vậy
Tôi luôn kính trọng nhất những người có thể tóm gọn thứ phức tạp thành thứ thật đơn giản. Rõ ràng, sáng sủa như ví dụ trong K&R C, chỉ mong phần chú thích được viết kỹ hơn một chút
Câu hỏi “liệu có thể hiểu code trong nháy mắt và onboarding kỹ sư mới có dễ không” thực ra không hề dễ như tưởng tượng. “Mới” ở đây là người có 0 năm, 10 năm hay 30 năm kinh nghiệm? “Tính dễ đọc” với ai đó có vẻ là một khái niệm rõ ràng, nhưng thực tế nó trải dài trên phổ từ 0 đến vô hạn. Phương trình Maxwell với người này có thể rất rõ ràng nhưng với người khác lại hoàn toàn mù mờ. Vì thế tôi luôn băn khoăn câu “code nên dễ đọc” rốt cuộc đang nhắm đến ai
Code dễ đọc là code quan tâm đến người đọc và giảm tối đa gánh nặng nhận thức cho họ. Đó cũng là mục tiêu của phân lớp trừu tượng và các design pattern. Tất nhiên nó mang tính chủ quan vì còn tùy vào trình độ chuyên môn của độc giả và mức độ quen thuộc với codebase. Nhưng bảo rằng vì chủ quan nên phủ nhận luôn khái niệm tính dễ đọc thì hơi quá. Đâu thể nói Joyce với 'Ulysses' và Seuss với 'The Cat in the Hat' đều dễ đọc như nhau được
Tôi không đồng ý với lập luận “tính dễ đọc không phải là một khái niệm”. Code không đọc được là code mà không ai đọc được, kể cả chính tác giả của nó (hoặc AI). Code chỉ có tác giả đọc được thì cũng không phải code dễ đọc
Các phương trình Maxwell ở thời của Maxwell đúng là rất khó, nhưng dạng mà ta biết ngày nay là kết quả sau khi Heaviside và những người khác gọt giũa lại để tăng tính dễ đọc
Tôi cho rằng “tính dễ đọc cục bộ” của một phần code không có nhiều ý nghĩa. Nếu một pattern được áp dụng nhất quán trên toàn bộ codebase, thì dù pattern đó có hơi phức tạp, tổng thể code vẫn có thể đủ dễ đọc. Sự phức tạp tạm thời là chấp nhận được nếu nó không ảnh hưởng đến chất lượng chung của toàn bộ mã nguồn
Tính dễ đọc phần lớn nhằm giảm ‘độ phức tạp ngẫu nhiên’ (accidental complexity). Dù là ký hiệu kiểu kịch bản điện ảnh hay thuật toán phức tạp, nếu ký pháp tệ thì bản thân việc hiểu nó cũng trở nên khó khăn. Cuối cùng, với câu hỏi ‘code phải dễ đọc với ai’, tôi nghĩ nó nên dễ đọc với một kỹ sư hiểu rõ lĩnh vực đó, quen với vấn đề nhưng chưa từng xem qua chính đoạn code ấy. Điều này giống với bài báo khoa học: nó phải dễ đọc với nhóm các nhà nghiên cứu trong lĩnh vực liên quan. Tóm tắt No Silver Bullet
Tôi nghĩ phép ví “một kỹ sư gu kém giống như chiếc la bàn hỏng, cuối cùng sẽ luôn chỉ sai hướng” mô tả đúng bản chất. Kiểu người ‘hỏng theo cách có thể dự đoán’ này còn có thể lọc ra qua phỏng vấn. Nguy hiểm hơn là kiểu ‘la bàn hỏng một phần’. Bề ngoài có vẻ chỉ lệch chút ít, nhưng thực ra lúc nào cũng sai đúng 127 độ
Những bài như thế này thường trộn lẫn hai vấn đề. Thứ nhất, có những quyết định tệ một cách khách quan, bất kể gu hay nguyên tắc nào, ví dụ tìm kiếm O(n) trong list thay vì O(1) bằng dictionary. Tồn tại những thứ mang tính kỹ thuật và có hơn kém rõ ràng. Thứ hai, mọi thứ còn lại đều là trade-off. Dùng map-reduce hay vòng lặp thường, chỉ cần cân nhắc bối cảnh hiệu năng, tính dễ đọc, khả năng tương thích, v.v. Miễn có lý do thì dù khác suy nghĩ của tôi cũng không sao. Vấn đề là khi lựa chọn đó sai, hoặc thậm chí không hề cân nhắc trade-off. Khi đó nó thuộc phạm trù bảo trì, và tùy hiệu năng hay tần suất mà đôi khi cũng chưa chắc cần đụng vào. Chỉ cần “lý do (why)” cho quyết định đó rõ ràng là tôi chấp nhận. Không chắc những thứ như vậy có thật sự gọi là “gu” được không
Vấn đề của bài viết là nó xử lý quá vô ngữ cảnh chuyện “mỗi người coi trọng các giá trị khác nhau”. Trên thực tế, kỹ sư phải cảm nhận được khá rõ giá trị nào là quan trọng nhất của bài toán (= hard constraint). Phần tự do còn lại sau khi đã trừ hard constraint mới là thứ có thể xem là “gu”. Nếu ví với nghệ sĩ, đó là phần ngoài những vật liệu và quy cách đã được chỉ định, nơi vẫn còn lại các ràng buộc hay tự do riêng của họ. Gu tốt của kỹ sư phần mềm, theo tôi, gần với việc theo đuổi sự tối giản về mặt thẩm mỹ và mức tự kiềm chế tối đa. Trường hợp tôi cho là thật sự “gu tệ” là khi ai đó phá vỡ nguyên tắc mà không có bất kỳ lý do nào. Nói cách khác, rất nhiều lần người ta nhầm “sự đơn giản” với “sự quen thuộc”
Mục “giá trị” trong bài có liên hệ với các thuộc tính của kiến trúc phần mềm trong luận án tiến sĩ của Roy Fielding. Luận án của Fielding nổi tiếng chủ yếu vì REST, nhưng thực ra là một bàn luận rộng và rất vững về kiến trúc phần mềm. Nó giúp suy nghĩ trong bối cảnh nhiều “thuộc tính kiến trúc” khác nhau như khả năng mở rộng, tính dễ đọc, khả năng bảo trì, v.v., và cá nhân tôi còn muốn nhấn mạnh tầm quan trọng của việc hiểu ‘các ràng buộc kiến trúc’ ngoài những thuộc tính đó
Kỹ thuật đúng nghĩa (Principled engineering) đương nhiên phải là điều cơ bản. Trên nền đó, gu có thể tốt hoặc xấu. Nhưng chiều ngược lại thì không đúng. Nếu bản thân engineering đã tệ thì gu không còn ý nghĩa. Gu xấu có thể làm giảm hiệu quả của engineering, nhưng không khiến engineering tự thân trở nên bất khả thi. Engineering về cơ bản đóng vai trò nâng đỡ cho gu. Ví dụ, dù một thứ có được engineering hoàn hảo đến đâu, nếu đó là thứ không ai cần hay không ai muốn thì cũng vô nghĩa
Gu xấu cuối cùng sẽ dẫn ta đến tình huống bất định X mà ta vốn muốn tránh. Theo tôi, gu tốt rốt cuộc là việc chuẩn bị sẵn nền tảng vững chắc và các hàng rào an toàn trong codebase để đối phó với những bất định của tương lai. Có như vậy mới tránh được rủi ro
Thật sự rất hay
Bài gốc hay, nhưng nội dung bình luận cũng thực sự rất hay.
Nhắc đến "gu", tôi lại nhớ đến video TED của Torvalds:
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux
Từ phút 14:20, nói về gu tốt thể hiện qua cách triển khai mã xóa entry trong linked list
Ngay cả những điều được nhắc tới trong ý kiến trên Hacker News như "các quyết định tệ một cách khách quan (ví dụ: tìm kiếm O(n) trong list so với tìm kiếm O(1) bằng dictionary)" đôi khi cũng cần được quyết định khác đi tùy theo ngữ cảnh.
Nếu chỉ tra cứu đúng một lần, thì chi phí tạo một bảng băm có thể còn lớn hơn việc thực hiện tìm kiếm O(n) trong list.
Bình luận hay đấy.