Linked e-resources
Details
Table of Contents
Intro
Table of Contents
About the Author
About the Technical Reviewer
Acknowledgments
Introduction
Chapter 1: Why Object-Oriented Programming Is a Must for Code Quality
Why OO Has Never Taken Off in ABAP World
OO Benefits: The Theory
Describing OO Programs: UML
Describing OO Programs: BON
Seamlessness/Reversibility
Seamlessness via an Automated Tool
Seamlessness via Naming Conventions
Design by Contract
Design by Unit Tests
Designing a Worldwide OO Program
What Is the Existing System State?
Why Is the Existing System State Not Portable?
What Can Be Done About Fixing That Problem?
Breaking Dependencies in General
Breaking Dependencies via Packages
Breaking Dependencies via Interfaces
What Is an Interface in OO Terms?
How SAP Uses Interfaces to Manage User Exits
Not Breaking the System
My Journey to OO Happiness
OO Happiness: The Theory
The Clean Coder
Clean Code
Head-First Design Patterns
More on Design Patterns
OO Happiness: The Reality
Writing an Interactive Executable Report in OO
Writing a DYNPRO Program in OO
Experiment
Rewriting a Huge, Business-Critical Program in OO
Slowly Transforming a Huge, Business-Critical Program to OO
OO Benefits: The Reality
Soft Benefits
Design Thinking
Ease of Maintenance
No One Goes Back
Hard Benefits
Avoidance of Syntax Errors
Parameter Handling
IMPORTING
EXPORTING
TABLES
RETURNING
OPTIONAL
NAMES
TYPES
FORMULAS
Reuse
Making Code Testable
Conclusion
Recommended Reading
Articles
Books
Chapter 2: Why Test-Driven Development Is a Must for Code Quality
TDD Theory
Fragile Code
Legacy Code
Automated Regression Tests
Dependencies and How to Break Them
The TDD Development Cycle: RED/GREEN/BLUE
My Journey to TDD Happiness
Testing After the Event
Testing Before the Event
TDD Workflow in Eclipse
Creating Test Doubles
Creating a New Test Method
Coding the Test Method
Coding the THEN Method
Coding the GIVEN Method
Coding the WHEN Method
Writing the Production Code
The BLUE Phase
Does This Actually Give You a Benefit?
From a Gut Feeling ...
... to a Concrete Example
Some Unit Tests Might Seem Pointless ...
It's Too Short to Test
It's Too Simple to Test
... but They Are Not!
Message in a Model
You Can't Get There from Here
Simpler but Wrong
Why TDD Has Never Taken Off
I Already Have an Automated Testing Framework
My Program Is Too Complicated for TDD
My Program Is Too Simple for TDD
TDD Is Far Too Expensive
TDD Reduces Development Costs
TDD Reduces the Cost of Fixing Bugs
TDD Reduces the Financial Risk of Failure
Conclusion
Recommended Reading
Chapter 3: Clarity: The First Pillar of Code Quality
Refactoring: Automated and Manual Checks
Automated Checks
Syntax Check
Extended Program Check
Code Inspector
Table of Contents
About the Author
About the Technical Reviewer
Acknowledgments
Introduction
Chapter 1: Why Object-Oriented Programming Is a Must for Code Quality
Why OO Has Never Taken Off in ABAP World
OO Benefits: The Theory
Describing OO Programs: UML
Describing OO Programs: BON
Seamlessness/Reversibility
Seamlessness via an Automated Tool
Seamlessness via Naming Conventions
Design by Contract
Design by Unit Tests
Designing a Worldwide OO Program
What Is the Existing System State?
Why Is the Existing System State Not Portable?
What Can Be Done About Fixing That Problem?
Breaking Dependencies in General
Breaking Dependencies via Packages
Breaking Dependencies via Interfaces
What Is an Interface in OO Terms?
How SAP Uses Interfaces to Manage User Exits
Not Breaking the System
My Journey to OO Happiness
OO Happiness: The Theory
The Clean Coder
Clean Code
Head-First Design Patterns
More on Design Patterns
OO Happiness: The Reality
Writing an Interactive Executable Report in OO
Writing a DYNPRO Program in OO
Experiment
Rewriting a Huge, Business-Critical Program in OO
Slowly Transforming a Huge, Business-Critical Program to OO
OO Benefits: The Reality
Soft Benefits
Design Thinking
Ease of Maintenance
No One Goes Back
Hard Benefits
Avoidance of Syntax Errors
Parameter Handling
IMPORTING
EXPORTING
TABLES
RETURNING
OPTIONAL
NAMES
TYPES
FORMULAS
Reuse
Making Code Testable
Conclusion
Recommended Reading
Articles
Books
Chapter 2: Why Test-Driven Development Is a Must for Code Quality
TDD Theory
Fragile Code
Legacy Code
Automated Regression Tests
Dependencies and How to Break Them
The TDD Development Cycle: RED/GREEN/BLUE
My Journey to TDD Happiness
Testing After the Event
Testing Before the Event
TDD Workflow in Eclipse
Creating Test Doubles
Creating a New Test Method
Coding the Test Method
Coding the THEN Method
Coding the GIVEN Method
Coding the WHEN Method
Writing the Production Code
The BLUE Phase
Does This Actually Give You a Benefit?
From a Gut Feeling ...
... to a Concrete Example
Some Unit Tests Might Seem Pointless ...
It's Too Short to Test
It's Too Simple to Test
... but They Are Not!
Message in a Model
You Can't Get There from Here
Simpler but Wrong
Why TDD Has Never Taken Off
I Already Have an Automated Testing Framework
My Program Is Too Complicated for TDD
My Program Is Too Simple for TDD
TDD Is Far Too Expensive
TDD Reduces Development Costs
TDD Reduces the Cost of Fixing Bugs
TDD Reduces the Financial Risk of Failure
Conclusion
Recommended Reading
Chapter 3: Clarity: The First Pillar of Code Quality
Refactoring: Automated and Manual Checks
Automated Checks
Syntax Check
Extended Program Check
Code Inspector