Here are few facts and rules I conceived from whatever little experiences I have got......
1. All the rules below have exceptions including this one.
2. No matter how good a program you wrote, there is always a scope of improvement, most of the time you know it but either feel too lazy or don't have time to improve upon that (let's face it later is an excuse for former).
3. Why comments are necessary? Human memory is more complex and fragile than Computer memory. the reason for which you have to do something in order to accomplish something gets obsolete after it's accomplished. However in case you have to go back (which is quite often) you might have to bang your head to recall why you did what you did. Comments saves your head. Also comments more come into picture when someone is trying to decipher your codes or vice-versa. If you want to save yourself from some abuses always go for commenting. Best approach is to make it a habit.
4. For developers testers are big time morons and for testers developers are equally idiots. It's sort of universal truth and feelings are usually mutual as they say. However they both have their perspective. Developers are more close to business level hence functionality for them is actually the application, Testers on the other hand are more close to end-users hence look and feel, UI, compatibility for them is sort of USP of application.
5. Truth is developer feels more confident on the application when testers bring out any functionality bug because it gives them the confidence that their functionalities implementations are properly being tested, however if there are lots of UI bugs it makes developers annoying as they don't get the confidence of their implementation being double checked instead they have to fix (what they consider) pity issues.
6. Many a times I find people going for help to others/seniors to solve their problem, well it's necessary sometimes specially when you have a deadline to fulfill, but sometime it becomes a habit however it gets annoying for others as no one wants to be interrupted by same person (specially of same gender) every time. In my opinion until and unless its necessary which means you have a time-limit and you have invested enough time on it you must not go to other people, In fact I personally ask for help when I have tried I assume everything they will do which in other words even they won't be able to do, At that point its fine to be surprised.
7. Quite often 'Hit and trial' is an ultimate solution.
8. Pick a day when you don't feel like working and there isn't real workload to remove the commented codes.
9. It's better to use and rely more on native methods and functions, they are safer, more reliable and better taken care of in internal processing.
10. Workarounds are necessary evils.
11. If you write jokes in your code it will make a funny application (if you know what I mean).
12. I feel the most sensitive and important part in back-end development is when you deals with the database layer. Most optimization, performance and security issue comes from there only. It's a good idea to rest and think a while before writing that layer.
13. This is a personal opinion but I feel that front-end validations should be the last implementation so that your back-end is sort of full-proof. If you apply front-end validations up-front in the beginning then your back-end wont be properly tested with range of inputs which goes from front-end without validation, hence back-end isn't prepared to tackle the challenges all by itself. Son in case your front-end validation fails their is a huge chance that your back-end will also fails.
..........................................
No comments:
Post a Comment