Collection and sharing of, interview questions and answers asked in various interviews, faqs and articles.....
Showing posts with label Project LifeCycle. Show all posts
Showing posts with label Project LifeCycle. Show all posts
Best practice #4: Recycle your resources
Invariably, applications waste too much time fetching, creating, or destroying some complex objects or resources. Others may be too expensive for a single application to maintain on a one-to-one basis. Therefore, you should create a limited number of the resource, and share them from a common pool. You can pool many types of resources, from complex objects to connections. J2EE will manage some of these for you. For example, J2EE connection pools can improve performance by an order of magnitude for extreme cases.
Best Practice#3: Use a Standard Modeling Language
Designers and Developers, as well as everyone involved in the development process, need to be able to communicate clearly with one another. To improve communication, you need a common language to articulate the design of application components.
Best practice #2: Design for change with Dynamic Domain Model
Modern developers need to have domain models that are nimbly changed. With the emergence of iterative development and shorter development cycles, there is almost certainty that changes to an application will occur after the initial design. To effectively handle changes, developers shouldn’t have to completely rework tested code. An application needs to be able to nimbly handle changes in a way that ensures a high level of quality.
Best practice #1: Attack risk as early as possible
The risk associated with application development seems to rise exponentially with complexity. While it may seem hopeless, there are some things that you can do to mitigate your risks. From a process perspective, perhaps the most important risk mitigation involves moving risk to the front of the schedule, reducing your risk in three ways:
· Improving knowledge. The biggest risks will always be associated with the unknown. Earlier knowledge will allow you to make more informed decisions and better schedules through the remainder of development cycle.
· Allowing recovery time. If you’re going to fail, it’s better to fail early, while there’s
still time to recover.
· Involving the customer early. Your customer’s response to a user interface or key capability can dramatically impact the direction of a project. Inspiring confidence early improves your relationships.
· Improving knowledge. The biggest risks will always be associated with the unknown. Earlier knowledge will allow you to make more informed decisions and better schedules through the remainder of development cycle.
· Allowing recovery time. If you’re going to fail, it’s better to fail early, while there’s
still time to recover.
· Involving the customer early. Your customer’s response to a user interface or key capability can dramatically impact the direction of a project. Inspiring confidence early improves your relationships.
Subscribe to:
Posts (Atom)