Source

Kephra / doc / CompleteProgramming.pod

Full commit
=head1 Complete Programming

This document describes the method the Kephra editor is developed with.
Its highest aim is to have at all times a usable program with the
highest quality at all levels while still allowing programming be fun.



=head2 Overview

=head3 DISCLAIMER

I strongly dislike strict rules imposed on me and make fun of people that
produce theories with three letter acronyms that try to be the answer to everything.
But now I am standing here, trying to "sell" you yet another programming methodology.
That IS irony, isn't it? At least I use only two letters beause this is more important.


=head3 Rationale

Well, several reasons brought me here.

1.) I always wanted a sane balance between the old bureaucratic waterfall method,
    and the modern extreme or agile programming, which is a bit too shortsighted,
    and accumulates additional work as the project grows.
    It should be possible to combine sound planning, practicability and quick results.

2.) Writing tests is no silver bullet and is used for several competing purposes.

3.) The awesome powers of prototypes are still not fully used.

4.) All methodologies I know of overlook several aspects of the product.
    That includes even "documentation driven development",
    which gave important impulses for the creation of CP.

5.) New tools like hg or git allow new workflows which solve pending problems.


=head3 Main Goal

Highest aim of CP is the conscience the code is produced with. As result you get
   * a superb overall user experience
   * quality code
   * transparent project planning and status
   * room for experiments and changes without trouble


=head3 Principles

   * All code and data of the project go into one repository.
   * If there is something missing write it down and commit.
   * There are no development phases in CP. You always try to be productive.
   * Even the initial list of needed features is part of the documentation.

   * Before implementing new functionality (not just a lib call),
     write a small prototype with just that function.
   * There is a seperate branch for all these prototypes to stay in.
   * When th  



=head2 Details

=head3 Defining Task and completness

main task

aprox. feature set

parts to do
   * documentation (user, programmer, comments)
   * prototypes
   * supply libs 
   * tests
   * logic
   * visuals
   * configs

resources

what kind of team to solve it with

what technologies, languages, libs, os, other tools
fallback alternatives or areas you might expand into

=head3 Early Development

=head3 Normal Development

=head3 Maintenance

Even if productive software is never done and you wand to get something usefull


=over 4
=item * 
=back