Однако есть проблема - расширения не будет, так как есть аутсорсинговая компания на большой и сложный объем работ.

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

А здесь никто и ничего гарантировать не может, % 80 программеров даже опытных - фиг поймешь как у них мозги сложены и что им надо .. текучка очень большая, пока это ниша работников относительно слабоконкурентна. итого: как повезёт ..

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

Это не опытные разработчики. Это велосипедисты, мнящие себя опытными и обучающиеся каждый раз городить новый велосипед за счёт незадачливого заказчика.

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

Потом приходит следующая "команда" и, разумеется, тоже находит что ООП применено не то и не там, да и версия ПХП устаревшая, надо на новой переписать. Разумеется более клёвой. Причём непременно с нуля.
Заметьте, функционирование проекта ни одну из этих команд "опытных профессионалов" не интересует вообще во всей этой схеме.
Вот это и есть велосипедисты, у которых за плечами "несколько десятков запущенных с нуля проектов". Над каждым словом из этой фразы плакать хочется. Заметьте, "запущенных" проектов (разумеется, "с нуля"), а не "работающих". Встретите - передавайте им привет при случае.

Проще и дешевле спроектировать его с нуля, используя патерны проектирования.

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

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

Жму руку за ответ

Добрый вечер. Исходя из ваших требований Вам нужен состоятельный специалист, который поучаствовал не в одном проекте. Не понимаю насчет Вашего сомнения в выборе сотрудника. Или уровень заработной платы не позволяет нанять хорошего специалиста?

Согласен. Второе - это и есть варианты выбора. Неудачно сформулировал в виде вопроса.

Проблема в том, что это вовсе не "разовый" выход. Это состояние Г-проектов такое. Я тоже поначалу, так думал... ну задержался раз... мелочь, ну опять проблема того же выбора... и тут снова.

И так пока не дошло.

Вы же ведь тоже понимаете что "написать заново - в три раза дешевле чем поправить". Фраза не моя, и понимаешь её только по опыту.

P.S. и да, не поняли.

P.P.S. выводы из этого оффтопа автору темы:

1. Если нужен прогер для "слегка подправить результат аутсорса", то ищите гуру и чем круче он будет, тем больше шансов на успех. Требуемые знания, совсем другие: умение бегло читать и разбираться в чужом коде (язык не важен!), опыт реассемблирования чужого кода вплоть до ручного восстановления алгоритма на ЯП, высокая стрессоустойчивость и способность к нагруженной работе. Ещё раз - ЯП предыдущей работы - не важен. Совпадет, значит Вам повезло, нет - освоит за пару недель ваш ПХП вместе с Джумлой или что там у вас на самом деле. Полезно знание "общих алгоритмов и принципов оптимизации и инкапсулирования разных систем друг от друга".
2. Если нужен прогер для доработки НОВОГО (это крайне важно!) функционала И БЕЗ правки уже сделанного, то можно и джуниоров. Тут как раз исходные знания - "чем ближе" к применяемым инструментам - тем лучше.

Вы сами-то PHP от С++ отличаете

на php пишу со времен 2-й, на C++ со времен topspeed/zortech c++ и borland c++ 3.1
не знаю зачем вам это понадобилось знать
и Forth от ADA тоже отличаю, и на них приходилось писать
про "дерьмо от аутсорсеров" - это больше вопрос к психологам, негативное мышление и так далее - тут не буду вас консультировать

ну тут у меня проще - что и как делать решаю я
допустим старый код, изначальный был на 4-й php, выходит пятая, я жду, до 5.2 в итоге ждал, потом запустил задачу миграции
сделали, все как по маслу прошло
старый код от прошлых разработчиков поддерживают и изменяют, новый функционал надо был писать, который можно реализовать отдельным проектом - попросил оценить варианты, так как качество старого кода меня не устраивает сильно, и ребятам тяжко постоянно тестить/разгребать чужой отвратительный код при дописке функционала, а там не одня сотня тыщ строк кода
в итоге из предложено выбрал симф2, как перспективную и подходящую технологию - сейчас вижу что не ошибся, после создания необходимого каркаса сейчас все гораздо быстрее и надежнее делается
поэтому смены комманд меня не пугают, а вот программер который свой собственный, и учавствует в этом безобразии - он нужен
ну я все что тут было написано прочитал, приму к сведению, были интересные мысли/мнения
думаю попробовать найти хорошего крепкого середнячка которому нафик не нужна "бумажная" работа в виде рисований диаграмм ганта и прочие головники, которому само по себе программирование - достаточно, и которому не чужда ответственность и самоуважение в виде качественного кода

Одно другого - не исключает. Вы привели достаточно забавные конструкции для PHP.

это было не для PhP совсем

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

на php пишу со времен 2-й, на C++ со времен topspeed/zortech c++ и borland c++ 3.1

Вообще не показатель знания стандартов. Один правильно подготовленный джуниор перекроет замшелый опыт старых, доисторических компиляторов. Увы.
Вы ещё побравируйте опытом на ZX Spectrum

попробовать найти хорошего крепкого середнячка

Кстати, соглашусь
Всё чаще многие приходят к мысли, что overqualified не есть гуд для стабильной работы

Забавно все-таки Вы сравниваете работу джуниора с опытом компиляторов... а у старых замшелых компиляторов, наверное много накоплено опыту, да? Хде, на перфокартах или 5-дюймовых дискетах?

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

... а "обоснование", полагаю тривиально: лучше брать Джуниора, уже успевшего подскользнуться, пардон набраться опыта, на паре тройке проектов. Предполагается, что есть шанс "осмысления" процесса скольжения... а "вдруг" начнет кодить "как надо"... (наивняк)

Автору:
1. Брать Джуниоров можно в команду, где уже есть спецы. И помогут, и научат и поправят.
2. Брать "середнячков" можно в уже работающий проект для расширения функционала, крайне желательно БЕЗ правок - какие-то обособленные новые задачи. Меньше шансов, что испортят то, что уже работает (побоятся лезть в чужой недокументированный код).
3. Править, улучшать работающий функционал (в наших реалиях) - крайне желательно автору. И делать это без веских причин - очень рискованно. Если автора нет а расширение надо интегрировать в работающий модуль (если оно ваще модульное), то нужен спец. с квалификацией не ниже автора, а лучше - выше.
4. И вот только если "приперло", надо править... и вот тут или автор или тот, кто имеет опыт.

Да и то. Подумать, обозвать первой версией и начать делать вторую рядышком.

Как-то так.