Pragmatic Phisolophy

Book: The Pragmatic Programmer Your Journey to Mastery, 20th Anniversary Edition by Andrew Hunt David Hurst Thomas (z-lib.org).pdf

Chắc hẳn khi bạn đọc bài viết này, bạn cũng là một Software Engineer

• Luôn học hỏi
• Chịu trách nhiệm, tìm kiếm giải pháp thay vì đổ lỗi
• Software Entropy: luôn cố gắng giữ code sạch, nếu có vấn đề trong code mà không sửa thì lâu dần, mọi người đều quen, và số lượng vấn đề tăng lên. Tương tự với thói quen, được đà làm tới (có lẽ vậy)
• Nghĩ rộng ra, nhìn bức tranh toàn cảnh, đừng để bị ếch ngồi đáy giếng. Một vấn đề có rất nhiều cách giải quyết, nếu mình chỉ nhìn từ đáy cái cây, thì nó khiến mình chỉ thấy được một nhánh của vấn đề, đi ngược lên vấn đề sẽ thấy được nhiều nhánh hơn.
  • Hiểu được vấn đề: nó là cái gì? nó gây hại gì? nguyên nhân từ đâu ra? có nguyên nhân nào tiềm ẩn mà mình chưa thấy không? nó có kết nối với thành phần khác không?
  • Nếu không hiểu được vấn đề, và cái tiềm ấn của nó, thì khi đó, mình có thể giải quyết được vấn đề, nhưng lại tạo ra thêm một loại các vấn đề khác.
  • Ví dụ: Dưới đây, ta có một ống dẫn nước chẳng hạn. Ở giữa có lưới để filter các cặn. Một ngày đẹp trời, xuất hiện cặn bự và nó làm nghẽn filter, làm nước không chảy qua được (ống dẫn không sử dụng được - theo code là bị error). Mình cần làm gì để fix nó?
    • Dễ ẹc, lấy cục đó ra là xong. --> hết cục đó, nếu lại xuất hiện thêm nhiều cục tương tự nữa thì sao? Lại tiếp tục lấy ra??
    • Vậy thì vẫn đơn giản, làm cái filter bự ra, là lọt hết xuống thôi. --> wow, needless to say, nếu để lọt cặn xuống ở dưới bị nghẹt thì sao?
  • Việc mình nên làm là tìm nguyên nhân tại sao lại sinh ra bad data, và ngăn ngừa nó. Tìm cội nguồn gốc rễ của vấn đề. Tránh lầm tưởng việc "tắt" báo lỗi, với việc "fix" lỗi. Như ở cách làm lỗ filter to ra, sẽ giúp nó không bị chặn ở filter đó nữa, nhưng vấn đề vẫn còn đó, nó chỉ chuyển từ chỗ này sang chỗ khác. Nếu nó báo lỗi ở layer dưới là vẫn còn rất may. Nó mà im im và một thời gian sau mới báo lỗi thì nguy nữa.
• Thế nào là đủ: khi nắm rõ yêu cầu, nắm rõ vấn đề, scope của vấn đề tới đầu. Từ đó mình sẽ giới hạn được giải pháp của mình. Giải pháp đó đã đủ đáp ứng yêu cầu hay chưa, còn cần gì nữa, bao nhiêu phần trăm. Điều này bắt buộc phải hiểu được yêu cầu, hiểu được vấn đề.
  • Người dùng sẽ giúp ích rất nhiều cho việc thế nào là đủ? dev một component, dev một tính năng, dev một API, thì người dùng những phần đó sẽ feedback lại đã đủ xài hay chưa?
  • Mình không thể làm hoàn hảo một ứng dụng, một thuật toán, do đó, mình cần giới hạn lại vấn đề. Ví dụ như một ô nhập description, user cũng không mong nó phải có đầy đủ tính năng như word được.
  • Tóm lại cuối cùng vẫn là phải hiểu được vấn đề, hiểu được nhu cầu của người dùng. Người ta có cần tính năng đó hay không, người ta có sử dụng nó hay không. Mình dev ra tính năng đó, mà người ta không xài tới thì làm để làm gì??? Mình cứ gồng gánh giải quyết trường hợp đặc biệt của vấn đề (và nó rất ít khi xảy ra), cố gắng làm cho hàm hoàn hảo, giải quyết hết các trường hợp để làm gì, trong khi những trường hợp người dùng hay gặp, lúc xài thì bị lỗi này, lỗi kia. --> Giải pháp có thể là cố gắng hoàn tất các trường hợp người dùng hay gặp trước, rồi nếu chưa kịp thì cho user một thông báo, đưa ra giải pháp thay thế cho user. Rồi mình xử lý TH đặc biệt sau, như vậy thì sẽ kịp thời gian giao hàng, và user cũng có cái để sử dụng, để feedback. Đừng có không kịp rồi dời lịch, không có tính năng nào cho user sử dụng.
  • "Know When To Stop": biết đủ để dừng.
