Lúc đầu định viết về product nhưng xong thế nào lại suy ngẫm nhiều hơn về software engineering, nên mình chia sẻ lại một số quan điểm của mình về software engineering và cụ thể hơn là như thế nào để phát triển bản thân khi bạn là một software engineer:
– Tiếng Anh là một công cụ, và cái công cụ này bạn phải nắm chắc trong tay. Dữ liệu tiếng Anh về lập trình hay kiến trúc, thuận toán… trong SE có thể khẳng định là nhiều hơn tiếng Việt rất rất rất nhiều lần, và độ cập nhật của những dữ liệu này cũng nhanh hơn dữ liệu tiếng Việt rất rất nhiều lần. Khi bạn không đọc hiểu tốt hoặc viết tốt (đơn giản là Google được vấn đề bằng tiếng Anh) thì bạn tự nhốt mình trong một phạm vi rất eo hẹp về kiến thức.
– Làm gì cũng phải hiểu bản chất gốc rễ của vấn đề. Khi bạn code Javascript nếu bạn chỉ biết dùng Jquery bạn sẽ gặp rất nhiều vấn đề sau này vì Jquery là một abstraction (sorry mình không biết dịch cái này ra TV như thế nào), và khi gặp phải khó khăn trong việc tối ưu hóa performance của JS bạn sẽ bị hạn chế trong việc tìm ra tại sao cái này render chậm, tại sao cái kia conflict với cái này. Bản chất gốc rễ ở đây mà mình nói đến là bạn nên tìm hiểu browser hoạt động ra sao và cách browser xử lý script theo trình tự như thế nào, và JS khi single threaded sẽ behave như thế nào.
– Nên tìm hiểu về functional programming và tính bất biến trong lập trình, cái này sẽ giúp bạn và code bạn viết ra dễ debug hơn, và dễ hiểu phần nào hơn cho người khác khi đọc code của bạn. Khi mỗi hàm bạn viết ra không bị “bẩn”, tức là mỗi hàm bạn viết ra khi nó nhận tham số vào thì bạn sure là kết quả của tham số hoặc một bộ tham số đó sẽ cho ra cái gì đó bạn hoàn toàn đoán trước được (tính predictable). Nếu hàm bạn viết ra nhận 3 tham số explicitly và bên trong hàm đó lại có sử dụng một tham số global sẽ thay đổi theo thời gian hay context thì khả năng bạn debug cái hàm này sẽ ăn hành nhiều.
– Viết test không phải là tất cả, nhưng bạn nên viết test. Khi bạn làm ở một startup nhỏ, cần move fast, việc testing có thể không quan trọng đến vậy nhưng ở scale lớn thì nó rất quan trọng vì bạn sẽ không phải mất thời gian và QC cũng không phải mất thời gian test lại cái code bạn viết ra. Nên viết code như thế nào để QC càng ít phải test càng tốt.
– Khi tổ chức lớn dần thì nên có convention trong việc viết code, nên có quy chuẩn, vì một cái code base cũng như một cái tiểu thuyết được viết bởi nhiều người. Khi có nhiều người cùng viết một câu truyện thì nó càng cần sự nhất quán và rành mạch, nếu mỗi người viết theo một kiểu cái câu chuyện sẽ không ăn nhập, cái flow bị gãy và người đọc/user là người ăn hành.
– Làm software engineer không phải là chỉ ngồi code, mà là nghĩ ra cách giải quyết vấn đề. Nếu vấn đề nó không cần phải code và exception sẽ không xảy ra thì càng tốt, một software engineering giỏi là sẽ không nhảy bổ vô vấn đề và viết code mà phải tìm ra vấn đề này thực sự gốc rễ phát sinh ở đâu, có thể nó là business process, có thể nó là UI design…, không nhất thiết nó phải là code. Hãy nghĩ mình là người solve vấn đề và khi nào không thể solve vấn đề bằng code thì mới code.
Bài chia sẽ bởi anh Hoang D Nguyen là Head of commercial Engineering – phụ trách quản lý toàn bộ quá trình xây dựng product mang lại trải nghiệm end to end cho consumer, trên tất cả các nền tảng web, app của Tiki.
Xem tuyển dụng software developer đãi ngộ tốt trên TopDev
Quote* từ anh Nguyễn Đông:
Functional programming là một loại design, việc lựa chọn FP, OOP,. là design decision mà bạn sẽ quyết định từ đầu dự án và nó sẽ phụ thuộc vào dự án của bạn là gì, skill của members,... Còn việc bạn có dirty code hay không lại phụ thuộc vào những khía cạnh khác. Tóm lại tiêu chí cần đạt được là: --- Viết ra phần mềm mà mọi người thích sử dụng; --- Code phải dễ bảo trì; --- Bạn làm việc tốt với mọi người trong team; --- It bug; --- Giải quyết vấn đề bằng cách đơn giản; Có nhiều tool và cách tiếp cận để đạt được những tiêu chí trên. Một trong đó là: --- Practice TDD mỗi ngày 30phut; --- Nắm những kiến thức cần thiết bất biến của software engineering: Là những kiến thức không bị lạc hậu nhanh theo thời gian như: principle knowledges, business knowlegde; --- Code review; .................................. Rất nhiều thứ khác. Nói chung phụ thuộc kinh nghiệm và khả năng tự reflect của mỗi người...
