Where to start coding software?

Question

The project that I am about to start is my first project, and it is very large. Although this is a great opportunity for me, I don’t want me to end up in messy code, so I made a whole software design (software architecture), dividing it into three levels:

• Presentation Level ---- (will be implemented through Java Swing)
• BusinessLogic level - (will be implemented through EJB technology)
• DatabaseLayer ------- (will be implemented using Hibernate)

Q1. What level should I choose for a start?

I have no experience in developing standard products, but I am sure that there is some specific order that is better than others.

Q2. I think these things fall under good design principles and best practices. I searched the Internet for these resources and found good resources, but I would be grateful if you would recommend me some resources that, as you know, have short, accurate and high-quality content?

Answer 1

"my first project and it is very big"

Please, do not do that.

Make a small project first.

• First write "model" (business logic). It will be very difficult, as this is your first project. Keep it small and focused only on business logic, which you can test and prove that it works.

• Drop it.

Now do another project.

• First write "model" (business logic). Based on the lessons learned from the first project, it will be much better. It will be difficult, as this is your second project. Keep it small and focused only on business logic, which you can test and prove that it works.

• Record the preservation and object-relational mapping of the second. Adding database resilience will be very difficult as this is only your first database project and only your second project.

• Drop it.

Now you have an idea of ​​what you are doing. Start the third project.

• First write "model" (business logic). Based on the lessons learned from the first two projects, this will be much better. By now, there will still be a lot of work, because you will finally understand what you are doing. However, this work will no longer include technical problems, now it will include real problems around use cases and what the application really does.

• Record the preservation and object-relational mapping of the second. Based on the lessons learned from the first projects, this will be much better. It will still be difficult. Nothing makes it easy. This is only your second time, so you will still be mistaken; there will be fewer errors.

• Be the last to write your presentation. Is always.

This is the fastest way to make a big project when you do not already know this technology.

Answer 2

Perform the implementation in vertical stripes : implement one project opportunity of three layers so that the design can be checked from end to end .. p>

First you can skip the database level, the data can be hardcoded, not saved, or simply stored in test files.

Answer 3

There are two approaches to this, and both have advantages and disadvantages:

• Top down
  First, create a user interface and implement data access logic and logic where necessary for the user interface.

• Bottum up
  First create a database layer, and then add the user interface functionality later.

The first advantage is that you have (at least in part) a working user interface that is a bit of a customer, which is why it is a de facto industry standard. The latter provides a stable and complete level of database and business logic, but they usually have some overhead because it is not clear how the data will be available / available later.

Answer 4

I think you should start from the level of business logic, since this level should be the one that determines which functions the other layers should have. If you start with a data access layer, you run the risk that you end up with a lot of YAGNI , and in addition, any application should be centered around business logic, not persistence or presentation logic.

You should learn best practices such as DDD and TDD , and you could probably benefit from knowledge of MVVM or a similar model too.

Answer 5

I would add to the existing answers:

Do not use a lot of technologies that you are not familiar with, or have only basic flaws; EJB, Hibernate, etc. They do not give you any assessment of what is happening under the covers, and add to the learning curve, pushing your deadline. Instead, going for something is a lot easier; e.g. RMI client server with JDBC or Spring / JDBC for persistence. You can always redo items later, but it’s better to deliver them incrementally, and not at all.

Answer 6

Q1. Take a pen and a lot of paper and start designing. This way you make “plans” before writing code.

Q2. Using paper first aid for quality design; Regular refinement, refactoring, and review help maintain quality.

Answer 7

Design Principles:

Start here http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod