Developer guideline » History » Version 17
Max Milbers, 11/22/2016 07:45 PM
1 | 1 | Max Milbers | h1. Developer guideline |
---|---|---|---|
2 | |||
3 | 12 | Max Milbers | h2. Philosophy and goal |
4 | 13 | Max Milbers | |
5 | 12 | Max Milbers | The goal is to write a small fast and stable core code which is easy to extend. The priorities are as the following: |
6 | 16 | Francesco Abeni | * Write OOP and clean in the given MVC structure |
7 | * Protect and secure the code |
||
8 | * The code should be fast and performant |
||
9 | * Focus on the core functions, and only as last thing, think about eyecandies and design. |
||
10 | 12 | Max Milbers | |
11 | 7 | Max Milbers | Remember we dont want an ecommerce framework full of features. We want a slim and fast framework which can be easily extended with features. |
12 | 1 | Max Milbers | |
13 | 16 | Francesco Abeni | * Mistakes might happen, important is to learn from them |
14 | * It is better to do something wrong than to do nothing |
||
15 | 1 | Max Milbers | |
16 | h2. Guidelines for teamwork |
||
17 | 12 | Max Milbers | |
18 | 13 | Max Milbers | The first very important rule is, |
19 | 12 | Max Milbers | |
20 | 1 | Max Milbers | *"Stay at your task"* |
21 | |||
22 | 16 | Francesco Abeni | This means, when you find a bug somewhere while you are working on your task, don't just fix it. Look in the tracker who is responsible for the code, look in the svn history to see who did the last change or even better the changes which cause your bugs. When you don't find any person ask the projectleader (Max Milbers). Give the person some time to correct the code, and fix it only when you get an OK by the projectleader. |
23 | 1 | Max Milbers | |
24 | 12 | Max Milbers | This rule is very important for the teamwork and has several reasons. |
25 | 16 | Francesco Abeni | |
26 | It often happens that someone is changing something which is effecting the code in many areas. We already had the case that someone (lets call him A) changed the code. Another guy, B, was working on his own code, using code written by A. Due the changes the code of B didn't worked before and B started to "fix" the code of A, which just destroyed the work of A, because B thought in the old structure and A just invented a new system. |
||
27 | 15 | Max Milbers | Or another annoying and frustrating case is when B says to A, hey there is a bug in your code. A starts immediatly fixing it, but B fixed it also and A gets an conflicted SVN (because B already fixed and comitted it) and did his working for nothing or even worse (we had that also), gets an conflicted svn and has to fix the "fix" of B again, because only A really understood that part of code. |
28 | 1 | Max Milbers | |
29 | 12 | Max Milbers | So working in the svn together is quite easy even when we work on the same files, when everyone follows the rules: |
30 | - update your svn often |
||
31 | - stay at your task |
||
32 | 16 | Francesco Abeni | - don't fix bugs not related to your task without permission by the projectleader. |
33 | 12 | Max Milbers | |
34 | Note about svn: |
||
35 | 16 | Francesco Abeni | If you want to commit a new version, first do an update via SVN of it, then test it again and after that commit it. |
36 | 12 | Max Milbers | |
37 | h2. Requesting features. |
||
38 | |||
39 | 16 | Francesco Abeni | If you have an idea or special interest for VirtueMart, write it in the internal forums where we can discuss it and develop a plan. However, if you start developing something then finish it. Too often developers are very enthuastic and start a great, big, mega feature and end up with nothing useable. Discussion and planning in the forum should make it possible to work together. |
40 | 12 | Max Milbers | |
41 | Everyone can add features as many as he wants but must follow 3 rules |
||
42 | 16 | Francesco Abeni | 1. it must not slow down the page and/or can be disabled and is disabled as default |
43 | 12 | Max Milbers | 2. it must fit in the rest of the architecture |
44 | 3. it must be bugfree for the release date (Beta, RC, Final) |
||
45 | |||
46 | 17 | Max Milbers | https://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/ |
47 | 7 | Max Milbers | |
48 | 1 | Max Milbers | h2. Some general coding advices |
49 | 10 | Max Milbers | |
50 | Here a guide for [[Setting up a Development Environment]] |
||
51 | 7 | Max Milbers | Here are some general tips and tricks for php: [[general php hints]] |
52 | 14 | Max Milbers | Here is a guide for writing code [[Coding standards and hints for Virtuemart]] |
53 | Here is a guide for [[GUI standard]] |