Kephra / doc / CompleteProgramming.pod

=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

    The name is a reminder that we reach for the impossible,
    because software is never complete. So please focus AND relax.

    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 Intentions

    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) The awesome powers of prototypes are still not fully used.

    3) Documentation coverage and depth matters a great deal and writing it
       would also help the developer.

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

    5) 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.

    6) 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
    
=item a superb overall user experience
=item quality code
=item transparent project planning and status
=item room for experiments and changes without trouble


=head3 Principles

=item Every action has a productive and lasting (yet changable) result.
=item All code, data and metadata of the project go into one repository.
=item Before implenenting a functionality that isn't just a lib call write a prototype.
=item Before implementing a use case, write a prototype.
=item These two types of prototypes stay in their respective dir/branch.
=item After the prototype you write the docs, then the code and then the test. 
=item When implementing a feature, do also the docs, test, GUI and the configs.



=head2 Details


=head3 Planning

First step: should be writing down the approximate feature set, save and commit it.
Its now part of the documentation and also serves as the todo.

Second step: think what what technologies, languages, libs, os, other tools
you should select and procede as in step one.
Spend some minutes on fallback alternatives or areas you might expand into.
Also consider now what kind of team could solve that task.

Rough drafts are all you need.


=head3 Prototypes

=head3 Documentation

=head3 Code

=head3 Tests

=head3 Completeness

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

=head3 Releases



parts to do

=over 4
=back
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.