Test First
In order for complex, secure, stable software applications to succeed, proper testing must take place throughout the entire
development lifecycle. Unfortunately, as the world grows and the pace of business increases, the time allocated for proper testing has shrunk to only a fraction of the time that is needed. Now a philosophy of writing tests before writing your actual code is more than just an academic proposition by Extreme Programming advocates. Whether you are an “Extreme” programmer or not, properly designed unit tests written can not only secure the stability of your code, but it can also speed up the development process.
Less Is More
When given the choice between “less” and “more,” a software developer will reap the benefits if “less” is chosen. For example, unless there is compulsory evidence that a project requires the use of an Enterprise JavaBean server, it is usually advantageous to avoid over-architecting and avoid such heavier implementations. Apply simple, abstract, modular solutions toward your business requirements so that, if a heavier implementation is required, it is trivial to scale up the lighter-weight solution.
Always Ask the Dumb Questions
Before thinking about how any code is to be implemented, take a step back and ask yourself what you actually need to achieve to meet the business requirements. Let’s face it. Writing software is the easy part. Writing software that meets requirements is where we often fall down. It’s important to get a broad understanding of what the software should do
before even considering how it should be implemented. In many cases, it may be that J2EE or even Java is the wrong solution to your problem. Always pay careful attention to what the best solution actually is. Don’t try to fit a solution to the wrong problem. To do this, ask the dumb questions. Ask the really dumb questions. The simplest dumb question is “why?” Why does a button need to be placed there? Why is an extra field needed? Why does a JMS queue need to be used? The higher up you go (that is, the closer to the requirements and further from the implementation), the more likely you are to discover something that may fundamentally change the way you implement the solution. Even if you don’t discover anything new, you will at least be reassured that you have understood the requirements.
Only after discovering the broad overall goal of the requirement should you start thinking about the details of implementation. Before and during implementation, you should continually ask questions. Ask the dumb questions and then ask detailed questions related to the fine-grained implementation. Only through repeated questioning can a developer truly pick the brain of the client and implement the best solution possible
In order for complex, secure, stable software applications to succeed, proper testing must take place throughout the entire
development lifecycle. Unfortunately, as the world grows and the pace of business increases, the time allocated for proper testing has shrunk to only a fraction of the time that is needed. Now a philosophy of writing tests before writing your actual code is more than just an academic proposition by Extreme Programming advocates. Whether you are an “Extreme” programmer or not, properly designed unit tests written can not only secure the stability of your code, but it can also speed up the development process.
Less Is More
When given the choice between “less” and “more,” a software developer will reap the benefits if “less” is chosen. For example, unless there is compulsory evidence that a project requires the use of an Enterprise JavaBean server, it is usually advantageous to avoid over-architecting and avoid such heavier implementations. Apply simple, abstract, modular solutions toward your business requirements so that, if a heavier implementation is required, it is trivial to scale up the lighter-weight solution.
Always Ask the Dumb Questions
Before thinking about how any code is to be implemented, take a step back and ask yourself what you actually need to achieve to meet the business requirements. Let’s face it. Writing software is the easy part. Writing software that meets requirements is where we often fall down. It’s important to get a broad understanding of what the software should do
before even considering how it should be implemented. In many cases, it may be that J2EE or even Java is the wrong solution to your problem. Always pay careful attention to what the best solution actually is. Don’t try to fit a solution to the wrong problem. To do this, ask the dumb questions. Ask the really dumb questions. The simplest dumb question is “why?” Why does a button need to be placed there? Why is an extra field needed? Why does a JMS queue need to be used? The higher up you go (that is, the closer to the requirements and further from the implementation), the more likely you are to discover something that may fundamentally change the way you implement the solution. Even if you don’t discover anything new, you will at least be reassured that you have understood the requirements.
Only after discovering the broad overall goal of the requirement should you start thinking about the details of implementation. Before and during implementation, you should continually ask questions. Ask the dumb questions and then ask detailed questions related to the fine-grained implementation. Only through repeated questioning can a developer truly pick the brain of the client and implement the best solution possible
551
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
