A Snapshot of Highlights for Beginners in Application Development
After working in a web application project for almost six months, seeing new members coming and old ones leaving, finally I’m rolling off from the project as well. It’s a pity that I can’t wait till the project go live, yet I hope I can pick up what I learned from the project so far and summarize them into tips that you can take away as follows.
The tips only cover a small fraction of what web developers should take care of, however they seem to be useful for preventing some previous bugs that we’ve encountered, the bugs that were not easily noticed at the beginning but later caused some strange behaviours.
Web I/O related
Do remember to disable input fields that are not necessary as it might cause unexpected values to be recorded, rather than just hide the web elements when input options depends on other predicates (say, you need to satisfy some conditions in order to get the input fields popped up). The unexpected values usually come from historial inputs. One more thing good about disabling elements that are not in used is that it can avoid the unnecessary event bindings.
If those input fields are not supposed to be seen in some scenario, just dont’t render them at the very beginning.
Only give the input fields that you really need.
Never trust user inputs, for they can be either too stupid or smart. That’s why we need validation. And validation takes carefulness.
- Reject null input if you do need the information(otherwise you had better not render the input fields at all).
- Restrict the values within the acceptable scope. The values must be within a close set all the time. Test all the boundary cases.
- If the validation rules are not applicable all the time(for example, some business logic only applies to some specific scenarios when users give the related inputs, and will be ignored in other cases), when they are not applicable(which means the inputs are not required), reset them by default as this kind of behaviours imply that the user is not going to input these specific fields. This helps to avoid the cases of capturing unvalidated inputs.
- If you are capturing a varied length Array or List from the page, make sure the correct mechanism is used for binding data input. For this part, just google it.
In a word, the ultimate goal of validation is to help you get the information you need while rejecting the others that you don’t need. Either you accept the inputs, or you reject. There’s nothing in between.
Design test cases that will cover all the logic branches, and use boundary cases as test indicators.
If there are some logics that are not well described by test cases, it may cause confusion and even introduce some bugs when we do the refactoring in the future. This is quite true when we are dealing with third party services and they are non-deterministic and thus causing unexpected outcome for us to adjust. RAC is one case that we’ve come up with.
Some web logic relies on state variables, make sure they are set and reset at the right time.
Base your design on states rather than behaviour, so that you will get a clear clue of developing and testing with less error prone outcome.
If things are too complicated, take state machine into consideration.
People come and leave. So others will read your codes as you will read others’. And after some time people may forget about the context where you wrote a specific piece of codes, that’s when knowledge transferring really matters. The context contains the related business logic, the defect you tried to fix, etc. To make it worse, these things are always changing so there will be a time that for others it’s hard to tell which part they should refer to and which part should be updated. Then it’s extremely important that there should be no hidden knowledge. Everything should be recorded, no matter they come in a form as test cases, comments, Jira descriptions, or even documents. While pair programming will definitely helps the knowledge transfer, people should still keep in mind that human minds are not as reliable as a well running mechanism for sharing. People may forget, yet machines seldom.
That’s why I’m writing this article.