Главная задача почти любого исполнителя (особенно хорошего коммерсанта) - поменьше поработать за ваши деньги. Поэтому:
1. Задача менеджера по веб-разработке уговорить вас на наименее трудозатратные и самые типовые программные решения (CMS и фреймворки) и типовой функционал. Минимум индивидуального подхода к вашим потребностям и вашей специфике. Все сложно-индивидуальное, что может отделить вас от конкурентов - в отказ.
2. Индивидуальная часть по программированию и верстке будет сделана максимально быстро и неаккуратно. В большинстве случаев никто не будет думать о скорости загрузки сайта, удобстве поддержки и развития программной части, надежности и безопасности, полноценном тестировании на разном оборудовании.
3. В SEO услуги попытаются свести к наиболее простым и шаблонным. В худшем случае - только генерировать отчет.
Вот что пишет о программной разработке тим-лидер одной из веб-студий. В данном примере он рассматривает отношение в студии к качеству программного кода, выявляемого на финальном этапе Code Review
----------------------------
«5. Когда это выгодно?
Code Review — ..., это выгодно на проектах, в которых планируется длительная поддержка. Аккуратный код минимизирует количество затрат на дальнейшую отладку и ковыряние в нем.
(Т.е. без передачи проекта на долгосрочную поддержку студии вы получите сложный, тяжелый код, который будет трудоемко обслуживать и развивать вашему следующему программисту. Несколько замен программистов работающих с кодом - и любые правки будут вам очень дорого стоить.)
6. Что делать после Code Review?
Это тоже очень щепетильный и непростой вопрос. Допустим, вы закончили проект, все работает, но Code Review показал, что нужно, скажем, еще неделю на полировку кода.
Как быть? Заказчик за это дополнительно не платит, времени обычно лишнего нет.
Приходится идти на компромисс, с надеждой на то, что в следующий раз разработчики не допустят ляпов, который были найдены сейчас. Обычно мы исправляем только на часть задач из Code Review, а остальные — принимаем к сведенью.
7. Что позволяет выловить Code Review?
С высокой долей вероятности можно отловить утечки памяти и проблемы в безопасности, а так же потенциальные проблемы в производительности. Со стопроцентной вероятностью вылавливаются косяки форматирования (соответственно, вы можете добиться однородности стиля кодирования у всей вашей команды). Хорошо вылавливаются «велосипеды» и дублирование кода, излишняя усложненность и избыточные конструкции. Довольно неплохо вылавливаются мелкие ошибки, опечатки в сообщениях.
Ошибки в логике работы или формулах выловить тяжело, увы.
(итак вы получили сайт: - с потенциалом тормозной работы, долгой загрузки и потерь клиентов по этой причине; - с потенциалом хакерского взлома; и скорее всего криво работающего в некоторых браузерах, поскольку на тестировании тоже экономили.)
8. Когда Code Review НЕ НАДО делать?
Code Review по сути противоречит краткосрочным бизнес-целям web-студии. Явной прибыли он не приносит, а время кушает порядочно. Нафиг он не нужен на коротких проектах, типа «натянуть дизайн на Joomla». Нафиг он не нужен на проектах, где критична скорость запуска, а не чистота кода. (Например стартап: делаем быстро грязный работающий прототип, запускаем. Если идея выстрелила — может быть перепишем красиво (обычно так никогда не бывает)...»
Еще один пример: обсуждение в закрытой группе сеошников отношения к работе для заказчика:
