- Tiếp cận theo cách thủ công, hiểu được làm thế nào có thể làm việc

chung trong 1 dự án. Trong dự án có lỗi, yêu cầu của khách hàng. Giải
quyết vấn đề liên quan đến kỹ thuật
- Tái cấu trúc
- Ví dụ: vòng lặp mãi mãi (while(true) thay thế for (;;))
- Kiểm thử phần mềm
- Các loại đánh giá kỹ thuật

- Các loại đánh giá

+ Đi ngang qua
+ Đọc mã lệnh
 + Lặp trình cặp đôi: làm <-> kiểm tra
+ Thanh tra: quy định chặt chẽ

- Trong dự án, tham gia 1 cách tùy hứng, ngẫu nhiên. Người đi ngang
qua của dự án. Informal(không chỉnh chu, 1 cách tùy tiện)
- Đánh giá qua lại
- Review và phản hồi

- Chỉnh chu hơn, rõ ràng hơn. Áp dụng cho phần mã lệnh

- Những người đánh giá sẽ đọc mã và phản hồi lại công việc của tác giả
- Chỉnh chu nhất: review nhiều thứ khác nhau. Người ta sử dụng hình
thức chuyên nghiệp và chỉnh chu hơn.
- Vai trò cụ thể: author vs review
- Danh sách kiểm tra, báo cáo kiểm tra…có check list thường gọi là
inspection, inspector là reivew với hình thức inspection

- Nhiều tên: kiểm tra phần mềm, review mã lệnh, Fagan inspection(tưởng
nhớ tới kiểm định Fagan).
- “… một kỹ thuật đánh giá chuẩn trong đó yêu cầu phần mềm, thiết kế
hoặc viết code là được kiểm tra chi tiết bởi một người hoặc một nhóm
người khác hơn tác giả để phát hiện những lỗi, những vi phạm của tiêu
chuẩn phát triển và các vấn đề khác… ”
 Để phát hiện và xác định phần tử phần mềm khiếm khuyết sớm
 Sửa chữa sớm các khiếm khuyết có tác động trực tiếp về chất lượng
- ANSI / IEEE Std. 729-1983 Bảng chú giải thuật ngữ chuẩn của Kỹ
thuật phần mềm
- Các bước thực hiện:
+ Lập kế hoạch: đưa ra lịch trình làm việc. Chọn những người review.
Chọn những phương tiện & công cụ hỗ trợ review
+ Tổng quát: kiểm tra lại những thứ cần review. Tập thử nghiệm
phương tiện & công cụ hỗ trợ review
+ Chuẩn bị: đọc code và tìm lỗi. Inspecter tìm
+ Họp: họp và tranh luận để tìm ra lỗi mới
+ Làm lại: tìm ra lỗi và sửa lại
+ Follow-up: tránh lỗi đấy ra(ngăn ngừa lỗi)
- Kiểm tra:
-  Vai trò:
 Tác giả
 Người điều tiết
 Thanh tra (người đánh giá)
 Máy ghi âm
 Đầu đọc / Máy chấm công
 Khi:
 Trước cuộc họp thanh tra
 Trong cuộc họp thanh tra
 Sau cuộc họp kiểm tra
- Danh sách kiểm tra tập trung người đánh giá chú ý đến các lĩnh vực có
vấn đề trong quá khứ
- Inspections tập trung vào phát hiện khiếm khuyết, và không điều chỉnh
- Những người đánh giá chuẩn bị cho cuộc họp kiểm tra trước và đến với
danh sách các vấn đề mà họ đã khám phá ra
- Các vai trò riêng biệt được giao cho tất cả những người tham gia
- Người kiểm duyệt kiểm tra không phải là tác giả của sản phẩm làm việc
được kiểm tra(tức là người kiểm duyệt không thể là tác giả của sản
phẩm). Người kiểm duyệt(moderator) phải được train kỹ
- Người điều hành kiểm tra đã nhận được cụ thể đào tạo về kiểm duyệt
thanh tra
- Cuộc họp thanh tra chỉ được tổ chức nếu tất cả những người tham gia
đã chuẩn bị đầy đủ
- Dữ liệu được thu thập trong mỗi cuộc họp thanh tra(inspection) và được
đưa vào các cuộc kiểm tra trong tương lai
- Quản lý chung không tham gia kiểm tra các cuộc họp trừ khi hiện vật
được kiểm tra là một kế hoạch hoặc tài liệu quản lý khác
- Quy trình sẽ mang lại những lợi ích gì?
- Đối với Quy trình Kiểm tra:
 Đã loại bỏ các khiếm khuyết
 Đào tạo chéo nhóm
 Những người khác ...
