Программирование как "Антибиотик" проекта: "Одно лечим - другое калечим"

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

=) Да я это понимаю, к сожалению есть и такой опыт (хотя не на лямы). Это не проблема "сегодня" и не проблема "вчера". По большому счету с этой проблемой я встречался и год назад и несколько лет назад в самых разных рабочих контекстах. Но сегодня меня так отбомбило, что я начал искать системное рентабельное решение. Я не поверил прогеру, когда он говорит "так все делают". (так - это как я описал и как коллеги предложили в треде) Оказывается все реально так. Прям пичалька.

-

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

Вот, то же самое написать хотел.

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

Code — разработка и анализ кода, инструменты контроля версий, слияние кода;

Build — инструменты непрерывной интеграции, статус сборки;

Test — инструменты непрерывного тестирования, которые обеспечивают обратную связь по бизнес-рискам;

Пакет — репозиторий артефактов, предварительная установка приложения;

Release — управление изменениями, официальное утверждение выпуска, автоматизация выпуска;

Конфигурация — Конфигурация и управление инфраструктурой, Инфраструктура как инструменты кода;

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

Нужно наводить порядок, без этого никак.

---------- Добавлено 25.10.2018 в 11:17 ----------

Переписывание с нуля не гарантирует отсутствие ошибок. Бардак в процессе снова вылезет наружу, пройдёт год-два и придётся опять всё переписывать.

PS Вот ещё на тему "переписать".

Мне не нравится этот подход и эта картинка тоже не нравится, как не нравятся и снобские статьи-переводы на хабре про то, как нужно организовать процесс.

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

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

Но мы же не говорим о действительно крупных, так?

Ржака в том, что все эти советы и системы, которые применяются в крупных компаниях - они вообще не применимы к компаниям поменьше. И будут только тормозить разработку. Но я знаю, что есть любители почувствовать себя Гуглом или еще кем-то, внедрить сразу все известные системы, всю документацию, и смотреть на 2 программистов, которые умирают, пытаясь все это прочесть и учесть.

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

Вы ошибаетесь. Не нужно никаких отдельных документаций на полсотни страниц. Доведение до абсурда не идёт на пользу ни большим ни малым проектам. Всё проще гораздо. Эти принципы хорошо масштабируются и очень упрощают внесение правок и получение фидбека. Основные проблемы с любым проектом появляются не во время старта, а именно тогда, когда надо что-то изменить или добавить. Заранее просто невозможно предусмотреть, как всё будет работать в реальности.

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

речь шла о том, что скрамы и их же с ними - это методологии разработки, а не сама разработка. Если у вас есть части 1 и 2 системы, tightly coupled друг с другом, вы меняете требования для части 1 и не тестируете часть 2, то после внесения изменений, вы рискуете получить проблемы в части 2 независимо от того какую методологию используете и используете ли вообще

А всё потому, что бардак. Никто не знает, что произойдёт в части 2.

А почему бардак? А потому, что нет общих правил внесения изменений, их контроля и тестирования (нет следования проверенным методикам, дао, бусидо и т.п.).

Почему нет? А нафиг они нужны, у нас же интернет-магаз, а не система управления группировкой околоземных спутников.

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

Угу, и СКРАМ-совещания в особенности

VoV@,

Конкретику давайте, конкретику. И ТС тоже.

У меня пока есть полное ощущение, что сижу в треде, где общаются разрабы Пейпала, Амазона, Фейсбука, e-bay и т.д. ну и порталов поскромнее, но все равно масштабных.

А еще этот топик - антиреклама самописов, причем очень показательная.

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

вы прежде чем писать, бюджеты сих мероприятий озвучьте?

Всегда из реалий бизнеса клиента надо исходить.

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