CUỘC TRAO ĐỔI GIỮA LUVINA v SPRITE
I. Nội dung bài viết này bao gồm:
- Cảm nhận về bài phát biểu
- Kiến thức thu được sau khi nghe
- Bài học kinh nghiệm rút ra sau buổi trao đổi
III. Các thành viên tham gia:
1. Các keys person, ban lãnh đạo của Luvina
2. Ông Yamamoto(nguyên CTO của TOSHIBA)
3. Ông Irisawa (CEO của công ty Sprite)
4. Ông Tanaka (Designer của công ty Sprite)
II. Nội dung chi tiết
1. Cảm nhận về bài phát biểu
- Trình bày của Vũ thiếu khoa học và không rõ ràng. Nặng nề về mặt trình bày, nội dung truyền tải tới người nghe rất ít.
- Thiết kế của Vũ theo phương pháp luận.
- Trình bày của Công mạch lạc, rõ ràng. Tuy nhiên, những kinh nghiệm, suy nghĩ của Công vẫn chưa truyền tải tới mọi người mà chỉ là những góp ý được Irisawa chỉ ra cho Công (đó là các checkpoint khi review design)
- Thiết kế của Công không theo phương pháp luận.
- Mặc dù yêu cầu bài toán là giống nhau nhưng kết quả đầu ra của Vũ & Công khác nhau:
+ Đầu ra của Vũ có thể dùng luôn để lập trình được
+ Đầu ra của Công chưa dùng để lập trình được, mà là đầu vào của Thiết kế chi tiết.
- Các keys person của Luvina ngồi nghe rất thụ động, ít đặt câu hỏi (trong đó có cả Hùng)
- Các kiến thức đều đã được nghe, biết, làm nhưng qua buổi trao đổi này thì thấy mình hiểu biết còn sơ sài, không hiểu bản chất.
- Sau buổi trao đổi này có thể mọi người sẽ có thêm một cách nghĩ mới về nghề làm software.
2. Kiến thức thu được sau khi nghe
a. Qua phần trình bày của Vũ
- Biết thêm về tên 2 phương pháp thiết kế: STS và Common Function partioning method
- Những điều kiện của việc design:
+ Một tài liệu thiết kế tốt là gì?
+ Các điều kiện thiết kế là gì?
+ Làm như thế nào để xác định phương pháp thiết kế?
- Những kinh nghiệm thu được:
+ Tính phụ thuộc
+ Độ bền
+ Tính cơ bản
- Nhớ lại được mô hình: phân rã chức năng và nổi bọt (bubble)
- Các bước thiết kế của Vũ:
+ System design
+ Software component design
+ Input and Output desing
+ Physical data design
+ Reuse of part
- Thuật toán tìm kiếm nhị phân (binary)
b. Qua phần trình bày của Công
- Thiết kế cơ bản
- Cách review thiết kế
- Đưa ra các check points khi review
- Các câu hỏi khi thiết kế:
+ Điểm mạnh là gì?
+ Điểm yếu là gì?
+ Tại sao chọn phương pháp này? Có phương pháp nào khác không?
- Khi nhìn thấy bản design “đẹp” (là những khối vuông chằn chặn, không có rẽ nhánh) là chắc chắn có vấn đề và cần phải xem lại.
- Khi review thiết kế thấy có 2 đường cùng đi đến 1 chức năng thì phải đặt câu hỏi tại sao lại như vậy? Mục đích để tránh tình trạng: giải quyết một vấn đề có nhiều hướng khác nhau dẫn đến việc code sẽ khác nhau.
- Qua mỗi lần review cần phải tracking lại kết quả review để rút ra kinh nghiệm
- Biết sơ qua về thuật toán tìm kiếm B+
c. Những góp ý của ông Irisawa （入沢）và ông Tanaka（田中）
- Thiết kế của Vũ hướng chức năng
- Thiết kế của Công hướng data
- Thiết kế của Vũ là thiết kế ở mức chi tiết
- Thiết kế của Công là thiết kế ở mức cơ bản
- Cần phân biệt rõ các giai đoạn thiết kế: Thiết kế cơ bản → Thiết kế chi tiết
- Khi review cần chú ý các checkpoints: Điểm mạnh, điểm yếu, có phương pháp thay thế hay không.
- Khi thiết kế phải đưa ra được bảng quan hệ function(ngang) - data(dọc)
+ Tối ưu việc thiết kế để làm sao cho mỗi một function quan hệ với một data(càng ít càng tốt) và ngược lại mỗi data quan hệ với 1 function càng ít càng tốt.
+ Dùng bảng này để review thiết kế cũng được.
- Cần phải nắm rõ các giai đoạn làm phần mềm.
d. Những góp ý của ông Yamamoto（山本）
※ Ngồi trong quần chúng để quan sát và nắng nghe thật kỹ. Sau đó mới đưa ra phán đoán, kết luận.
※ Những điều cần nhận thức rõ và luôn luôn phải nhớ khi làm PM là:
- Việc làm phần mềm là khó khăn và trí tuệ
- Không được hiểu rằng yêu cầu của KH là 100% yêu cầu của việc làm phần mềm. Đó mới chỉ là 10% yêu cầu của việc làm phần mềm.
- Vậy 90% còn lại của việc làm PM ở đâu? Nó nằm trong đầu các kỹ sư làm PM(designer, developer, tester, …)
- 90% đó là cái gì? Đó là kiến thức về thiết kế, về công nghệ, … về những thứ liên quan đến việc phát triển PM mà người kỹ sư cần phải sẵn sàng để tham gia phát triển.
- Phần lớn các dự án PM bị fails nằmở 90% này.
- Và khi làm ODC thì 90% này càng khó khăn để hoàn thành.
- Về công nghệ: liên tục cập nhật công nghệ để tránh lạc hậu
- Khi gặp vấn đề phải tận dụng những component đã có. Chỉ viết lại khi chưa có ai giải quyết vần đề này.
- Những nhà phát triển cần phải mapping được yêu cầu KH với ngôn ngữ máy tính. Chuyển một đống chữ gọi là yêu cầu sang một thứ ngôn ngữ mà máy tính hiểu được chỉ có 0 và 1.
3. Bài học kinh nghiệm rút ra sau buổi trao đổi
※ Khi review cần đưa ra các checkpoints
※ Khi thiết kế phải nhìn từ 2 chiều: ngang(functions) - dọc(data)
※ Yêu cầu của khách hàng - cái này chỉ chiếm 10% của việc yêu cầu làm phần mềm - 90% còn lại là kiến thức mà người làm software phải sẵn có.
※ Để đảm bảo thông tin giữa các giai đoạn được truyền tải đúng, đủ thì yêu cầu: không chỉ hiểu giai đoạn của mình mà phải hiểu cả giai đoạn trước mình. Ví dụ khi làm Test phải hiểu được Code hoặc khi làm Code thì phải hiểu được design.
※ Phải mapping được yêu cầu KH với ngôn ngữ mà máy tính hiểu được. Để làm được nhà thông dịch thì phải hiểu cả 2.
