Project Smells: Or Loose Thoughts on What to Strive for in the Code Development Process

The author, Mateusz Gorski, reflects on transitioning between development teams and the practices that distinguish well-maintained codebases from struggling ones.

Why This Article

After joining a new team, the author realized that practices previously taken for granted weren't universal across all projects. Rather than condemning existing approaches, this piece examines "smells" - warning signs worth investigating - applicable to developers at any career stage.

Tests

Testing emerges as the most critical practice. Well-written tests serve as living documentation for newcomers. The author emphasizes descriptive test naming, such as "test_raises_validation_error_when_incorrect_country_code_provided" rather than generic labels like "test_fails."

Additional testing considerations include understanding dependency injection for testability, treating test code with the same quality standards as production code, and pursuing comprehensive coverage (even 100% is achievable). Integration testing across multiple layers - validating API endpoints alongside database results - prevents rigid code architectures that over-test individual functions.

Dependencies Between Modules

The piece discusses the Dependency Rule: inner architectural layers shouldn't rely on outer ones. Avoiding circular imports strengthens maintainability. Module-level encapsulation parallels class-level principles.

Programming Frameworks

Developers should recognize design patterns their frameworks impose, acknowledging that one framework's standard may be another's anti-pattern.

Meetings and SCRUM

Excessive meetings drain resources. SCRUM should facilitate rather than imprison teams. Story point estimations aren't universally necessary.

Conclusion

Code ultimately serves business purposes. During reviews, developers must resist assuming their approach is the only valid one.