When it comes to dividing your application into modules.. do u believe in inter-module dependency, or every module must be able to standalone?
This is my thought…
I am assuming you are talking about modules for specific framework, instead of general module that is framework agnostic.
I think it is OK to have inter-module dependency, just do your best to minimize it. 0 dependency module is ideal, but need to weight cost of effort and code duplication.
Supposed I have a timetable module for student to manage timetable. It requires access to DB. If there is already a ORM/DB module, there is no need to rewrite another one just to make sure my module has 0 dependency.
Do 1 things, and do it well. If your module is very focus, it usually will have minimal dependency on other modules.
Use a dependency resolution/manager. On PHP platform, Composer makes sure the dependent modules are in place.
I will avoid writing an 0 dependency module at the expense of reinventing the wheel. I prefer to write reusable code and use them whenever possible. I will let the dependency manager handle the dependencies.
Benson:Personally I find that implementing a project with dependency injection in mind can cause development time to take longer, but you will appreciate the flexibility it gives and ease of testing once the application gets bigger in future.
Many times, shorter development time, which sounds pleasing to any client, is really not the way, especially if the client is gonna work with you long term over the same project.
Hong:Another technique for reducing technical debt, but does not take extra time, is to write testable code. You may may decide not to do unit testing, but you can still write testable code. From my experience, it greatly helps me reduce coupling among code.
Of course, you will need have unit testing experience to know what is "testable code".
An excellent post on how to present product to users. When writing a marketing message, it is a good idea to focus on benefit, instead of features. The article has described (with examples) on the difference between benefits and features.
From users’ perspective, why would they want to use your product?
Keeping it DRY (Don’t Repeat Yourself) helps to reduce technical debt. Once you spotted either a piece of information or code been duplicated in 2 places, it is time to refactor. It may be putting it into a function, or setting it as a class constant. Don’t wait until it starts duplicating in more than 2 places.
I think it is not enough to know only 1 application framework and use it as a Swiss Army Knife for everything. It better to learn different frameworks each designed to solve different problems. I suggest learning 1 framework at a time, and get sufficiently effective with it, before moving on to learn the next class of framework.
These are some classifications I would like to learn at least one framework in each category:
Sometime my client tells me that he wants a particular feature. It is good to take a step further and figure out why he wants this feature. It is crucial to understand the client’s problems you are paid to solve.
Possible outcome of discovering the root problem:
You may be able to propose alternative feature that can better solve this problem (possibly easier implementation)
You may discover that the feature may not be solving the problem at all, and it might need to be remove from feature list