我为我公司的 Java 后端职位空缺编写了一个测试,以下是包含任务的文档文本:
User ManagProject 标题:图书馆管理系统 该项目旨在创建一个图书馆管理系统,这是一个帮助图书馆工作人员以简单有效的方式管理图书、顾客(图书馆用户)和图书借阅的软件工具。
主要功能: ement:创建和管理图书管理员帐户。允许图书馆员登录。Book Management: Add new books with details like title, author, ISBN, and genre. Edit and update book info. Remove books from the library. Display a list of all library books. Patron Management: Add new patrons with their names, contact info, and membership status. Edit and update patron details. Remove patrons from the library. Show a list of all library patrons. Borrowing System: Enable library patrons to borrow books. Track due dates for borrowed books. Allow librarians to mark books as returned. Notify patrons if they have overdue books. Search and Filtering: Create a search feature for books and patrons based on criteria like title, author, and name. Add options to sort and filter lists of books and patrons. Reporting: Generate reports that display overdue books and transaction history. Provide statistics about the library's book collection and patron activity. Technical Details: User Interface: Design an easy-to-use web-based interface for librarians. Ensure it works well on different screen sizes. Security: Set up user login and access control for librarians. Safeguard sensitive information, like passwords and patron data. Database: Use a relational database (e.g., MySQL, PostgreSQL) to store book, patron, and transaction data. Create a suitable database structure and relationships. Performance: Optimize how the system fetches data from the database. Ensure the system can handle multiple users at once. Scalability: Design the system to grow smoothly as the library's needs expand. Technology Stack: Backend: Java (with Spring Boot) Frontend: HTML, CSS, JavaScript Database: Relational (e.g., MySQL, PostgreSQL) Security: Spring Security Database Access: Hibernate User Interface Templating: Thymeleaf or similar Project Deliverables: The project's source code. Documentation (README) explaining how to set up and run the application. Brief documentation describing the project's structure and design choices. Source code should be provided as a git repository. Evaluation Criteria: The project will be assessed based on: Functionality: Does the system meet all functional requirements? User Interface: Is the interface user-friendly and adaptable to different devices? Code Quality: Is the code well-organized, readable, and maintainable? Security: Is user authentication and data protection implemented correctly? Database Design: Does the database structure fit the project's needs? Documentation: Is there clear documentation for setting up and using the application? Error Handling: Does the application handle errors gracefully? Performance: How efficiently does the application perform its tasks?
通过测试后,他们说很明显“是我自己写的”(确实如此)并告诉我改正然后再试,但不幸的是他们没有告诉我任务到底出了什么问题。我自己找不到具体需要纠正的地方,如果您能告诉我,我会很高兴这是Github上该项目的链接。
立即声明:你可以发表很多评论,但被调查者和检查员的观点不会一致,这并不是事实。因此,建议从原始来源中找出他们不喜欢的内容以及应该纠正的内容。我可以代表我自己简单地说明我到底在哪里看到了问题以及可以改进的地方。
git中项目的解释文件的设计是通过带有markdown标记的readme.md文件,它不是用三行不太清晰的文字写的。
数据库是通过存储在单独的地方并在数据库上单独运行的SQL文件来设计的。除了该方案与应用程序相关之外,它的一部分还包括插入代码。在源代码中,甚至有两个重复的类DataInitializer.java和UserDataInitializer.java用于此目的。
数据库模式必须满足要求;出于未知原因或出于什么目的而做了某些事情;
系统中的角色位于单独的表中,用户也位于单独的表中。顺便说一句,这两个词都可以被数据库保留,因此它们通常写角色/用户并坚持以复数形式使用相同的名称。那么为什么 user.role 文本字段存在于这个模式中呢?
或者书籍及其发行,有一个描述发行的借阅表。那么为什么 books 表中存在 books.patron_id 呢?为什么是交易而不是贷款历史?贷款表本身已经包含所有必要的信息;您甚至不需要添加单独的历史记录(出于礼貌,您可以添加计划归还日期来跟踪实际归还和延迟)。
这是如果它是本质上的,但不是本质上的,你仍然可以把它穿上。例如,一本书可能有多个作者和多个流派。尽管数据库允许(COMMENT 选项),但模式中没有注释。状态和其他东西会经历魔法常量,这就是 transactions.transaction_type 的情况,如果它只是文本而不与任何东西绑定的话。
另一个 patreon 可以被认为是相同的用户。如果该服务希望允许用户自己在终端上搜索书籍,建议为他们提供单独的权限和登录访问权限。然后 patreon 表将作为冗余而自行消失。仅按权限分配,同时员工本身也可以是同一用户。
在这些情况下,图表可能如下所示。
想象一下自己是该计划的一名员工,并思考什么会方便,什么不会。例如,如果我去一个有书籍的部分,我想以一种方便的方式使用它们。
我首先看到的是,大多数书籍都无法查看,出于某种原因,我必须单独单击借书按钮,否则我根本无法在列表中找到它们。你可以用过滤器做同样的事情,而不是强迫一个人以不同的形式走来走去。
如果图书馆有几千本书,那么我会向下滚动到按钮,直到晚上:)为什么它们不在顶部,您是否尝试过向数据库添加五本书以上?超过五个用户?如果我需要交叉搜索,它没有实现。对于这一切,有 Pageable 和 CriteriaBuilder。有一些值得努力的事情。
没有统计信息,比如每个月借、还、迟还的书有多少本?嗯,有一点
adaptable to different devices:仔细检查应用程序在不同屏幕上的行为。一般来说,考虑方便性。
文件夹和文件结构没有什么太大问题。代码本身也被格式化为控制器/服务/存储库的正常分解。然后很难说检查员希望看到什么,因为有不同的做法和使用方法。这是您需要与检查员核实的地方。
人们只能推测普通 DTO 的主题,而不是实体,它们应该彼此分离。并且还检查可以填充在那里(注释@Max、@Min、@NotNull 等)。
Get/Post 不需要有不同的地址;它们可以在一个 @GetMapping("/book/create") + @PostMapping("/book/create") 上正常工作。