Hello
my name is Hadeel, I am graduated from University of Jordan ! [my linkedin] (https://www.linkedin.com/in/hadeel-daragmeh-524727206)
I learned about somthings like :
- Unity
- Javafx
- Php And so on...
I love learning so much, i feel it's a good way to unload energies and gain skills in a perfect way And that it😉
- Conceiving The Purpose of Software
- The Goals of Software Design
- (Mis)understanding
- Simplicity
- Complexity
- Maintenance
- Consistency
- Prioritizing
- Solving Problems
- Good enough is fine
- Predictions
- Assumptions
- Stop Reinventing
- Resistance
- Automation.
- Code measurement
- Productivity
- Testing
- (Under)Estimation
- Running Away From Rewriting
- Documentation and Commenting
- Picking Technologies (Tools, Libraries, etc.)
- Self-Development
- Don’t be a hero
- Don’t Ask Questions… Ask For Help.
Your design should be easy for you and helpful for others..
Bad developers don’t understand what they are doing, and good developers do. It really is that simple
A “good developer” is doing everything in their power to make the code as simple as possible for other programmers.
Controlling complexity
you will exactly know your software purpose and its definition. Second, you will be as simple as possible in every piece of code you write. Third, when a new feature or change request comes to the discussion table, you will evaluate them based on your software purpose and question them.
Your main purpose is to control complexity, not to create it.
effort of maintenance than it is to reduce the effort of implementation.
The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change.
dividing. Don’t try to solve one big problem. When you look at the problem as a whole, it can scare you. Divide it into smaller tasks and solve each sub-problem one by one. Once you solve each sub-problem, you connect the dots.
Don’t predict to future. Be only as generic as you know you need to be right now.
Code should be designed based on what you know now, not on what you think will happen in the future.
Don’t reinvent the wheel. Always resist adding more code, more features until you are convinced that they are required and there is a need to implement them. Because unnecessary changes will increase defects in your software. If you can automate it, automate it. The optimum code is a small bunch of code that is easy to understand, easy to read.
- When you have a bug, first you should reproduce it. You shouldn’t guess the source of the bug and apply fixes based on your assumption. Most probably, you will be wrong. You should see it with your own eyes before applying the fix.
Break the big thing into smaller things. The smaller it is, the easier it is to estimate.
You’re probably still going to get it wrong, but you’ll be a lot less wrong than if you estimated a big project. *
- When you can’t make the code simpler then you should add the comment to explain this complexity.
When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice. Look to peers and senior developers to review your code.
you can read the article from this link
klick here
