SDK Development Best Practices: Design Principles and Coding Standards from Baidu

This article shares the admission standards and coding philosophy when writing SDKs at Baidu, aiming to improve team efficiency and reduce production bugs.

Why Write SDKs?

1. Avoid reinventing the wheel - abstract common functionality into a shared SDK for reuse

2. Reduce production bug probability - collective optimization makes bugs less likely, and fixes apply universally

SOLID Design Principles

The article emphasizes that good code is designed, not written. The five principles are:

- Single Responsibility Principle: A class should have only one reason to change. Example: Separate MobileSound interface (volume control) from MobilePhoto interface (photo adjustment)

- Open-Closed Principle: Software entities should be open for extension but closed for modification. New features should be added through extension rather than modifying existing code

- Liskov Substitution Principle: Subclasses must be substitutable for their base classes. The article demonstrates this with phone charging interfaces, showing how to handle devices with different capabilities (e.g., 8848 Titanium phone without wireless charging)

- Interface Segregation Principle: Clients should not depend on interfaces they do not use. Different modules should have different interfaces

- Dependency Inversion Principle: High-level modules should not depend on low-level modules; both should depend on abstractions

Coding Principles

1. Stability and Efficiency: Public libraries must be stable as failures can affect multiple business units

2. Expose Errors: Log all exceptions and expose error codes to users. Use Panic and Recover in Go to prevent crashes:

func
safelyDo
(work *Work)
{

defer
func
()
{

if
err :=
recover
(); err !=
nil
{

log.Println(
"work failed:"
, err)

}

}()

do(work)

}

3. Testing: Unit tests verify logic correctness; stress tests verify performance under high concurrency

4. Backward Compatibility: Public APIs should not change; new versions should add new interfaces rather than modify existing ones

5. Minimize External Dependencies: Keep the SDK lean to avoid dependency instability

6. Usability: Simplify complex calls, provide unified configuration management

7. Understandability: Clear directory structure, consistent code style, comprehensive comments, and documentation

Practical Experience

- All commits must be linked to internal requirement cards

- Golint code style checks are mandatory

- Git branch version management

- CR committee for code review