Тема: 
Потрудитесь объяснить поподробнее, а то можно не так понятьСообщение от slip7
| ||
Потрудитесь объяснить поподробнее, а то можно не так понять
Вот как раз наоборот
А не стоит путать недароботки проектировщика и реализацииПо модели "водопад" уже наврядли кто работает.
Выходит, что говорили, знания улучшающие взаимопонимание между программистом и дизайнером оказались не нужны. Проработка мелочей. создание хорошего ТЗ, не надо, просто выбираем пару паттернов и все, а дальше как-то сляетсяPS проектировка и коммандная работа никому не нужны - я об этом то и не говорил, что то кто то надумывает
Я говорю о том что юзабилити и GUI неотменная часть любого проекта, относиться к ней как мелкой и не важной - ошибка которая ведёт к фатальному результату в виде неюзабельных проектов.
Почему же тогда сейчас как раз при деле гибкие итерационные методы разработки?
Стоп. Вы что говорите о минипроектиках на два дня где все напроектировали и отдали жетское время на реализацию?
Говорили что обоим зачем почему то знать что такое полярная система координат и как ее пользоваться. В 99% процентах случаев ни тому ни другому это не надо, а если и надо то постигается это настолько быстро что даже упоминать об этом как о требовании к что одному что второму не имеет смысла.
Говорили о дизайне - рюшечках которые крутятся и т п
Да и о том что не все первично на проектах и детально продумывать реализацию их с самого как правило не выгодно.
Если уж решились что то коментировать что найдите время прочитать внимательно и обдумать прежде чем написать, а не просто безаппеляционно резюмировать в стиле Лебедева.
Значит составление полного грамотного ТЗ противоречит итерационным методам разработки?
Если на то пошло, то в больших проектах, есть специальные люди, которые говорят, что эта кнопочка должна быть красной с зелеными буквами, как раз в больших проектах все рассматривают до мелочейСтоп. Вы что говорите о минипроектиках на два дня где все напроектировали и отдали жетское время на реализацию?
Это частный пример использования, но на всякие такие мелки постижения того элементарного уходят в итоге часы рабочего времениГоворили что обоим зачем почему то знать что такое полярная система координат и как ее пользоваться. В 99% процентах случаев ни тому ни другому это не надо, а если и надо то постигается это настолько быстро что даже упоминать об этом как о требовании к что одному что второму не имеет смысла.
ЗЫ тему уже можно переименоватоь
рюшечки которые крутяться очень не маловажная вещь для заказчика, не надо принебригать этим.
Это не выгодно, если проект может в любой момент развалитсяДа и о том что не все первично на проектах и детально продумывать реализацию их с самого как правило не выгодно.
А в электронном виде нет?
В досконально полном ТЗ смысл будет если оно с самого начала не будет менятся. А это как бы не совместимо с "гибким"
Есть. Но суть не в том что они говорят это. А когда они это говорят и когда имеют право сказать еще раз.
Всего не предугадаешь, можно всю жизнь потратить на изучения всяких таких мелочей типа авось пригодятся и в итоге все равно не солкнувшись с тем что будет нужно.
под гибким я понимаю использование кашерных паттернов для проекта, правильного построение классов по работе с БД, чтоб при малейшем изменении БД не пришлось переписовать весь класс-менеджер, а такие вещи как эргономику, динамику элементов и т.п. можно описать и сразу
Они всегда это имеют право высказать, на любом миттинге, т.к. это очень важный аспект для пользователяЕсть. Но суть не в том что они говорят это. А когда они это говорят и когда имеют право сказать еще раз.
Я изначально просил обратить внимание, что говорю я не про отдельный курс диф.ур., конечных автоматов и т.п., а про стандартный курс математикиВсего не предугадаешь, можно всю жизнь потратить на изучения всяких таких мелочей типа авось пригодятся и в итоге все равно не солкнувшись с тем что будет нужно.
Гибкость как раз и подразумевает возможность изменять требования. Конечная эргономика и т п это вообще результат проб и ошибок.
Финальный результат - баланс между удобством эксплуатации, функционалом, красотой, техническими ограничениями, финансовыми и временными рамками.
Никто в большом проекте этот баланс сразу не предскажет.
стандартный курс математики - это что?
Исходя из сказанного можно сделать вывод: берем проект, пишем ТЗ, делаем что получится, отдаем пользователю. Да можно во время создания проекта изменить формат тултипов или их фон, но искать по ходу работы компромисы между всеми влияющими на проект вещами, это гибкость, скорее это халатность.
это то, что в школе даютстандартный курс математики - это что?
делаем что получится - делаем что надо и возможно сделать по текущему заданию.
Хочется вам того или нет, но большинство проектов покрупнее сайтов визиток, именно так и делаются
часто приходится применять производные программистам или дизайнерам?
А есть в Одессе курсы, где учат именно веб-программированию?
Добро всегда побеждает зло! Значит, кто победил - тот и добро!
В Шаге вроде есть всё.
Зачем вообще курсы????? если в сети много инфи сиди сам себе дома в красных трузелях и зубри!!!))))))если конечно в голове не сидит вирус кривые руки)))
угу, спасибо. На счет ШАга знаем, но цены там - запредельные! Имхо.
Добро всегда побеждает зло! Значит, кто победил - тот и добро!
А при чем кривые руки к голове?!
Добро всегда побеждает зло! Значит, кто победил - тот и добро!
Притом если руки не стоят та в голову не вобьешь
Все равно не вижу связи! Руки - это одно, голова - другое. Если человек умеет работать головой - руки не при чем! И наоборот...
Добро всегда побеждает зло! Значит, кто победил - тот и добро!
Ваши права
Ответить с цитированием
Социальные закладки