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

Присущ
На сайте с 06.01.2011
Offline
914
#21
Shlackbaum:
жопа...

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

Прототипы и юзабилити, чтоб продавал и в топ попал Анализ сложившихся бизнес моделей и поиска точек роста Директ — от 2500 р, включая бюджет на клики / Аудит РК до и после запуска — от 5000 р
Shlackbaum
На сайте с 18.08.2010
Offline
311
#22
Присущ:
Не совет, но для облегчения направлений мысли, бывает и проекты с миллионом в месяц, переписывают заново, куда деваться, если это легче, чем постоянно искать грабли.

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

-

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

VoV@
На сайте с 22.09.2007
Offline
196
#23
LazyBadger:
А скрам-спринты-агилька и прочий дрек - это оформления, это стиль, а не решение. У вас же сейчас - просто бардак, а "бардак автоматизировать нельзя"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⭐ Разработка Андроид-приложений (Xamarin C#). ⭐ Разработка ASP.NET (WebForms, MVC, WebAPI, Core). ⭐ Цой жив!
melkozaur
На сайте с 06.04.2010
Offline
496
#24

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

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

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

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

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

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

Серверы в NL/US со скидкой 30% нашим читателям: E5-2650v4/10GB DDR4/240GB SSD/1 Gbps - от $20: https://ua-hosting.company/vps/nl SEO без компромиссов: https://seoleaks.net SEOLEAKS - продвижение сайтов: https://www.instagram.com/seoleaks
VoV@
На сайте с 22.09.2007
Offline
196
#25
melkozaur:
К реальности, в которой мы говорим о магазинах, контентных проектах и т.п. - сайтов не настолько сложных, чтобы каждый пук документировать и создавать для каждого пункта каждого меню отдельную документацию на полсотни страниц.
В действительно крупных компаниях знают, как это все организовать. Там и бюджет и состав команды позволяют. Там можно экспериментировать, строить новые системы и т.д.
Но мы же не говорим о действительно крупных, так?

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

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

K
На сайте с 22.11.2017
Offline
17
#26
koketkade:
Вы, как разработчики, просто недооцениваете СКРАМ... :) Из личного опыта могу сказать, что 90% разработчиков на начальных этапах не одобряют любые изменения... и воспринимают это чуть ли не вторжением в их личную жизнь... :) Но через время приходит понимание...

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

VoV@
На сайте с 22.09.2007
Offline
196
#27
kekeke:
вы рискуете получить проблемы в части 2 независимо от того какую методологию используете и используете ли вообще

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

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

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

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

S
На сайте с 30.09.2016
Offline
469
#28
koketkade:
Вы, как разработчики, просто недооцениваете СКРАМ

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

Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
melkozaur
На сайте с 06.04.2010
Offline
496
#29

VoV@,

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

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

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

KrutE
На сайте с 29.04.2006
Offline
200
#30
У меня пока есть полное ощущение, что сижу в треде, где общаются разрабы Пейпала, Амазона, Фейсбука, e-bay и т.д. ну и порталов поскромнее

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

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

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

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

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий