I have been writing an E-shop project for a customer and now I have signed a new similar contract with another customer. I was wondering what would be the best practice to continue the first project while staring the second so that the reusability is at maximum?
One way would be to change the first project to read all menu items, slider pictures, ... from the database so that I can deliver the same project to both customers with different databases. The benefit of this approach is that I have to manage only one project, but it leads me to gradually write a CMS, which is a time-consuming task.
The other solution would be to use Git. For example, I would fork the base project into two different projects. If the functionality I am writing is the base one, then I would push it into the base project; otherwise, I push it into the appropriate forked project.
Which one is a better approach in your opinion? Or you guys have any better idea?
Cheers, Habib
I have finally found some solutions that I would like to share with you guys. Let's divide differences into 2 big categories of data differences and code differences:
Differences in data
If the database in each project is different (e.g., the product has some features in one project and some other features in another project), then the best solution is to use NoSQLs such as MongoDB. In the first place, NoSQLs are designated to support databases that don't have well-defined data structures, and you don't know what features you may add to each entity at present or in the future. It completely applies to my scenario that each shop may have a different data structure. However, since my project is based on Laravel and it does not have built-in support for MongoDB, I have decided to design some key-value tables that haven't been so bad so far.
Differences in the code
Regarding differences in the code, I would definitely suggest branches in Git and other functionalities provided by Git repositories such as Gitlab repository mirroring. Each feature has a different branch in my code, and I can provide each customer with different functionalities by merging those branches I want to deliver to the customer.
All in all, you may take as much business logic as you can into the database since changing it in the future is more straightforward. On the other hand, you'd better keep themes in the code because every customer likes a different theme, and changing them in the code is easier than taking them to the database.