part developer PL / SQL - 1st part
Saturday, October 31, 2009
Shingles And Swimming
Reading the book from Steven Feuerstein Oracle PL / SQL Programming 5th ed. -Which is incidentally highly recommended reference material for developers PL-shares the following tips in your opinion are the result of being trained to teach and work with thousands of developers in PL and in which process has obtained some conclusions about the way we all do our job in the world of PL / SQL. 
did not develop the rush! Almost always we are working with tight delivery times, or catching up on the odd setback. We have no time to lose and a lot of code to write. So get to work, right?
False. If we get well soon and fully converting the code to build exactly the requirements in the hundreds, thousands or even hundreds of thousands of lines of code, we'll end up with total chaos that is almost impossible to debug and maintain.
should not panic before deadlines, it is likely to be met if you do careful planning. Steven recommended to resist the pressure of delivery and to ensure the following before starting a new application or even a specific part of the application: Building
cases and test scripts before writing the code must
determine how you will ensure a successful implementation before writing a single line of program code. Doing so is more likely that the interface of your program is correct, and fully identify what your program needs to do.
Establish clear rules for how developers write SQL statements in the application
In general, Steven does not recommend that every developer to write lots of SQL. Instead, the queries that return a single record, inserts and updates should be "hidden" in procedures and functions pre-built and well tested (called
information encapsulation). These programs can test, optimize and maintain a more effective way than just SQL statements (some of them redundant) scattered throughout the code.
clear rules on how the developers handle the exceptions in
team All developers should launch, manage and log errors in the same way. To achieve this, it's best to create a single package error-handling that hides the details of how to record these, setting out as exceptions thrown and spread upward through nested blocks, and to avoid hard coding specific exceptions-de-la-application. Ensure that all use that package and
not write their own error handling code complicated, time consuming and error prone.
Use the refinement step by step "(also called top-down design) to limit the complexity of the requirements to face at any given time
If you use this approach, you will see that run parts of your modules are short and easy to understand, which makes the code easier to maintain and improve it over time. Local or nested modules play a key role in monitoring this design principle.
These are just a few important things to take into account
before starting to write all that code. Just remember: the software development world, haste not only makes things fragile, almost guaranteed a generous offer of bugs and lost weekends.
False. If we get well soon and fully converting the code to build exactly the requirements in the hundreds, thousands or even hundreds of thousands of lines of code, we'll end up with total chaos that is almost impossible to debug and maintain.
should not panic before deadlines, it is likely to be met if you do careful planning. Steven recommended to resist the pressure of delivery and to ensure the following before starting a new application or even a specific part of the application: Building
cases and test scripts before writing the code must
determine how you will ensure a successful implementation before writing a single line of program code. Doing so is more likely that the interface of your program is correct, and fully identify what your program needs to do.
Establish clear rules for how developers write SQL statements in the application
In general, Steven does not recommend that every developer to write lots of SQL. Instead, the queries that return a single record, inserts and updates should be "hidden" in procedures and functions pre-built and well tested (called
information encapsulation). These programs can test, optimize and maintain a more effective way than just SQL statements (some of them redundant) scattered throughout the code.
clear rules on how the developers handle the exceptions in
team All developers should launch, manage and log errors in the same way. To achieve this, it's best to create a single package error-handling that hides the details of how to record these, setting out as exceptions thrown and spread upward through nested blocks, and to avoid hard coding specific exceptions-de-la-application. Ensure that all use that package and
not write their own error handling code complicated, time consuming and error prone.
Use the refinement step by step "(also called top-down design) to limit the complexity of the requirements to face at any given time
If you use this approach, you will see that run parts of your modules are short and easy to understand, which makes the code easier to maintain and improve it over time. Local or nested modules play a key role in monitoring this design principle.
These are just a few important things to take into account
before starting to write all that code. Just remember: the software development world, haste not only makes things fragile, almost guaranteed a generous offer of bugs and lost weekends.
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment