Lập Trình Cơ Bản: 21 errors of a PHP-programmer. Part III

Description of seven last fatal errors. These errors are conceptual on their nature and cause errors described in the 1st and 2nd part of the article. They also include such errors as insufficient attention paid to the project in whole and to the program code as its part.

One of the main advantages of PHP is its disadvantage at the same time: PHP is very easy to learn. This attracts many people but in spite of its false easiness its rather difficult to learn right and effective usage of this language.

As a rule we deal with insufficient programming praxis. Inexperienced programmers face the necessity of complicated web-applications creation. Thus the mistakes are frequently done which an experienced programmer could evade such as unjustified usage of printf() function or wrong usage of PHP semantics.

In this series including three articles the most typical from our point of view errors are presented. These errors may be classified on some categories from non-critic to the fatal ones. Together with these errors analysis the ways of their evading are described and also some little tricks which have been collected for many years of programming praxis are presented.

Audience of the article

This series of articles is meant for those PHP-programmers who want to evade the mostly common errors in the code writing. The reader is at least supposed to know general PHP syntax; some experience of practical language usage is also very desirable.

Introduction

Part I: 7 childish errors are described (21-15 backwards according to the grade of their importance in our classification). Such errors dont cause serious problems but they reduce effect of programs work and are also expressed in a bulky difficult to read code which is also difficult to change.

Part II: The next 7 error (14-8) which are classified as serious. They lead to the considerable reduction of codes completion speed and scripts safety reduction; the code becomes even more complicated.

Part III: Description of the last seven fatal errors. These errors are conceptual on their nature and cause errors described in the 1st and 2nd part of the article. They include such errors as insufficient attention paid to the project as a whole and to the programs code as their part.

7. Programming by means of method cut-paste: wrong approach

Some beginners have a habit of copying another code, for example, scripts for addresses verification, mail sending and form processors. Such activities result into mixture of operators which does what it has to do although not in a proper way.

And if the code functions under optimal conditions, it will obligatory break down during real testing. At this holes patching never makes your code

extensible: the program will look like a set of scraps which were fastened together. Ask an experienced programmer to change something in such script and he is sure to prefer writing one of his own. Unreadable code is an inextensible code.
safe: you insert another persons code into your project without knowing what exactly this code does. Think about it. And what if this code contains false system call which destroys all the files form your fixed disk? Besides that the same code cannot have the same protection and safety for different systems. And finally youre simply copying someone elses errors.
fast: if you compose code from the parts of different scripts, you shouldnt expect fast work from it. Thus in this case logical development of the script is simply absent; and its a common fact that scripts speed is based on its logic.

Correct approach: examine and then copy

Before you copy code of someone else examine it carefully. Analyze what has been done and in what way. And only if this code is easy to read, fits into your programs logic and doesnt contain any errors, only in this case it can have pretensions of being copied. If these rules are observed, the copied part can be integrated into the project rapidly and smoothly.

Libraries are what you need

Use libraries of PHP-functions only from reliable sources such as, for example, PEAR and PHP Classes Repository. Optional functionality which API from these libraries offers to you will benefit your project. So if youve found a ready-made library of functions which are necessary to you (from reliable source), its usage is always welcomed.

6. Absence of technical directives in the project

Once in the very beginning of my career I worked over one serious project (on PERL) in team with three other programmers. I was young (and I wasnt a supervisor of a project), we had no technical directions. Each of us took his part of the project and worked over it on his own. When we started assembling our project our parts were quite different on their styles.

For example, one of my colleagues used BiCapitalization in the variables names. I used underscore ("_"). The supervisor of the project chose the most original style and mixed both methods according to his mood (this fact caused conflicts in the names space; everyone knows how unpleasant it is for a developer).

We needed 20 hours optional time; although nothing like that would have happened if we had set up clear technical directives for our project.

Technical directives describe structure and external presentation of the source of the project, determine methods and realization strategics of the final product.

For development of any project you have to set up technical directives and follow them. In the technical directives various working aspects should be determined: general items, for example, division of the source (its file structure) and more concrete ones, for example, rules of variables naming (suffixes and prefixes, global, in full).

Technical directives are the set of consent which should be observed independently from the personal preferences of programmers. Technical directives fix all the decisions concerning all questionable moments like these:

which variables should be declared as global and how they will be differentiated from the local variables;
structure of documents saving, i.e. rules in which directory this or that file should be placed: src or lib.;
style and contents of comments;
documentation rules;
strings width.

Technical directives should be arranged into a document; each projects participant should have its copy. After the project ends this document must be saved for the further addressings to the source.

Example of technical directives project

For better understanding well try to set a sample of technical directives: without details, the main items only. Of course, all the necessary elements will be presented but they will be rather schematically: in reality technical directives can easily have 10-40-pages length. Its worth to mention that you dont need to write new technical directives for each new project: its enough to have a ready-made sample and change it if necessary.

Technical directives for presentation of the project DesignMultimedia.com

So lets give an example of the external presentation of the project. Having developed a document like this you may concentrate on the realization of the project only and dont worry about incoherence of sources, naming conflicts or sites structure if you develop your own site.

Introduction

This part determines following moments:

file structure
documentation of sources
comments: style, meanings, definitions
directives concerning assembling of the project
rules of variables naming

File structure (on the example of DesignMultimedia.com)

Explanations to the structure:

Running titles

Each page of the initial text of the project contains following heading:

For example, all c. and h. files within PHP4 project had the following standard heading:

/*
+-----------------------------------------------------------------------+
| PHP version 4.0                                                        |
+-----------------------------------------------------------------------+
| Copyright (c) 1997, 1998, 1999, 2000 The PHP Group                    |
+-----------------------------------------------------------------------+
| the given file with the source gets under action of PHP license |
| for version 2.02 which copy is saved in the given program package in file  |
| LICENSE; the given license is also available on the address in WWW   |
| http://www.php.net/license/2_02.txt.  |
| If you havent got the PHP license copy and don't have any possibility |
| to get it through WWW we beg you to inform us on the address |
| license@php.net and the license will be immediately sent to you. |
+-----------------------------------------------------------------------+
|\Authors: Sterling Hughes <sterling@php.net>                            |
+-----------------------------------------------------------------------+
*/

And the lower running title:

<Here you place your standard lower running title; in the project PHP4 in all files .c and .h you can see following :>;

/*
* Local variables:
* tabulation width : 4
* main indent C: 4
* Tabulation:
*/

And comments if necessary.

<Here explanations about the contents of upper and lower running titles are given; perhaps the reasons for their presence are explained (in depends on the running titles contents).>;

Documentation

In this part codes documentation style in the application is defined: if itll be arranged in the javadoc form or XML Docbook

Comments style

Here the comments style together with explanation of abbreviations and some phrases is described

Rules of projects assembling

Here the rules in form of bans or directives are given, for example: Dont save different classes within one file or Save each class within a single file

Naming of variables

Here you can write something like this :

By naming of the variables in the given project the following rules are to be observed:

[1] In the names of the classes bicapitalization is used.

[2] Functions names are written with lower-case letters, for the separation of the words underscore ("_") is used.

[3] Other more concrete rules.

5. Absence of the expert judgement about the program

The idea to add this item visited me during the similar testing which I was asked to do by my friend. Having examined his code I was able to reduce the variables quantity on one third (that resulted into 400 per cent increase of data base addressing speed), quantity of strings in the program on about one half and beside that make many improvements with general result 1000 per cent speed increase (that means ten times faster).

What is the moral? The moral is that quality, speed and safety of your code will incredibly increase in case you always have another available experienced programmer who will examine your code. Other person will pay attention to all the errors about which you even didnt know and find simpler ways for solving this or that task. Beside that its easier for him to find such places of your code which make PHP work slower or which can be potential holes.

One of the reasons for the incredible success of PHP project which is a language with uncovered sources is the fact that many people have seen the code. Thousands of people tested PHP for free against the presence of errors, potential fails, incompatibility, working speed etc. Thus by the appearance of a new PHP version minimum 2-3 very experienced programmers have looked through the code.

As an ideal all the projects of medium/large scope should be looked through by at least two guest programmers. As in any other kind of art a new look is always welcomed. But people are mostly satisfied with one tester.

Person who is able to give rapid judgement about the work done and introduce constructive motions about the codes contents and realization of a project as a whole is supposed to be an experienced expert.

Often its useful to set up a short questionnaire for the person who looks through the code. Here are some possible questions:

What is the purpose of code XXX?
How does file XXX fit into the rest of the project?
What is the algorithm for the errors neutralization?
Can we chase actions of an average user of the given program?
Where can a program user be mistaken?

4. Patching up a project

You may have written an application and had an idea that some moments are worth rewriting. To patch up means to write patches instead of examining the reason of errors appearance and its removal.

If youve done such mistake and wrote patches your code wont work properly which is caused by the compromise of speed and safety.

Indexes for the projects imperfections

Of course, by the initial projecting of an application you suppose that your thoughts are the most correct ones. And you can understand that something goes wrong only in the last moment when the application (and its parts as well) is nearly written up to the end. There are two indexes which testify of a wrong projects plan:

Very frequent codes reanimation: program breaks down constantly and you find different methods to force it to work. But this doesnt fit into the initial plan of your project. On the other hand although it isnt the best way out in the given situation, it is the best salvation you can find within the plan youve already set up.
Very complicated realization. Complicated operations are done for salvation of simple tasks. In the example given below cycle for is used for the output of a string:

<?php $GeorgeBush = "If you examine market tendencies, I think, youll mention that the larger import part comes into the USA from abroad "; for ($idx = 0; $idx < strlen($GeorgeBush); $idx++) { print $GeorgeBush[$idx]; } ?>

This code is written well; it passes through the line in cycle and puts out the famous phrase of George Bush correctly. The syntax is correct as well as nesting. And nevertheless we could get the same result by the simple output of the whole string (print()).

Improvement of programs drawbacks

When you realize that the program has some drawbacks or that it isnt simply realized in the best way, you undertake proper steps for the codes optimization. There can be plenty of variants this way: you can leave everything as it is, you may change some modules of the program or rewrite the whole project.

In the most cases it can be useful to have a judgement of an independent expert: having looked through and examined the code he will be able to judge about scope of imperfections properly.

Lets examine three categories of errors:

Little localized mistakes: sometimes errors in your program arent so critical for its functioning and its correction doesnt compensate money and time spent on it.

Ways of correction: in this case its necessary to document somehow the fact of error itself. When you decide to change or renew your application youll correct this error at once. As an example for the error of such class can serve wrong data organization in the separate part of application (simple massive in the place where it would be more logical to use an associative one; riding-crop instead of more suitable tree).
Considerable but localized errors: sometimes it happens so that you really have to rewrite some part of an application. For example, if you write your operation system, there can be plenty of errors in the Windows dispatcher and at the same time the rest of the code can be in order.

Ways of correction: all you need is to change project of Windows dispatcher namely (not the whole operation system). It seems to be the mostly widespread case in the programming practice: single modules contain errors but the general project structure is correct.
Considerable widespread errors: and finally the emergency case when errors are contained in the realization of the projects infrastructure itself.

Ways of correction: if the applications infrastructure itself was projected wrong, usually we need reorganization on the level of different program modules interaction. This is, of course, the most laborious work which takes a lot of time and it is rarely done especially if we speak about projects on the last stages of their realization. As an example of such errors we can demonstrate usage of simple files for saving the whole amount of information within such huge search system as Yahoo.

3. Excluding of ultimate user from the development process

Imagine such situation: youve got a task to develop a corporate application special for your company. Youve spent hours on search and documentation of tone of documents, defined costs of the project, set up tasks and completed them. In three months you bring the ready-made project only to hear in response:

It isnt what we wanted.

Our demands changed.

Yes but

Eh, what program are you talking about? (Your initial customer is already fired from the company!!!!).

Has something like that ever happened to you?

A user is always to have the last word in the judgement about your application. Its namely he who will use your application (and, of course, he will keep trying to use it wrong). Many programmers write such things which are masterpieces on their own but at the same time dont correspond with users demands. And it often occurs because one or some misunderstandings.

And these misunderstandings appear when you ignore the ultimate user during the development process. Dont forget about your future users when creating an application. Always keep in your mind WHAT users want get from you and in what way the program should achieve the set aims. Its principally important to have connection with users and pay your attention to following procedures:

permanent feedback
creation of models
beta-testing

Permanent feedback

Benjamin Franklin wrote in his Poor Richards anthology: One stitch in time is worth of nine. We can apply the same rule for the applications development. If you really want to finish your project as soon as possible, its very important to have connection with user and be interested in his opinion about your program. What do they like about it? What do they dislike? How can you improve your application?

Creation of models

Creation of the program models is a whole system which includes many tests and communication with users and acting during the whole period of applications development. However doing tests on models takes much time. And its worth to start it from definition of users testers group.

Check application against conformity with demands but also pay your attention to the direct responses of users themselves. Besides that many programmers test an application only after having written and assembled it. They make a mistake cause this may fail the whole project: the differences between what a user needs and what youve done are too big. Besides that users often understand what they really need only having some real sample before their eyes. Users demands to the project are constantly changing during the development (although many programmers would prefer quite the opposite).

There is a method for evading this headache: divide the whole application development process into some stages. By ending of each stage think over the following:

Does the work youve done on the given stage bring some useful for a user result?
Are there any things left which user would like to see in your application but which still arent presented in the project?
Will the optional functionality which has been added on the given stage be set in action?
What is the net profit in the functionality of your application?
Has your work improved or worsened the application?
How to divide work into stages?

Usually good practice is considered such limitation of stages when some considerable portion of users interface is completed.

As for me, I consider the first stage finished when the first variant of common applications interface is ready. This occurs when designers define the backbone of the site. The next test of users interface can be done when the mostly general demonstrational model of functionality of your application will be ready.

Then tests are done after the finishing each module or multiplier. The example of such module we may call users dispatcher in application or search system of a site. By testing I gather my own testers group (I invite others who are more competent in the subjects tested at the moment) and offer them the same questionnaire which I described before. This enables you to see general result of your work on the given stage. You may ask additional questions or hold to the initial list.

Beta-testing

This is the mostly widespread testing form which looks a bit like modeling but usually beta-testing is done when the project is on the last stage of its development. The project is sent to a certain group of beta-users; they test an application and sent their references, comments and error messages to the developer. Beta-testing isnt as interactive as modeling and its worth to do it as early as you can. However beta-testing is simply necessary before you release your application.

2. Absence of a plan

Nowadays many projects are written according to the principle the main is starting; further it goes on its own. For example, I wrote one of my first projects basing on the 40 minutes long telephone conversation. And although everything functioned the risk of falling down was big enough. Of course, if I had thought over and planned everything before starting to code, the risk of fails appearance would have been considerably less.

For example, abstraction in the project was nearly equal to zero. I.e. if customer had had a wish to use MySQL instead of MSSQL, we would have to rewrite the whole project. Besides that the safety system wasnt done properly. All data were saved in cookie. There were some other defects but they were too inconsiderable to be described in details.

In his work "The Mythical Man Month" which was devoted to the software development process Fred Brooks described optimal plan for work over an application that looks like that:

1/3 Projecting: you develop a functioning conception. What do different application modules (or parts of these modules) include? How do they interact? How should the whole application function? Answers on these questions build a base for the whole system development.
1/6 Coding: thats the thing that all of us adore to do. We realize conception into life.
1/4 Testing of separate modules and common testing on the early development stage. By creation of big systems such moment comes: the application isnt ready yet but its already developed up to the stage when you may test its basic functionality.
1/4 Testing of the whole system: it is the last stage when we already deal with the ready-made application; now it should be checked and rechecked in order to have as few bugs as possible left.

But nowadays we are already happy if we can spend 1/6 of all the time on the first part (projecting). In the most cases programmers are eager to print code without having a clear idea of what they should write and without considered task estimation and, of course, without any ready-made ways of its solution. Such behavior can be compared with attempts to write a term paper without setting up a plan.

Coding can be a simple statement of what youve already have projected, no more than this. Many programmers come to such grade when they write all the application (or the most difficult parts of it) in pseudocode and only after it code the project in the real language such as, for example, PHP.

Notice: projecting of appearance, work and thinking of your application is also known as informational architecture.

Stages of projects development

A lot can be said concerning this theme. But its enough to enumerate: debugging, compiling flow blocks, modeling, project management and terms establishment.

But we will content ourselves with a minimal set of general recommendations.

So an ideal projects plan includes:

stage of demands learning
stage of development
stage of testing

Stage of demands learning

Complete analysis of demands made to the program is the first step in planning of an application; you define what exactly you need to do. You describe detailed and precisely what the program will do and how it will work. Its one of the principal moments in development.

Determination of users demands

So how can you clear up what exactly a customer expects from your application? You should play a role of consultant occupied with determination of customers needs and in particular try to analyze what this customer presents himself. For example, you should be interested in following:

What are they occupied with?
What makes their product better than the others (or unique)?
In what way would they like to present themselves to the audience?
Which features/properties of their site will help them to achieve their market?

The last question enumerated will be able to help you with the projects extension. Can you offer some optional functionality and thus make their site better? If you can, your customer will be extremely happy and youll have the opportunity to deal with a big project (and it also costs more).

Methods of research can vary from questionnaires to the private conversations with people occupying key positions in the company. But whatever you choose its always very important to ask all the questions enumerated in this chapter.

Determination of technological demands

On the given stage you are to determine which technologies your application will use. The main question: will we be able to satisfy customers demands; do we dispose of technical ability for this? At this you should take into account language in which the application is realized, operating system of a platform, servers speed and speed of connection with it and many other aspects.

Stage of development

So the specifications are ready. On the given stage you should decide how your application will be realized, what and when will occur in it. You may even make some rough drafts in pseudocode if some parts seem too complicated to you. In other words youll need to:

model an application
illustrate it
make some rough drafts in pseudocode

To model

Before you start coding you should think over the way in which different parts of your application will communicate with each other.

As an example well examine a script with message sending form. Well describe all possible actions which user can make for filling in such a form. On the highest applications abstraction level only two actions are possible: a user either has sent his data or hasnt sent them.

If the data arent sent, you need to send a page with an empty form to the user. In other case its necessary to make (to repeat) one of the following actions:

if the data is correct (i.e. correspond with correct data criteria), you need to send the message to the addressee and a gratitude page to the user.
otherwise we send an error message with indication of what was wrong and offer an opportunity to correct it.

To illustrate

Below a very simple diagram illustrating applications work is presented. The diagram is made in Microsoft Visio(r) and suits ideally for the simple message sending application.

However when we speak about more complicated projects its always useful to have special tool for diagram building available. Here are three of them enjoying the most success: Dia, Visio and UML.

Pseudocode

Pseudocode (i.e. such code which only describes an applications work and isnt correlated with any of the languages) is a rather common practice among developers. Usually it is used when some confusing situations are faced or when the general overview of applications work isnt clear. I also think that pseudocode is rather useful by the applications interfaces determination and especially when interfaces I have created are used by other developers. Pseudocode helps to find the simplest but at the same time sufficient methods of treating this or that application part.

To give an example well return to our script for messages sending:

if (formSubmitted) { valid_name(name) or error() and output_form(); valid_email(email) or error() and output_form(); valid_message(message) or error() and output_form(); message = name & email; send_mail(email, message); print "Thank you for your feedback"; } else { print "Send us feedback"; formelement(name); formelement(email); formelement(message); }

This code determines the main scripts structure and demonstrates all the necessary elements. Of course, code isnt a working PHP-script (although it could take this place). The mission of pseudocode is to set tasks and, perhaps, to base them on theory. The grade of pseudocodes abstraction depends on you only. As for me, I incline to less abstract code. It depends on that how sure you feel when programming.

And finally when youve already planned your application you can start coding: all the steps that should be done are already familiar to you; you also know what you should get as a result.

Stage of testing

One of the most important stages in the applications development which nevertheless is not very often done is (final) testing. Often under pressure of a manager or due to the time shortage the testing phase is reduced to minimum or omitted at all. And the application is considered to be conventionally fit.

Frankly speaking, programmers hate testing. This, perhaps, is the most annoying and irritating occupation connected with programming. Testing results into hours and days of unknown bugs hunting, debugging, checking of all the possible combinations and situations and all this in order to make sure that the program functions properly in the most cases. And nevertheless you are NOT GOING to get a code without any bugs! Something is sure to slip away from your attention. And things which (you are sure!) shouldnt happen occur at any case.

Regression tests

People are seldom content themselves with one applications version: most of them are in perpetual endless renewal. Make sure that adding new functions doesnt distort work of the old ones: functions on which users depend to a certain extent. To do this you should know about such notion as regression tests cycle. So are called tests which prove that functionality of the present version wont be upset in the following release. Each new version of PHP-project itself passes series of regression tests and thus by adding some innovations the previous functionality is saved completely. Thus we not only achieve backward compatibility of all PHP-versions (i.e. new abilities added but the old scripts keep working correctly) but also confirm the fact that innovations dont upset work of other functions (and even dont change their behavior).

Volume tests

Congratulations, your application works perfectly with one user: everything seems to go right and happen at a huge speed. And what happens if 20 users will work with the application simultaneously? And 30 users? And what about 100? How fast is your project working now? Does it show up strange errors?

Independent from the tests you do make sure that your project works correctly at big loadings and changing conditions.

But this doesnt mean that users should do all testing work instead of you (when you simply lay out everything on the site and wait for references and letters about the errors found, you know). Make beta-testing as it is described in the previous chapter. Besides that there are special service programs which emulate big users flow. The first thing to memorize is AB from Apache. AB or Apache Benchmark makes adjusted quantity of requests to the page and shows up quantity of successful requests, quantity of requests failed, average speed and so on.

We recommend you insistently to test your web-projects by means of AB (of course, if youve made a decision to use Apache server). This way youll be able to find and optimize pages which eat up memory or load to long. (Also think about purchasing of a wonderful caching utility from Zend- The Zend Cache).

1. Fouled-up terms

Error number one for all time and nowadays which is haunting programmers is complete inability to calculate their time inputs.

Dont be afraid too much because we are all optimists. Its quite natural to suppose that realization of a project will take exactly that period of time which it has to. And no bugs are taken into account. Even more than that, we often have no idea that we might have any problems with realization of something.

So lets pull ourselves together, suppress this instinct and calculate time inputs otherwise. From my personal practice: when I take up a new project I take into account all the factors I can memorize, estimate period of time I need for each of them, sum all this up. Then I double the result I got. Isnt it accurate? I wouldnt say so: customers are pleased when you bring a ready-made project before the indicated term (and conversely: if you are late, they are rather displeased).

Such reassurance method of time inputs indication helps me to work properly over a project and keep within terms indicated by me. But here, of course, everything depends on the accuracy of the original calculations.

Every programmer underestimates (far more seldom overestimates) time which he needs for a projects development. At this each of them has his own coefficient of potential errors admission. For me its 2, for someone t can be 1.5 and for someone else even 3. The whole trick consists in finding your personal coefficient and amending your calculations.

Underestimation of time inputs for the projects development can result into following consequences (which are too familiar to me):

You sacrifice all your free time to the project. Youll spend day and night working over it and have no time to rest (I dont intend to say developing is bad but programming non-stop is impossible to bear).
You will be in hurry. This means you will carry about presenting the ready-made project in time instead of thinking about its readability, safety and working speed.
Hurrying up you may leave out such important stages as testing of a code or checkout. The customer may dislike it and youll get some extra-work.
You may need outside help. This costs some money and isnt always useful (according to the Brookss law, especially by development of capital projects).

Always leave enough time for prolonged checkout (the same period as you leave for the whole coding stage and even more) and no less than one third of all the time for planning. These two stages determine the whole projects development.

SterlingWonderfulToyland.com: Example

Lets examine as an example one simple project: site SterlingWonderfulToyland.com. This is a usual commercial internet-site. Its purpose is to sell via internet game devices and videogames with discounts; the items quantity is limited.

As a supporter of old and checked sales methods the sites owner John Giuseppe wants to invite customers to his storehouse and choose goods themselves. Thus the whole site can be logically divided into two parts:

the order system itself
html-part of the site which invites customers to the storehouse and design of this storehouse itself.

By planning I would make up two separate estimates for those parts. Then I would sum up these two terms, add a week for assembling two parts and presented the final term to the customer (for the whole site without any division).

Html-part

For simple strategic part of the site I would taken as base the time I need to make up one page in some editor, for example, in Macromedia Dreamweaver. And as dynamic elements are absent in this part for determination of general time input you may simply multiply time you need to make up one page by the quantity of pages (under condition that pages design is already developed). Then I would double the result I got (as my personal coefficient is 2). Generally, this part doesnt need really detailed planning (think over: a designer submits you with schedule of that how everything should look like, your task is to make up pages in Dreamweaver).

Notice: add one more interval which is equal to about 1/3 of all time, youll use it for assembling of the project. So if youve planned development of script for credit cards checking in 9 days, add another 2-3 days.

Orders system

Distribution of regalement for dynamical part is rather difficult thing. The thing that can help you here is simple division of task into some simple components (as, for example, operations with credit cards, instant order at one click, products catalogue, management system of this catalogue and so on) and calculation without any coefficient. Then I sum up and multiply by my personal coefficient of errors admitted. Only after that I calculate one third of time for the whole development and add it. All the optional time I spend on checkout and testing in order to provide a customer with a correctly working project.

Notice: add another one third of the time for planning as in simple html-part.

How to present such terms to the customer

The fact youve managed to calculate the terms for project realization correctly doesnt mean that the customer accepts them as you do. Sometimes having indicated too long terms you simply loose your customer. Your competitors will set more attractive terms only to get this order and they simply wont hold within these limits. So what should you do to please the customer and at the same time be honest and hold within indicated terms?

Here the moment comes when you have to present your services and terms to the customer in a proper way Which terms can you offer? What makes your terms real and why exactly this term is indicated instead of any other one? Often imagined conversation with the customer helps: imagine yourself on his place and think what you could expect from the potential employee.

Here are some of the aspects which seemed the most important to me:

Make high-quality work. Others can work a bit faster than you but your advantage is that you make everything properly and correctly and this finally will save a lot of customers time and money (this argument is especially considerable if you are hourly paid).
Keep to the terms. You set terms and intend to keep to them. Others con set terms which are more attractive but they are not going to keep to them.
Give references. Your previous projects illustrate your professional skills. Collect references and letters of recommendation from customers who were pleased with your work in order to present them to the potential chief/ customer.
Be careful! Check orthography and grammar in all your calculations. Add schedules and graphics, describe all you plan to do and time you need for each task indicated carefully and clearly.
Offer some variants. Dont content yourself with simple declaration of time which some task is considered to take. Give some possible variants. How will the events develop according to optimistic scenery? And according to the pessimistic one?
Indicate the shortest possible terms. Large terms have more chances for not being kept to.

If the terms indicated by you are too short

If a nuisance like this has nevertheless happened to you and you are going to be late, there are still some possible variants of actions (which arent mentioned too often in such situations):

Maintain contacts! There can be nothing more important than permanent contacts between programmer and customer. All the time inform the customer about what you are doing about the project. If you need to prolong your terms, itll be much easier to do than in case there were no news from you at all during that period of time.
Demonstrate the ready-made part of a site to the chief/customer. Demonstration of the work youve already done often makes negotiations concerning optional time easier. Show youre working over the project.
Find a switchman. Take the whole responsibility for being late yourself but dont forget to indicate different external factors which prevented you from making the order in time.
Cut the angles. Thats disgusting and annoying but if you really dont have enough time youll have to cut some angles and present to the customer release version of the product with detailed list of all the bugs. Then during the testing or later youll return to them and correct.
WYSIWYG. Working over web-projects I prefer to write html-code with because I dont trust graphic html-coders too much. However if your project is endangered, its worth to treat such variant.

Summary

PROGRAMMING BY MEANS OF METHOD CUT-PASTE: WRONG APPROACH.

Usually copying of someone elses code isnt considered to be a very good idea. Itll be great to examine techniques and algorithms of another code and integrate them into your project if necessary. Or you can use ready-made libraries. But you shouldnt simply copy another code.

ABSENCE OF TECHNICAL DIRECTIVES IN THE PROJECT

Making up detailed directives is necessary by developing every project. Directives let you lead your project organized in the style and documentation which is common for everyone and thus let you evade many probable misunderstandings in the future.

ABSENCE OF EXPERT APPRECIATION OF THE PROGRAM.

Someone is obligatory to look through your code. New look on the project will find such things as non-optimized SQL-requests, wrong syntax application, too complicated solutions, holes and other drawbacks.

HOLES PATCHING

Serious drawbacks cannot be corrected with patches. If you see that something has been projected wrong (or in a way that isnt proper enough), in the most cases its better to reproject and rewrite this module.

EXCLUDING OF AN END-USER FROM THE DEVELOPMENT PROCESS.

Never do this. These are namely users who will judge about appropriateness of your application when everything will be said and done. Attraction of users to the applications development process itself will let you evade many probable misunderstandings.

ABSENCE OF A PLAN.

Forget about principle the main is to start; further it goes on its own. Find time for detailed planning. Each projects plan should include following stages: examining of demands, development and testing.

FOULED-UP TERMS.

Find enough time for the projects realization! Aiming at keeping to the unreal terms youll increase your chances for making previous 20 errors. Dont let yourself be wasted in time.

21 errors of a PHP-programmer translate to Việt Nam

Lập Trình Cơ Bản

Thursday, 12 April 2012

21 errors of a PHP-programmer. Part III