Reflections on a Small‑Scale Java Project: Architecture, Technology Selection, and Development Practices

Recently I completed a small‑to‑medium Java project, which gave me several insights and ideas.

Project background: The project was for the Langfang municipal government. It had been started by another company but was abandoned as a half‑finished product. When I took over, I received the source code, database (over 400 tables), and minimal notes, but no requirement or design documents. After discussions we decided to redevelop rather than continue, due to high cost of understanding the existing code.

Refactoring: Using the provided source and database, I managed to get the original system running. While testing the front‑end, I discovered severe browser compatibility issues: the pages rendered correctly only in IE7 and a few domestic browsers; they were unusable in other IE versions or mainstream browsers.

Technology selection:

Front‑end framework – Because of the compatibility problems, we needed a framework that worked across browsers. Considering the team’s skill set and user needs, we chose dwz . It offers good cross‑browser support (IE, Chrome, Firefox, and major Chinese browsers), is easy to learn, and the team was already familiar with it.

Core framework – The common Java stack options are Spring, Struts/SpringMVC, and Hibernate/MyBatis. Spring is a given; the choice between Struts vs. SpringMVC and Hibernate vs. MyBatis depends on team expertise and community support. We selected Struts and Hibernate because the developers were more comfortable with them, and their communities are larger.

In summary, the base framework is Spring + Struts + Hibernate .

Other tools – For the database we used MySQL (sufficient for a small project). Eclipse served as the IDE. Maven was preferred over Ant for build management. SVN was chosen for version control within the LAN because of its simplicity. The web container stack is Tomcat for production deployment and Jetty for development, the latter integrated as a Maven plugin for hot‑reload.

Basic architecture design: The system follows an Action‑Service‑Dao‑Entity layered structure. The overall diagram is shown below:

The diagram illustrates the core skeleton; utility classes are placed in a tool package. The design respects object‑oriented principles such as abstraction, encapsulation, inheritance, and polymorphism.

Action – An abstract BaseAction extends ActionSupport , encapsulating common features like pagination and result constants.

Service – An abstract BaseService implements generic CRUD operations. Specific services (e.g., UserService ) inherit it and add business‑specific methods such as login and logout, improving code reuse.

Dao – An abstract BaseDao provides generic data‑access methods, mirroring the responsibilities of BaseService at the persistence layer.

Entity – A BaseEntity can implement Serializable and hold common fields like id , reducing duplication across entity classes.

Development management: The team started with four members; after one left, we maintained a size of four‑to‑five. We adopted an agile approach with daily stand‑up meetings at 9 am to discuss progress, blockers, and task assignments, reporting status to the project manager.

Finally, I share some reflections on rapid development of small systems.

Rapid requirement determination – Small systems usually have simple business logic, so quickly sketching prototypes and maintaining close communication with the client helps lock down requirements early.

Reasonable technology selection – Choose technologies that fit the project’s needs and the team’s expertise. Prefer stable releases that are one or two versions behind the latest to avoid immature bugs.

Excellent base architecture – Good code is extensible, maintainable, and reusable. Achieve this by introducing interfaces between layers to reduce coupling, keeping responsibilities single, documenting key modules, and extracting common utilities (e.g., pagination, tree menus, file upload/download).

Project management – Effective management balances schedule control and personnel coordination. Tailor communication and motivation strategies to individual team members, assign tasks based on strengths, and address issues with patience and analysis rather than blame.

Original source: blog.csdn.net/liushuijinger/article/details/40833791

Java Group – Focused on sharing Java knowledge.