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
|
||||
!pom.xml
|
||||
!dev/
|
||||
!docs/
|
||||
!doc/
|
||||
!resources/
|
||||
!src/
|
||||
!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