|
|
Posted by Carl on 10/12/05 23:06
NC wrote:
> Nikolas Hagelstein wrote:
>
>>i spend a lot of time on thinking and researching about how to
>>make developing webapplications with php a more structured/systematic
>>thing.
>
>
> Why stop at development? Or, rather, why start in development?
> Structure and system should be first introduced in sales and
> implementation...
>
In not really sure that I understand what you are trying to argue here,
but I would argue that 'Sales' is not necessarily a factor that needs to
be considered in the context of this discussion, and implementation is
only one part of the development process. Structure and system _should_
be 'introduced' (at the minimum) well before implementation .
>
>>Anyway my current attitude is that fullfilling the following
>>needs would make application depvelopment via PHP a really
>>fast/professional/structured thing:
>>
>>- An MVC -architecture framework (e.g MOJAVI)
>>- template parser (for View part)
>>- severall helper toolkits/frameworks
>>(DB abstraction layer/Form validation etc.)
>>- disciplined/skilled Devloper ;)
>
>
> I respectfully disgree. No matter how professional your
> development is, your success will NOT be determined by the
> quality of development. Whether or not your product uses MVC
> (or another fashionable development technique) is of no
> consequence to the buyer. The buyer wants to see the relevant
> feature set (which is a design issue, ultimately rooted in
> marketing), reasonable cost of ownership (which a purely
> marketing issue), knowledgeable sales people and responsive
> implementation people (which are human resources issues).
Again, you lost me. My first response here would be to see my comment
above on 'Sales' and apply it to every mention of 'buyer' in this
paragraph.
Although you may /sometimes/ be correct in that 'success will NOT be
determined by the quality of development', you definition of success and
mine clearly differ. Proper design markedly increases _your_ ability to
work with, repair, modify and reuse code in the future, and these
abilities are propagated to the user, or 'buyer' in your terms. If the
end user happens to be a developer, or would like to have the software
modified, these attributes are invaluable, and often overlooked and
underestimated in marketing. I would say having these options makes a
project/product more successful.
Regarding your comment that there exists a design issue is "ultimately
rooted in marketing" has me perplexed. The issue with design is
implementing the feature set determined by marketing, and how this
implementation is done should be under the complete control of the
designers (i.e. NOT MARKETING!).
>
> On the development side, what you really need is a combination
> of coding AND DOCUMENTING guidelines with a code repository and
> a defect tracking system. Over time, this will ensure you have
> a large base of potentially reusable and reasonably bug-free code.
> Whether you want to introduce guidelines that require the use of
> MVC or, say, forbid the use of OOP altogether, is a matter of
> secondary importance...
>
>
>>Wouldn't it be nice to have something like the
>>"PHP professional webapplication development guidline" ?
>>containing:
>>- toolkits/frameworks
>>- techniques
>>- tutorials etc.
>
>
> I think it's called PEAR; it includes code repository (complete
> with dependency checks and defect tracking) and coding guidelines...
>
PEAR is indeed one possible answer to the OP's question, though I think
it is far from a complete solution. On an even more abstract level, we
could also say that the solution is PHP itself, or how about 'some
program written in some language that solves the problem'.
> Cheers,
> NC
>
Cheers,
Carl.
Navigation:
[Reply to this message]
|