Project

General

Profile

Developer guideline » History » Version 14

Max Milbers, 02/25/2011 04:48 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
- 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
10 1 Max Milbers
11 12 Max Milbers
and as last thing, think about eyecandies and design.
12 7 Max Milbers
13 12 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.
14 7 Max Milbers
15 1 Max Milbers
- Mistakes might happen, important is to learn from them
16
17
- It is better to do something wrong than to do nothing
18 12 Max Milbers
19
h2. Guidelines for teamwork
20 13 Max Milbers
21 12 Max Milbers
The first very important rule is, 
22 1 Max Milbers
23 13 Max Milbers
*"Stay at your task"*
24 12 Max Milbers
25
This means, when you find a bug somewhere while you are working on your task, dont 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 dont find any person ask the projectleader (Max Milbers). Give the person some time to correct the code, fix it only, when you get an OK by the projectleader.
26
27
This rule is very important for the teamwork and has several reasons.
28
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 guym, B, was working on his own code, using code written by A. Due the changes the code of B didnt 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.
29
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 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 understoods that part of code.
30
31
So working in the svn together is quite easy even when we work on the same files, when everyone follows the rules:
32
- update your svn often
33
- stay at your task
34
- dont fix bugs not related to your task without permission by the projectleader.
35
36
Note about svn:
37
If you want to committ a new version, first do an update via SVN of it, then test it again and after that committ it.
38
39
h2. Requesting features.
40
41
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 possible to work together
42
43
Everyone can add features as many as he wants but must follow 3 rules
44
1. it must not slow down the page and/or can be disabled and the standard is disabled
45
2. it must fit in the rest of the architecture
46
3. it must be bugfree for the release date (Beta, RC, Final)
47
48 7 Max Milbers
49
h2. Some general coding advices
50 1 Max Milbers
51 10 Max Milbers
In general we avoid the use of globals. Globals are hard to maintain and they are unsure variables. 
52
Here a guide for [[Setting up a Development Environment]]
53 7 Max Milbers
Here are some general tips and tricks for php: [[general php hints]]
54 14 Max Milbers
Here is a guide for writing code [[Coding standards and hints for Virtuemart]]
55
Here is a guide for [[GUI standard]]