Nói với quản lí rằng không có đủ thời gian để hoàn thành một công việc là một trong những kĩ năng tôi muốn có nhất sau gần một năm đi làm. Hoặc bạn phải lựa chọn giữa trễ hạn và sống trong lo lắng vì chất lượng của những thứ mình tạo ra.
Trong ngành này dường như làm kịp thời hạn là một cái gì đó xa xỉ. Tất nhiên mọi thứ cũng có giới hạn của nó, quản lí thì có quản lí ở cao hơn, quản lí ở cao hơn thì có khách hàng, khách hàng thì có thị trường, v.v. Cho nên không phải cứ cái gì cũng nói không kịp là được.
Công bằng mà nói, không cứ gì phát triển phần mềm, mà nói chung bạn không thể có đủ thời gian để làm tất cả mọi việc, nhưng bạn có thể có thời gian để làm những việc quan trọng nhất. Vì vậy làm không kịp cũng là một biểu hiện của tính yếu kém trong việc ước lượng thời gian và đánh giá kế hoạch.
Nói như thế có nghĩa là việc nói không với người quản lí không phải chỉ đơn giản là thu hết can đảm lại mà nói. Chính xác hơn can đảm không có vai trò gì ở đây cả. Bạn phải tính toán được và chấp nhận rằng bạn không có đủ thời gian, phải thấy được việc gì cần làm với chất lượng ở mức độ hợp lí, và phải chọn lấy những giải pháp thỏa hiệp nhất. Càng nhiều thông tin và lựa chọn thì người quản lí sẽ càng dễ tiếp thu ý kiến của bạn. Vậy là kĩ năng nói không phụ thuộc vào khả năng ước lượng, nắm vấn đề và kiến thức và các giải pháp.
Khi biết nói không rồi có lẽ tôi sẽ trở nên chuyên nghiệp hơn rất nhiều.
Annotation element “mappedby” được dùng trong JPA để chỉ đến field bên phía relationship owner.
Khi mới tìm hiểu về mappedby thì thuật ngữ “relationship owner” làm tôi cảm thấy khá mơ hồ. Lí do chủ yếu là sách giải thích rất qua loa thuật ngữ này. Tìm kiếm trên Internet có vẻ không đem lại kết quả gì đáng kể. Một cấp trên của tôi giải thích rằng việc lựa chọn relationship owner tùy thuộc vào ý nghĩa về mặt business của các entity càng khiến tôi rối loạn hơn.
Hóa ra, chỉ dẫn về “relationship owner” đã được phát biểu rất rõ ràng trong JSR 220:
Relationships may be bidirectional or unidirectional. A bidirectional relationship has both an owning side and an inverse side. A unidirectional relationship has only an owning side. The owning side of a relationship determines the updates to the relationship in the database, as described in section 3.2.3.
The following rules apply to bidirectional relationships:
- The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy element of the OneToOne, OneToMany, or ManyToMany annotation. The mappedBy element designates the property or field in the entity that is the owner of the relationship.
- The many side of one-to-many / many-to-one bidirectional relationships must be the owning side, hence the mappedBy element cannot be specified on the ManyToOne annotation.
- For one-to-one bidirectional relationships, the owning side corresponds to the side that contains the corresponding foreign key.
- For many-to-many bidirectional relationships either side may be the owning side.
Chứng tỏ trong một số trường hợp đọc specification lại tiết kiệm thời gian hơn tìm kiếm trên Internet 
.
Đây là hướng dẫn viết báo cáo luận văn do thầy Nguyễn Hứa Phùng phổ biến, nếu bạn học Khoa học máy tính ở BK thì nên tham khảo.
Theo như thầy NHP nói, thì chỉ có hai người xem báo cáo của bạn là người hướng dẫn và người phản biện, ba người trong hội đồng chấm sẽ chỉ lướt qua trong lúc bạn bảo vệ. Hơn nữa ngay cả người phản biện cũng sẽ không có nhiều thời gian để xem báo cáo, cho nên bạn phải cố gắng tập trung vào các điểm chính trong luận văn của mình. Đặc biệt cần tránh việc nhồi những thứ vô bổ vào báo cáo để cho nhiều chữ.
Báo cáo:
- Chương 1: Giới thiệu, nên chiếm 10-20 trang. Đây là phần đặc biệt quan trọng, vì người phản biện sẽ căn cứ vào phần này để xem có nên đọc kĩ phần sau không .
- Tầm quan trọng: Chứng tỏ vấn đề mà bạn tìm hiểu có vai trò quan trọng (không quan trọng thì làm làm gì).
- Độ phức tạp: Chứng tỏ vấn đề này khó (không khó sao đáng làm luận văn).
- Thesis statement: Phát biểu bạn sẽ làm cái gì. Công việc mà bạn hoàn tất phải khớp với phát biểu này.
- Đóng góp của luận văn cho vấn đề bạn tìm hiểu.
- Cấu trúc của báo cáo.
- Chương 2: Kiến thức nền tảng, khoảng 20 trang. Trình bày những công nghệ và công việc liên quan (của người khác). Lưu ý không sao chép, và viết thật ngắn gọn, vì đây là những thứ người khác làm. Người phản biện thường sẽ không xem kĩ phần này mà chỉ tham khảo nếu cần thiết cho việc đọc các chương sau.
- Chương 3 (và 4, nếu hai người làm hai việc độc lập): Thiết kế và hiện thực, khoảng 60 trang, nói chung phải đảm bảo chiếm tỉ lệ lớn trong báo cáo, vì đây là những thứ do mình làm.
- Thiết kế: Chú ý phân tích, so sánh các công nghệ, phương án. Phải làm sao thể hiện những thứ mình chọn là tối ưu nhất.
- Hiện thực: Chỉ trình bày qua cách tổ chức chương trình, triển khai, v.v. Đừng chép mã nguồn vào báo cáo, vì sẽ không ai đọc.
- Chương 4: Thử nghiệm.
- Chương 5: Kết luận.
- Phụ lục: Có thể trình bày kế hoạch thực hiện luận văn, bao gồm dự kiến và thực tế, những việc nảy sinh, v.v
Thuyết trình:
- Thời gian nói khoảng 15-20 phút, số slide khoảng 20-25.
- Một số slide quan trọng:
- Slide 0: Giới thiệu tên, tuổi, v.v
- Slide 1: Bố cục của bài thuyết trình.
- Slide 2-3: Chương 1 của báo cáo, nói khoảng 2 phút.
- Chú ý không nói chương 2 của báo cáo, hoặc chỉ nói trong một slide.
Không biết vào thời điểm này thì đưa mấy bài kiểu này nên có an toàn không nhỉ .
Tháng trước HM có chat với một người bạn và nhận được một câu trong đề thi giữa kì môn Lập trình hướng đối tượng như sau:
Trong C++ câu lệnh ClassB CB = new ClassB() tạo ra đối tượng trong vùng nhớ: a. heap b. stack c. static d. tất cả đều sai
Và HM nhận ra đã hai năm kể từ khi học xong môn này, nó vẫn chả thay đổi gì cả. Câu hỏi trên thì dính dáng gì đến OOP? Khi xưa thi môn này HM cũng gặp những câu hỏi khiến người ta có cảm giác đây là môn “Lập trình OOP, Java, và C++ cóp nhặt”.
Theo ý kiến của HM (và HM không phải là giáo viên), một môn Lập trình hướng đối tượng nếu được dạy, cần phải thể hiện được:
- OOP là một paradigm, các ngôn ngữ chỉ là implementation.
- Các khái niệm về encapsulation, inheritance, polymorphism, overriding, v.v
- Giới thiệu qua về các implementation khác nhau cho những khái niệm trên.
- Các nguyên lí khi thiết kế hướng đối tượng, và một dự án lớn áp dụng được nhiều nguyên lí này thì rất tuyệt. Tuyệt hơn nữa nếu nó sử dụng lại bài tập lớn của môn học trước dành cho sinh viên mới, vì nó sẽ tạo ra sự đối chiếu. Môn Lập trình hướng đối tượng khi HM học không dạy cái này, và cũng chỉ đưa ra các bài thực hành dạng copy-paste, chạy có thể được có thể không, và hoàn toàn không minh họa gì cho các nguyên lí OOP.
Thực sự cảm thấy rất tiếc.
