You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. We will proceed with core functionality (nearly all backend) before implementing the UI.
49
-
2. Code should be simple and designed for testability. Add tests for critical logic, especially around Git repository analysis and data handling. Use Go's built-in testing framework and aim for good coverage on core functions.
50
-
3. Modular design - core logic should be standalone and not often to change if we want to swap out anything at the "boundary" (e.g. Git library, database, frontend framework). To this point, use interfaces and dependency injection where appropriate to decouple components (manual DI, no frameworks). For example, we can define a `GitRepository` interface that abstracts away the underlying Git library, allowing us to swap out `go-git` for another implementation in the future without affecting the rest of the codebase.
51
-
52
-
## General features of the app
53
-
54
-
- A read-only interface of a given Git repository. The Git repository should already exist on disk, and the user should be able to select it via a file dialog. Upon load, there should be a background indexing processes (details TBD) that will create a new SQLite database file in the same directory as the Git repository (automatically added to git/info/exclude so that it is never committed). This database will be used to power all analytics and visualizations in the app, and will be updated incrementally as new commits are added to the repository.
55
-
- The primary features will be related to the following:
56
-
- Commit graph visualization (total and by contributor)
57
-
- Code change heatmaps (e.g. by time of day, day of week, etc.)
58
-
- Contributor activity timelines
59
-
- File change history and statistics (including churn, most changed files, etc.) in a hierarchical format (to understand changes at the directory level as well as file level)
45
+
1. Code should be simple and designed for testability. Add tests for critical logic, especially around Git repository analysis and data handling. Use Go's built-in testing framework and aim for good coverage on core functions.
46
+
2. Modular design - core logic should be standalone and not often to change if we want to swap out anything at the "boundary" (e.g. Git library, database, frontend framework).
0 commit comments