rename folder docs -> doc & add goals.md
This commit is contained in:
parent
c376e31d55
commit
2f3ad2e6a6
4 changed files with 37 additions and 1 deletions
2
.gitignore
vendored
2
.gitignore
vendored
|
@ -21,7 +21,7 @@
|
||||||
!deps.edn
|
!deps.edn
|
||||||
!pom.xml
|
!pom.xml
|
||||||
!dev/
|
!dev/
|
||||||
!docs/
|
!doc/
|
||||||
!resources/
|
!resources/
|
||||||
!src/
|
!src/
|
||||||
!test/
|
!test/
|
||||||
|
|
36
doc/goals.md
Normal file
36
doc/goals.md
Normal file
|
@ -0,0 +1,36 @@
|
||||||
|
# Goals
|
||||||
|
|
||||||
|
### Goals for the end-user
|
||||||
|
|
||||||
|
* Easy-to-use user interface
|
||||||
|
* Consistent structure for commands, parameters and options
|
||||||
|
* User needs to provide only data which is required for the specific task
|
||||||
|
* e.g. data that can be derived from other data should not need to be provided
|
||||||
|
* Informative feedback - in both cases:
|
||||||
|
* Success
|
||||||
|
* high-level information about the performed actions is shown - possibly enriched with selected useful details
|
||||||
|
* Failure
|
||||||
|
* clear information about the error is shown - and where applicable, possible solutions are mentioned
|
||||||
|
* Intuitive user-interface, which requires only little documentation - but where necessary, documentation is provided either in the
|
||||||
|
* help function or
|
||||||
|
* in separate documents (e.g. in cases where longer explanations are helpful)
|
||||||
|
|
||||||
|
### Goals for the developer
|
||||||
|
|
||||||
|
* Easy-to-understand architecture and code
|
||||||
|
* clear architecture (with high-level documentation)
|
||||||
|
* clear control flow
|
||||||
|
* sufficient control about the order of execution
|
||||||
|
* consistent and intuitive naming of modules, fields and functions
|
||||||
|
* documentation where helpful
|
||||||
|
|
||||||
|
### Goals for end-user and developers
|
||||||
|
|
||||||
|
* Clear modularization concept
|
||||||
|
* modules can be run separately (in the sense that they only involve other modules where strictly required)
|
||||||
|
* similar to the interface segregation principle but on module level
|
||||||
|
* useful for developers e.g. for integration testing and for maintainability of the code (due to less dependencies)
|
||||||
|
* for end-users for selected modules, i.e. if they have a need to run the module separately
|
||||||
|
* modules can be easily combined by developers in order to provide composed functionality
|
||||||
|
* modules require minimal input (i.e. only input which is strictly necessary for their execution)
|
||||||
|
* similar to the interface segregation principle but on data-level
|
Loading…
Reference in a new issue