Как избежать проблемы «проще переписать»?

Question

[WolfSkull]

Планирую заказать веб приложение, проект будет развиваться, возможно, поменяется программист, т.к. по моему опыту со временем некоторым надоедает вести один проект. В общем, опасаюсь проблемы, когда при смене программиста, новому «проще переписать». Если делать на фраймворке Yii, можно не опасаться смены программиста? Или еще нужно на GitHub вести его? С GitHub пока не хочется разбираться, можно ли потом залить проект туда?

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

Answer 1

[egorinsk]

> В общем, опасаюсь проблемы, когда при смене программиста, новому «проще переписать».

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

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

Переписывание кода — это потеря денег с неизвестным результатом, где гарантия что третий, четвертый и т.д. программисты не захотят переписать еще раз? Я вам советую этого избегать.

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

> Если делать на фраймворке Yii, можно не опасаться смены программиста?

Это зависит от программиста, Yii не запрещает гнать кривой код, хотя изучение фреймворка чуть-чуть выпрямляет мозги программисту (и повышает ваши шансы получить что-то нормально работающее).

Comments

[justyork]

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

[Алексей Павлов]

Я тоже один раз взялся доделывать один проект. Он был сделан на приличном фреймворке (ZF1, было года три назад). Так там были методы на 500+ строк, куча (куча!) дублирования в коде, когда приходилось вручную просматривать чуть ли не все строки всех методов класса, да ещё в саппорт-классы надо было заходить править, и в фронтенде на js тоже надо было те же вещи править.
В общем, через месяц отказался. Я не на работу туда устраивался, а на повремёнку, так что счёл возможным смыться.
Это был тот самый случай, когда надо было переписывать. Хотя проект был очень большой.
> Если делать на фраймворке Yii, можно не опасаться смены программиста?
ZF1 тогда был мейнстримом для корпоративного сектора, качественный фреймворк с отличной документацией. Не помогло...

Answer 2

[avorobiev]

Есть только один способ — нанимать правильных людей.

Comments

[kk86]

Это тоже не гарантирует. Хотя и лучшее из всего, да.

[habrsa]

Согласен.
Сложно, но варианты «покрывать код тестами» для заказчика, который не в курсе, что такое система контроля версий — совет ещё тот.
Поддержка, а особенно передача проекта — всегда дорогая операция, это без вариантов.

Если «прошлый программист» говорит, что закончил на 80%, это 1) не значит что он закончил на 80% 2) даже в идеальной ситуации с идельным кодом и проф.разработчиками затраты вновь пришедшего разработчика будут гарантированно выше 20%.

И что это за пурга:
>«как бы написать идеальный по моему мнению код», а не «как получить максимум прибыли с минимумом затрат».
1. это избитое клише, которое нельзя применять ко всем
2. разработчик, который пришёл дорабатывать проект по правилам рынка скорее заботится о своей «максимальной прибыли при минимуме затрат.»

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

Answer 3

[Максим]

>Если делать на фраймворке Yii, можно не опасаться смены программиста?

Использование фреймворка, ещё не означает отсутствие говнокода. В данном случае Yii, заставит придерживаться определенных правил и это хорошо, но попадаются люди, которые могут так извратится над функционалом фреймворка, что аж страшно становится. Тут многое зависит от уровня программиста. Если, он грамотно использует возможности Yii и ООП, то особых проблем вникнуть в проект не возникнет.

>Или еще нужно на GitHub вести его?

Не помешает. Например, на github или bitbucket.

Comments

[EugeneOZ]

Каких правил он заставит придерживаться? «Больше статики, синглтонов и GodObjects»? Нет в PHP нормальных фреймворков популярных кроме Symfony2.

[Максим]

Всё намного проще. Использование фреймворка в данном случае, неважно Yii это или Symfony, навязывает использование определенной структуры приложения, именование файлов и др. В проекте не будет смешана, самым худшим образом, логика и представление (не всегда). В отличии, например, от разработки проекта на нативном php, где может быть «спагетти» код из запросов/javascript'a и др. на пару тысяч строк и запутанная структура. Хотя опять же, тут многое зависит от грамотности программиста.

Answer 4

[Crank]

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

Answer 5

[deadkrolik]

Мое скромное мнение состоит в том, что единственный способ избежать такой ситуации — покрывать код тестами.

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

Answer 6

[Виталий Желтяков]

В некоторых случаях всё таки «проще переписать».

Проблема кроется не в выборе средств, а в подходах написания кода. Если код дописывать по принципу «тут чуть-чуть, там чуть-чуть», то естественно через некоторое время даже из понятного кода получиться говнокод. Если же код чётко разделять на отдельные функции или классы с адекватными комментариями, то проблем как правило не появляется.

Answer 7

[frostosx]

Если бюджет позволяет, то иногда заводят отдел контроля качества и тестирования. Если у вас не от случай, то поддержу egorinsk

Answer 8

[Никита Гусаков]

Мне кажется по каждому пункту конечных возможностей приложения должна быть реализована система модульности. Тогда все изменения будут вноситься относительно легко.
И почему именно yii?

Answer 9

[Павел Волынцев]

Очень неоднозначный вопрос, на который невозможно дать простой ответ.

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

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

Как подавить желание "всё переделать" ? Никогда не принимайте работу в состоянии "почти готово". У вас есть техническое задание? Если нет, закажите технических писателей - пусть составят ТЗ до начала работы программистов. А по окончании работ проверяйте все пункты ТЗ на реалиацию. Проверяйте на тестовом сервере, на боевом сервере. Несколько раз проверьте, чтобы убедиться, что что-нибудь не сломается само по себе через месяц. Закажите специально тестировщиков, которые смогут проверить проект на соответствие ТЗ. Тогда сработает первое правило программистов - "работает - не трожь". Новый три раза подумает, прежде чем что-то сломать.

А может быть через год действительно надо будет всё переделать. Пусть новенький обоснует. Проведёт code review и найдёт неисправимые уязвимости в безопасности, докажет низкую производительность. Пусть устроит usability test, обоснует редизайн и изменение в функциональности сайта. Пусть устроит A/B тестирование и поможет повысить конверсию и продажи.

Вот как то так. Бред, конечно, зато от сердца.