Как выбрать программиста для сайта?

в сухом остатке следующее:

самопис с фрилансером: непонятный опыт исполнителя, непонятные перспективы по поддержке, высокая стоимость. Уровень исполнения зависит от уровня 1 исполнителя - это конечно не очень хорошо, при том, что объективно оценить его я не могу. Косвенно вижу, что это не самый высокий уровень, по его работам.

студия:любая цмс, например, та же джумла, на которой сделана существующая версия. Я ее знаю, мне она понятно. Студия берет ядро джумлы 3 и допиливает все, включая структуру базы данных под мою задачу.Необходимые компоненты дописываются. Если что-то типа стандартного модуля можно использовать - используется. Нет проблем ни с натяжкой шаблона на любую цмс, ни с отдельным архитектором, ни с отдельным программистом, можно потом заказать тестирование системы. По оценке говорят, что промахнуться больше чем на 20% не могут.

Уровень исполнения не зависит от уровня 1 исполнителя. Оценить уровень можно по сложности решаемых студией задач.

Думаю та же джумла должна выдержать 30000 страниц и 5000 пользователей без проблем.

Фриланс ценится за низкую себестоимость. Если стоимость студии ниже фриланса - либо слудия никчемная либо фрилансек зажрался, ищите другого.

Поддержка зависит от способа реализации - фрейм или цмс - с поддержкой проблемы будут минимальные.

С моего опыта, даже такие цмс как джумла или ДЛЕ очень часто заказуют перенести на фреймворк, часто взламывают и тд.

Но что еще хочу сказать - если у вас больше 5000 юзеров в день не планируется и база не более 500 000 тыс записей - то вы зря создавали тему. Делайте на том, что доступнее и дешевле. Даже ВП при его тормознутости таки проблемы выдержит при кеширвоании и норм хостинге.

Такую тему нужно создавать если у вас планируется SAAS/B2B/другое - что-то, что реально выходит за пределы цмс/новости/магазина.

Ну у каждого свои темы и уровень понимания! Благодарю Вас за мнение! Не сердитесь!

Мне эта тема помогает, а в общем-то это и есть ее цель!

Вот "допиливать ядро" - это плохо. У вас сайт должен быть совместимый с новыми версиями системы. Если пилят ядро - это очень плохо. Мы на WP, например, когда модули разрабатываем или темы всегда стараемся совместимость делать с новыми версиями WP и, по возможности, новыми версиями модулей.

Первое сообщение на форуме! поздравляю!

Нет, наверное ядро не пилят, но предварительно сказали, что уровень кастомизации будет такой, что автоматические обновления скорее всего будут невозможны и типа это нормально.

Но если потребуется обновление версии ядра, то это делается в ручном режиме с исправлением появляющихся косяков.

Хотя скажу Вам по секрету, работающий сайт идет на версии 1.5. и ей наверное лет 6, работает без обновлений. И никто не ломает, т.к. старая :)

tysson, на самом деле он совершенно верно насчет совместимости с новыми версиями сказал - я как раз то же самое хотел добавить.

Смысл Джумлы (или другой CMS) именно в том, чтобы использовать общие наработки по максимуму, чтобы не выполнять обновления "в ручном режиме с исправлением появляющихся косяков".

И помимо попыток взлома (количество которых с ростом популярности может увеличиваться), вам также в дальнейшем могут понадобиться компоненты и плагины, которые откажутся работать со старой версией.

я понял, что по поводу автоматического обновления надо момент проговорить. Спасибо

Это утверждение - серьезный повод задуматься о том, насколько оптимально выборан подход к решению задачи. Проводя аналогию в строительстве, строя многоквартирный дом, вряд ли кто станет заказывать в КПД панель, что-бы заложить в ней окно и вырезать болгаркой дверь в другом месте. Если проект требует нетипового решения - заливают монолит и кладут кирпич. Это в любой сфере человеческой деятельности так - грамотный подход подразумевает не переделку готового, а переход к выбору более простых компонент.

Такая фраза, обычно, означает, что у Вас возрастут расходы на сопровождение. Т.е. в реальных условиях ограниченности ресурсов, придется жертвовать развитием ради поддержки. Кроме того, "исправления появившихся косяков" часто имеет далеко не нулевой временной промежуток и, что хуже, сопряжен со снижением качества работы продукта.

Избежать указанных проблем поможет пересмотр выбранной технологии. Как вариант - вместо сайта в традиционном понимании перейти к веб приложению в котором:

1. Представление данных независимо от API.

2. Каждую задачу рассматривать изолировано от остальных.

3. Внутри каждой задачи определить базовый функционал, без которого совсем ни как и дополнительный.

Такой подход даст больше гибкости. Во первых, уйдете от длительных сроков. Каждый модуль проще просчитать и по времени и проверить в работе. Во-вторых, проще сменить исполнителя, если что-то пойдет не так. В третьих, быстрее получите минимально рабочий вариант, который потом можно наращивать фичами.

tysson, пробежал вашу тему вскользь, понял, что на момент создания у вас явно была каша в голове, решил подкинуть тезисы на основе которых возможно легче принять решение.

1) Выбор того на чем писать должен быть основан на:

а) Возможности реализовать необходимый функционал на "этом",

б) Возможности найти в дальнейшем нового программиста, когда старый "слетит" (это происходит всегда).

2) По поводу Yii. Когда я пришел 3 года назад на их форум с бюджетом 300 000 и явной возможностью расширить функционал фреймворка, котрый напрямую пересекался с моей темой (интернет торговля), спецов там не нашлось. При том, что это (судя по обсуждениям в интернете) это классный фреймворк, необходимо учитывать, что любой фреймворк, как и ЦМС накладывает определенные ограничения на разработку. Поэтому опять возвращаемся к пункту 1а.

3) Программистов можно тестировать, но за бюджет "от 200 000" без умения их тестировать (опять же не будучи прогером вы это не сделаете) на классных программиста рассчитывать не приходится - повезет если найдете средненького.

4) Идеальный вариант писать на php c нуля, но он минимум в пару раз дороже.

5) Обратите внимание на описание кода, помимо описаний в самом коде, нужно делать документ описывающий весь функционал поштучно с пояснением как реализовано и где находится код. (ИМХО)

А что значит писать с нуля? И почему такой подход идеален? Разумеется, учитывая что 2016 год на дворе.

Это в теории хорошо. На практике, особенно для небольшой команды и постоянно развивающегося продукта, внешняя документация достаточно быстро рассинхронизируется с реальным положением вещей в коде. Если придерживаться определенного стандарта в оформлении, код сам себя отлично документирует. Все просто - надо тщательно подходить к выбору имен идентификаторов и форматировать для удобства чтения и навигации. Если что-то со временем стало непонятно - значит названия выбраны неудачно и надо их рефакторить. А описывать как реализовано - это избыточно. Все видно в коде. И XML Documentation comments для описания контракта функции и решаемой задачи.