|
|
@@ -0,0 +1,92 @@ |
|
|
|
|
|
|
|
|
## A. Documentation |
|
|
|
|
|
We are working on a framework, is **mandatory** that you have read the framework doc: |
|
|
|
|
|
* [symfony/doc](http://symfony.com/doc/current/book/index.html) |
|
|
|
|
|
* [symfony/cookbook](http://symfony.com/doc/current/cookbook/index.html) |
|
|
|
|
|
*** |
|
|
|
|
|
## B. Coding Standard (PSR-0, PSR-1, PSR-2) |
|
|
|
|
|
We use PHP you should know what is [php-fig](http://www.php-fig.org) |
|
|
|
|
|
*** |
|
|
|
|
|
## C. Coding style |
|
|
|
|
|
1. Tvision Style is "No frills" |
|
|
|
|
|
2. Simple-Clean-Rude-This-Week is **always better than** |
|
|
|
|
|
Complex-NextMonth **and** Perfect-Never too. |
|
|
|
|
|
|
|
|
### We are not dummy coders, we code... |
|
|
|
|
|
1. Clean |
|
|
|
|
|
2. With annotation, the Classes and the Functions has PHPdoc |
|
|
|
|
|
3. Without debugging comments eg. //echo |
|
|
|
|
|
4. The variable name should replace the comment see [book clean code](http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) (this book is in our library). |
|
|
|
|
|
5. Only the English language exists in the code. |
|
|
|
|
|
6. Follow the Object Oriented extreme philosophy. |
|
|
|
|
|
7. If you wrote code with too much "if-else", maybe you didn't follow correctly the step n#6. |
|
|
|
|
|
8. Event and Logger are good friends. |
|
|
|
|
|
9. Exceptions are very good friends. |
|
|
|
|
|
|
|
|
### We are good developer and we want to evolve, reading and studying. |
|
|
|
|
|
|
|
|
### We deeply use these: |
|
|
|
|
|
* [design-philosophies](https://docs.djangoproject.com/en/dev/misc/design-philosophies/). |
|
|
|
|
|
* Dependency Injection |
|
|
|
|
|
* Design Patterns. |
|
|
|
|
|
* BEST PRACTICE. |
|
|
|
|
|
* Test before coding |
|
|
|
|
|
|
|
|
*** |
|
|
|
|
|
## D. Git and Flow |
|
|
|
|
|
We use the git-flow standard naming convention and branching model |
|
|
[http://nvie.com/posts/a-successful-git-branching-model/](http://nvie.com/posts/a-successful-git-branching-model/) |
|
|
|
|
|
create a branch name for each task |
|
|
|
|
|
### Design Flow |
|
|
|
|
|
Follow this pattern |
|
|
|
|
|
1. \[use case list\] **Get** a task from the use case list. |
|
|
|
|
|
2. \[develop\] **Develop** on your repo (using a branch for every task) |
|
|
|
|
|
3. \[git\] **Push** to your fork whenever you want (also with broken tests) |
|
|
|
|
|
4. \[test+git\] **Pull** from upstream when your task is complete and all the tests are green |
|
|
|
|
|
5. \[test\] **Check** that the tests are still green |
|
|
|
|
|
6. \[git\] **Make** a Pull Request |
|
|
|
|
|
7. \[use case list\] **Flag** the task in the use case list as Waiting Quality Assurance. |
|
|
|
|
|
|