Standaarden voor de ontwikkelaar ?

[marcussmit]

Hallo,

Hebben jullie standaarden vastgelegd waar (externe) ontwikkelaars aan moeten voldoen ? Wij zijn nu een aantal projecten aan het uitbesteden en ik probeer wat vast te leggen aan standaarden. Ik worstel vooral nog met hoe stellig, hoe specifiek en hoe uitleggend we gaan vastleggen. (dus eigenlijk alles ) Voorbeeldje:

Website
- Always deliver a robots.txt in the webroot. File may be 0-byte.
- Always deliver a favicon.ico in the webroot. File may be 0-byte.
- Never use hardcoded hostnames in the code of the site, except when this is required for the functionality. If for any reason hostnames are required: comment
- When php: always use closing php-tags (the "?>"). Never close the file with cosmetic newlines (the "\n"). Some php scripts are executed from the commandline and closing newlines result in more output then required.

... en zo nog een paar onderdelen

Marcus

[Mastje]

Misschien is dit boek handig: Prentice Hall Clean Code A Handbook of Agile Software Craftsmanship

Kan zo eigenlijk niet 1, 2, 3 tips noemen helaas.

[marcussmit]

Hi,

Dank voor je reactie. Het gaat me niet zo zeer om eigen standaarden om te leren, daar ben ik immers zelf bij Waar het mij om gaat is wat ik aan ontwikkelaars kan meegeven als hoe ik het wil.. Iedere ontwikkelaar zal zijn eigen standaarden hebben die niet perse de onze hoeven te zijn

Marcus

[Vic D'Elfant]

Ik heb onze coding guidelines vastgelegd in een PDFje dat al eigenlijk jaren ongewijzigd is gebleven. Probleem is en blijft wel dat je ergens een grens moet trekken, en dan zul je nét zien dat een developer dat ene ding pakt dat buiten die grens viel. Simpele dingen als "voer nooit een SQL-query in een loop uit" moet je eigenlijk ook opnemen, maar als je daar aan begint krijg je een behoorlijk boekwerk omdat sommige dingen in zekere zin ook onder de noemer "common sense" gaan. Wat doe je bijvoorbeeld met de namen van een tabel in de database? En indexes? Wanneer is een index toegestaan? Niet direct gerelateerd aan programmeerwerk, maar je komt het wel tegen in het "geknutsel" van een developer.

Wat wel bijzonder effectief bleek is het periodiek (iedere ochtend) runnen van PHP_CodeSniffer op de trunks. Als je een mix maakt van documentatie en regels in CodeSniffer kom je een heel eind. In ons geval krijg je (in combinatie met svn blame) een nette HTML-mail per repository met je "to do" lijstje.

P.S.
M.b.t. die hostnames: ik zou een constante aanraden (HTTP_DOMAIN en HTTPS_DOMAIN). Scheelt je een hoop werk met wisselen tussen development, staging en productieomgevingen.

[marcussmit]

Hi,

Dank voor je reactie.

Dingen als looped queries kun je vrij snel als common sense afvangen inderdaad. Als dat voorkomt zal je applicatie waarschijnlijk niet de vereiste functionaliteit bieden en kan de ontwikkelaar nooit af zijn en dus ook niet opgeleverd worden.

Is je pdf'je iets dat je kunt delen ?

Om even dieper in te gaan op het voorbeeld van de hostnames: dat zou ik over willen laten aan de ontwikkelaar. Die moet zorgen dat de functionaliteit er is (i.e. geen hardcoded hostnames) en of deze dat oplost met een variabele, of een inifile ofom mijn part $_SERVER['SERVER_NAME'] maakt mij dan weer niet uit Geeft wel weer goed aan dat zelfs zoiets simpels al aanleiding voor discussie kan geven.

Nog een voorbeeldje:

Database:
- MySQL tables are always saved as InnoDB. When for any reason another storage engine is used, this is required to be commented on in the delivery notes.
- When a maximum of 1 record is to be deleted from any table, add "LIMIT 1" to the query. Better safe than sorry!
- Always use 25 or 255 or 2500 for varchar length
- Id-fields are always non-signed integer. Always use auto_increment.
- When changes to the database schema are required, the developer will include a .sql file with all changes in the deliverynotes. The reason for any schema change is discussed in the deliverynotes.

Marcus

[Vic D'Elfant]

Is je pdf'je iets dat je kunt delen ?

Zeker: http://vicdelfant.coronis.nl/etc/php...guidelines.pdf. Ik zie wel dat het PDFje in principe is doorontwikkeld in onze interne wiki, dus het is niet helemaal actueel meer.

[SebastiaanStok]

Meestal adviseer ik dit artikel.

http://www.pfz.nl/wiki/overzichtelijk-sql/
http://www.pfz.nl/wiki/overzichtelijk-programmeren/

Richtlijnen die ik intern gebruik zijn veel uitgebreider, maar nog niet helemaal klaar.
De handleiding van Vic kan ik mooi gebruiken voor verdere inspiratie

[systemdeveloper]

Zeker: http://vicdelfant.coronis.nl/etc/php...guidelines.pdf. Ik zie wel dat het PDFje in principe is doorontwikkeld in onze interne wiki, dus het is niet helemaal actueel meer.

"Het algehele idee achter de richtlijnen in dit hoofdstuk is dat de leesbaarheid niet ten koste van luiheid van de programmeur moet gaan".

Volledig mee eens.... NIETS moet ten koste van de luiheid van een programmeur gaan

[Vic D'Elfant]

Mooie zinsopbouw ja, haha. Die zal ik maar even aanpassen...

[systemdeveloper]

Mooie zinsopbouw ja, haha. Die zal ik maar even aanpassen...

Mwoah, zit wel een kern van waarheid in natuurlijk. Luiheid is wel een vereiste voor een goede programmeur

[Vic D'Elfant]

Zo diep had ik nog niet erover nagedacht ja... maar wat je zegt klopt als een bus

[baahmi]

Naast wat richtlijnen die automatische gecontroleerd kunnen worden (stijl, complexiteit, etc) is code reviewen 1 van de belangrijkste onderdelen in een ontwikkeltraject. Simpele commit mails uit bv Subversion naar je mailbox is al meer dan voldoende om tijdig te corrigeren wanneer dat nodig is (en ook nog eens te leren van de verassende oplossingen die mensen soms bedenken).