-Tại sao Đánh giá Kỹ thuật?
 Mục tiêu phát triển phần mềm:
 Giảm thiểu các khiếm khuyết phần mềm Giá cả
 Đánh giá kỹ thuật loại bỏ các khiếm khuyết sớm trong Vòng đời và nó luôn
rẻ hơn khi tìm lỗi muộn
 Lưu ý rằng Đánh giá kỹ thuật giúp loại bỏ khiếm khuyết và ngăn ngừa các
khiếm khuyết trong tương lai

-Giá thành rất cao sau khi để lâu mới fix

-Lợi ích của Đánh giá Kỹ thuật
 Loại bỏ sớm các khiếm khuyết
 Các nhóm tìm ra lỗi mà không có cá nhân nào đánh giá sẽ có thể tìm thấy
 Các nhà phát triển và người đánh giá ít kinh nghiệm hơn học hỏi từ những
đồng nghiệp giàu kinh nghiệm hơn của họ
 Các cuộc họp tạo ra một lịch trình mà mọi người phải hướng tới
 Khuyến khích cá nhân để đóng góp và cải thiện
 Chia sẻ kiến thức quan trọng
-Một khiếm khuyết là gì?
 Khi người đánh giá hoặc đồng thuận của người đánh giá xác định rằng mã
phải được đã thay đổi trước khi nó được chấp nhận, nó là một "Khiếm
khuyết"
 Nếu thuật toán sai, đó là một khiếm khuyết
  Nếu mã đúng nhưng không thể hiểu được do tài liệu kém, đó là một khiếm
khuyết
 Nếu mã đúng nhưng có một cách tốt hơn để làm đi, đó là một khiếm khuyết
 Đối với các mục đích đánh giá:
 Một khiếm khuyết là một cải tiến đối với mã sẽ không xảy ra nếu không xem
xét
-Tại sao không phải đánh giá kỹ thuật Được sử dụng rộng rãi hơn?
 Không cần thiết với các ngôn ngữ hiện đại và kỹ thuật phát triển
 Các nhà phát triển hiện đại vẫn tạo ra những khiếm khuyết
 “Đã thử nó và nó không hoạt động”
 Đừng nhầm lẫn giữa ý tưởng tốt với người nghèo thực hiện
 Quá trình này thường không được thực hiện tốt hoặc được thay đổi mà
không hỗ trợ dữ liệu
 Các nhà phát triển không thích làm chúng
 Chúng có thể trở nên tẻ nhạt, nhưng chúng cũng có thể hãy vui vẻ
-Tại sao không phải đánh giá kỹ thuật Được sử dụng rộng rãi hơn?
 Các nhà phát triển của chúng tôi rất giỏi
 Ngay cả những nhà phát triển rất giỏi cũng tạo ra những khiếm khuyết
 Hầu hết các nhà phát triển muốn học hỏi từ những sai lầm
 Các nhà phát triển không tiếp thu phản hồi tốt
 Hầu hết các nhà phát triển muốn học hỏi từ những sai lầm
 Kiểm thử đơn vị cũng hiệu quả
 Kiểm tra đơn vị không nắm bắt được mọi thứ
 Kiểm tra đơn vị có thể cho cảm giác sai về chất lượng
Tóm lược
 Nếu được thực hiện đúng cách, đánh giá là một phương pháp cho:
 Giảm đáng kể số lượng lỗi được giao
 Giữ mã có thể bảo trì được
 Nhận nhân viên mới làm việc hiệu quả nhanh chóng và an toàn
 Các phương pháp và công cụ có thể được áp dụng sai, được coi là thất bại,
và sau đó bị loại bỏ như một trải nghiệm tồi tệ bởi người dùng không được
kích hoạt để thành công
 Các kỹ thuật chất lượng như đánh giá và kiểm tra là không loại trừ lẫn nhau
 Dữ liệu chi phí, lợi ích và danh mục phải được thu thập để xác minh và cải
thiện quy trình xem xét của bạn!
-Check list:
+Đặt tên có đúng chuẩn chưa?
+Giao diện có hợp lý không?
+Các đối tượng cùng loại có giống nhau không?
+Kết quả có gây chú ý?
Review
+Nên đặt text label1 thành: Kết quả. Nên đặt id cho label: số thứ nhất & số
thứ hai
+Giao diện hợp lý nhưng chưa đẹp, thêm text box gần Kết quả
+Nên ép kiểu cho textBox1 & textBox2:
int soThuNhat=Convert.Int32(textBox1.Text)
int soThuHai=Convert.Int32(textBox2.Text)
+Kết quả nên để trong text box
*Dùng code collaborator để hỗ trợ review meeting
*Link lấy bài: thực hành 2
https://drive.google.com/drive/u/1/folders/1zN0bPEyv9dEbuEPQe3ck-
bn2YN0FlaQy
*Viết đề tài:
Mini Game - Keo_Bua_Bao