Oracle PL/SQL best practices
In this compact book, Steven Feuerstein, widely recognized as one of the world's leading experts on the Oracle PL/SQL language, distills his many years of programming, teaching, and writing about PL/SQL into a set of best practices-recommendations for developing successful applications. Coveri...
| Autor principal: | |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Inglés |
| Publicado: |
Sebastopol, California :
O'Reilly Media, Inc
2008.
|
| Edición: | 2nd ed |
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009627455906719 |
Tabla de Contenidos:
- Oracle PL/SQL Best Practices, 2nd Edition; They Call This ""Work""?; The Cast of Characters; Structure of This Book; How to Use This Book; Conventions Used in This Book; About the Code; Comments and Questions; Safari Books Online; Acknowledgments; 1. The Big Picture; Successful Applications Are Maintainable; Successful Applications Run Fast Enough; Best Practices for Successful Applications; Software is like ballet: choreograph the moves or end up with a mess.; Solution: Agree on a common development workflow built around standards, testing, and reviews.; Application-level workflow
- Step 2: Build the application foundation.Step 3: Build the next application iteration.; Step 4: Validate the application iteration; Single-program construction workflow; Step 2: Build an iteration of the program.; Step 3: Test the program iteration.; Step 4: Trace execution of the program.; Step 5: Debug the program.; Step 6: Validate the program: optimize and review.; Which steps do you perform?; Deferred satisfaction is a required emotion for best practices.; Step 2. Implement just the header of the program; Step 3. Define the tests that must be run; Step 4. Build your test code
- Contracts work for the real world why not software, too?; Solution: Contracts capture agreements.; Enforcing contracts in code.; Don&t act like a bird: admit weakness and ignorance.; Solution: Give your brain a break, and ask others for help.; Five heads are better than one.; Solution: Move beyond documents to a review process that directly engages the development team.; Resources; Don&t write code that a machine could write for you instead.; Solution: If you can recognize a pattern in what you are writing, generate code from that pattern.; We need more than brains to write software.
- 2. Real Developers Follow StandardsIt&s a free country; I don&t have to use carriage returns in my code.; Solution: Use the built-in functionality of your IDE to automatically format your code.; Too much freedom is a very bad thing.; Solution: Rely on naming conventions that are intuitive and easy to apply.; Good names lead to good code.; Solution: Construct subprogram names so they reflect both what they are and what they do.; Put your checklists into your code.; Solution: Make your checklists active and directly involved in development.; Resources
- Who needs comments? My code is self-documenting!Solution: Sometimes you really do need to add comments.; 3. Life After Compilation; Tracing; Debugging; Best Practices for Testing, Tracing, and Debugging; Thanks, but no thanks, to DBMS_OUTPUT.PUT_LINE!; Solution: Build a layer of code over DBMS_OUTPUT.PUT_LINE.; Assume the worst, and you will never be disappointed.; General Solution: Build instrumentation (tracing) into your application from the start.; Specific Solution 1: Embed trace calls in Boolean expressions to minimize overhead.
- Specific Solution 2: Include standardized modules in packages to dump package state when errors occur.