• Luôn đặt câu hỏi tại sao: cái này cũng là để mình hiểu rõ vấn đề, phản biện lại, không phải cái gì mình nghe/đọc cũng đúng. Luôn cố gắng tìm hiểu conflict trong lập luận, trong vấn đề. Tại sao mình phải ngồi viết cái này? tại sao mình ngồi nghe cái này? Tại sao lại phải luôn đặt câu hỏi tại sao? Tại sao?
• Thảo luận, giao tiếp: mình làm việc theo team, không phải tự thân một mình. Nhiều người đóng góp vào một dự án, thì lúc đó không phải ai cũng có cùng suy nghĩ, do đó một tính năng này, đoạn code này có thể nhập nhằng/conflict với người khác. Hoặc tính năng này có người đã làm rồi, mình gặp vấn đề tương tự, nếu không hỏi, không thảo luận, thì làm sao để biết???
  • Có phải đây là lí do mình có buổi peer review hay không?
  • Ngoài ra, khuyến khích mọi người khi gặp vấn đề gì mà bí, chưa giải quyết được, hoặc mình gặp vấn đề đó, suy nghĩ một hồi ra được giải pháp mà nó hơi phức tạp, cần phải dev trong 1 ngày, đổi khá nhiều code, thì nên thảo luận với người khác. Đôi khi mình chỉ cần giải thích lại vấn đề cho người khác hiểu là đã tự giúp mình tìm ra giải pháp? --> Tại sao? giúp mình chỗ nào? Ans: Nó giúp mình nhìn lại vấn đề từ đầu, nhìn lại bản chất của vấn đề để giải thích cho người khác, từ đó giúp mình quay lại, có cái nhìn khái quát hơn (nhánh cây cao hơn) giúp mình ngộ ra là có giải pháp khác tốt hơn.
  • Không nhất thiết phải thảo luận với người có nhiều kinh nghiệm về vấn đề đó, mà có thể là người không biết gì về nó, hoàn toàn mới, như ở trên, nó sẽ giúp mình phải khát quát và giải thích vấn đề ở góc nhìn khác, góc nhìn của người không trong nghề, mình sẽ lại ngộ ra điều mới mẻ, giải pháp mà mình chưa bao giờ nghĩ ra.
• Có thể thấy các ý trên nó đều liên quan tới nhau. Nếu mình không có đủ kiến thức, mình chưa gặp vấn đề đó bao giờ thì làm sao mình tìm ra được giải pháp, không biết keyword thì sao tìm? Do đó cần luôn học hỏi. Mà nếu không biết luôn hoặc chưa kịp học thì làm sao? thảo luận với người khác. Luôn luôn cần phải hiểu vấn đề. Điều này thì chắc ai cũng biết, nhưng thường bị rơi vào false assumption: vấn đề này dễ ẹc, nhìn cái là biết rồi thì tìm hiểu làm gì cho mệt. --> Đừng để bị đánh lừa bởi những thứ thấy được (visible), những thứ tiềm ẩn làm sao thấy được nếu không bới lên. Ở trong chăn mới biết chăn có rận.