Pushkoff
> у тебя на почте должны остаться все посты этой темы, скинь мне на мыло если не жалко...
лол. что ты собрался делать с постами вия?
Помню Вий там что-то вещал про итеративнъй процесс разработки...
От себя могу сказать, что я такой наблюдаю уже 2 раза - оно после нескольких лет протухает почти что окончательно. Становится невозможно работать, баг-фикс каждой новой фичи отнимает до 50% времени.
Но вина всему не итеративность, а тупо отсуствие скилла. Нет скилла - любой метод дизайна не спасет от такой разработки. Есть скилл - хоть как делайте, жить будет.
Так что ответ в людях скорее, чем в методологии разработки - будь там agile, постояннъх рефакторинг и прочие, они не спасут от тупого девелопера, которъй к примеру размажет очередную подсисетму по всему сорсу и т.д.
Suslik
> лол. что ты собрался делать с постами вия?
тред эпичен чуть более чем полностью... хочу хранить его у себя...
Z
от себя добавлю, scrum в котором билды делаются не для себя а для проверок из вне, убивает код еще сильнее, так как за час до мейлстоуна вносится прикруток больше чем за всю неделю до этого, и они там остаются, так как новый мейлстоун требует выполнения новых задач...
2Pushkoff
Кто ж знал-то :) По сути, теория она того, важная вещь. Просто вопрос возник на самом интересном месте - при начале образования команды, а я приверженец четкого спланированного кодинга. Ну хотя бы в мечтах :)
Уфф.. На ящике, конечно, что-то осталось, но что-то попадало и в спам (или еще куды). Я, конечно, могу понаставить галок и переслать тебе.. Ты уверен, что хочешь этого?
Смотрю свой код двухлетней давности. Иногда прямо гордось за себя берёт, мол, как здорово догадался что-то вот здесь проэктировать. Или возникнет мысль: "мдаа, надо бы тут добавить такой-то метод", смотришь - а он уже, оказывается, есть :)
Помнится, когда я два года назад смотрел свой код, соответственно, четырёхлетней давности, wtf/m просто зашкаливал.
Картинка лол, сохранил)))
Suslik
> wtf/m просто зашкаливал
сильно зависит от ревьюера : )
холиворы они ведь не зря, встречал варианты когда ревьюер был из другого идеологического лагеря, так вот на каждую элементарную, с моей точки зрения, весчь приходилось давать много ответов, и всё равно чуял, что не все ответы принимаются, периодически проскакивали искры
но вот сам себе ревьюер это всегда плохо, варишься в собственном соку : (
Sh.Tac.
> сильно зависит от ревьюера : )
У нас сработанная команда из трёх человек. Чёткий code convention и, в существовании чего я вообще не был уверен, у нас практически совпадают взгляды на проэктирование в целом. То есть то, что проэтируют напарник и напарница вызывает уважение у меня, то, что напроэктирую я - у них. Ну, по крайней мере обычно :)
Ясное дело, если какой-нибудь из наших проэктов, с головой напичканных шаблонами и виртуальным наследователям показать какому-нибудь покимону или ещё кому повёрнутому, например, на plain C, то ничего кроме отторжения у ревьюера вызвать не удастся. Но вот не пофиг?
Вий, это не серьёзно. ты иногда входишь в какой-то дурачок-мод и с тобой становится напрочь невозможно общаться.
Вий
в орхетектуре краудсорсинг не работает. у одной задачи может быть несколько, вообще говоря, жизнеспособных решений и они друг с другом часто вообще не уживаются. кто-то любит ездить на велосипеде, кто-то - на самолёте, и при этом слушать всех подряд не просто не рекомендуется, а вредно. надо взять одного опытного человека и делать так, как он скажет. чтобы самому стать таким человеком, лучше способа чем просто программировать, программировать, программировать, наверное, ещё не придумали.
Suslik
> лучше способа чем просто программировать, программировать, программировать,
> наверное, ещё не придумали.
я вот тоже думаю что вию мешает
тупо писать код
правда решил промолчать
нафига вся эта архитектурная ахинея?
> нафига вся эта архитектурная ахинея?
Согласен. Я в неё тоже не упираюсь. Тупо пишу как получится. Есть конечно наброски, но четкой архитектуры не представляю (пробовал не получается. плюнул).
> лучше способа чем просто программировать, программировать, программировать
Золотые слова.
Вий
Да вижу тебе не помогут , хотя все считают , что ты сам взялся за это и должен сделать все сам . Вообщем пока
единственный способ тебе помочь - это сделать так чтобы ты сам понял что к чему , впрочем остальных это тоже
касается - кодить непонято что , но зато работает - значить движок - точно да ? Давай напрягайся , как почувствуешь ,
что вагон день тянул - значит есть толк .
Берешь любой компилятор и вставляешь на форму проигрыватель музыки с кнопкой , в проперти загружаешь еще до
компиляции файл мп3 , добаляешь три панели друг на друга , на каждую панель по картинке одинакового размера ,
затем связываешь нажатие кнопки с процедурой по которой меняется порядок панелей - тру и фалс - вкл и выкл -
одну включил другую затем выключил - одно нажатие - сделай рандом в процентах в связи с таймером и сиди и клацай
пока не дойдет - то есть тут только вариант делать , а так ты ни до чего не дойдешь просто представляя себе как это .
А потом посмотришь на все свои схемы и полезные советы и увидишь где что .
Офтопнусь. Тут столько эпика, что просто перегруз мозга произошел =)
Но, вопрос в другом - посоветуйте что нибудь полезное почитать про архитектуры движков? Англ, русс - не важно. Так сказать, что вам по опыту реально помогло. Гуглил, буржуйские статьи читал, в основном только там что то найти можно - много воды, которая вытекает. То есть не передается принцип мышления и представление абстракции логики направления брейн шторма =(
Тема в архиве.