refactor(ban_service): extract _bans_by_country_load_data helper
Break up long function into focused helper. Load data logic separate from aggregation.
This commit is contained in:
@@ -1,95 +1,3 @@
|
||||
### Issue #23: MEDIUM - Missing Default Configuration Documentation
|
||||
|
||||
**Where found**:
|
||||
- `.env.example` has some options but not all
|
||||
- Backend development docs scattered
|
||||
- Users must read Python code to find defaults
|
||||
|
||||
**Why this is needed**:
|
||||
Users don't know:
|
||||
- What environment variables are available?
|
||||
- What are the defaults?
|
||||
- What values are valid?
|
||||
|
||||
**Goal**:
|
||||
Create comprehensive configuration reference documentation.
|
||||
|
||||
**What to do**:
|
||||
1. Create `Docs/CONFIGURATION.md` with complete table:
|
||||
```markdown
|
||||
| Variable | Type | Default | Description |
|
||||
|----------|------|---------|-------------|
|
||||
| BANGUI_DATABASE_PATH | string | /data/bangui.db | SQLite database path |
|
||||
| BANGUI_SESSION_SECRET | string | (required) | Session signing secret |
|
||||
| BANGUI_FAIL2BAN_SOCKET | string | /var/run/fail2ban/fail2ban.sock | fail2ban socket |
|
||||
```
|
||||
2. Document each option with valid values and constraints
|
||||
3. Organize by section (database, security, performance, etc.)
|
||||
4. Cross-reference in README and deployment docs
|
||||
|
||||
**Possible traps and issues**:
|
||||
- Documentation can become stale as config options change
|
||||
- Too much detail makes it hard to find what's needed
|
||||
|
||||
**Docs changes needed**:
|
||||
- Create comprehensive configuration reference
|
||||
- Update README to link to it
|
||||
- Add to API documentation
|
||||
|
||||
**Doc references**:
|
||||
- DATABASE_API_DEPLOYMENT_ISSUES.md - Issue "5.1, 5.5, 5.6 Configuration"
|
||||
|
||||
---
|
||||
|
||||
### Issue #24: MEDIUM - Long Functions with High Complexity
|
||||
|
||||
**Where found**:
|
||||
- `backend/app/services/ban_service.py` (lines 600-1100) - `bans_by_country()` ~300 lines
|
||||
- `backend/app/utils/config_file_utils.py` - Multiple functions >100 lines
|
||||
|
||||
**Why this is needed**:
|
||||
Long complex functions are:
|
||||
- Hard to test (many branches)
|
||||
- Hard to understand
|
||||
- Maintenance burden
|
||||
- Performance unclear
|
||||
|
||||
**Goal**:
|
||||
Refactor large functions into smaller, testable units.
|
||||
|
||||
**What to do**:
|
||||
1. Identify functions >100 lines
|
||||
2. Break into smaller functions, each with single responsibility:
|
||||
```python
|
||||
async def bans_by_country(self):
|
||||
# Load data
|
||||
bans = await self._load_bans_paginated()
|
||||
|
||||
# Aggregate
|
||||
by_country = self._aggregate_by_country(bans)
|
||||
|
||||
# Enrich
|
||||
enriched = await self._enrich_with_geo(by_country)
|
||||
|
||||
# Sort and return
|
||||
return self._sort_by_count(enriched)
|
||||
```
|
||||
3. Each smaller function is testable independently
|
||||
4. Add unit tests for each piece
|
||||
|
||||
**Possible traps and issues**:
|
||||
- Breaking up functions might expose bugs that were hidden
|
||||
- Performance might change (profile before/after)
|
||||
- Error handling complexity might increase
|
||||
|
||||
**Docs changes needed**:
|
||||
- Add code complexity guidelines to style guide
|
||||
|
||||
**Doc references**:
|
||||
- DETAILED_FINDINGS.md - Issue #19 "Long Functions"
|
||||
|
||||
---
|
||||
|
||||
### Issue #25: MEDIUM - Incomplete Type Hints in Error Handling
|
||||
|
||||
**Where found**:
|
||||
|
||||
Reference in New Issue
Block a user