Конечно для интернет магазина именно корзина будет местом складирования покупок. Такой стиль безусловно навеян реальными магазинами, в которых это образ просто незаменим.
Вот такую идею я выразил в своём первом посте, но почему-то он был безжалостно заминусован (и почему-то не только пост). Но я всё таки прошу ответа — неужели известный дизайнер не попытается уйти от совсем не нужного ему суда? Способов в конце концов много. Я предложил один из них…
Это очень страшно, когда происходит именно отход от модели. Когда модель трансформируется — это нормально. Зачастую отход — это просто прикрепление к ней сбоку дополнительных функций, т.к. они нужны. Но как они будут взаимодействовать с моделью — уже не так важно в этом случае.
Главное, чтобы было как в «Крёстном отце»: ничего личного, только бизнес. =)) А то иногда очень противно, когда в компании начинаются личные разборки из-за чисто деловой активности…
Это задача разработчика — предложить решение, которые сумеет удовлетворить заказчика и учесть технические ограничения, это его работа.
Про это я писал выше. Но хочу отметить, что имея проект на долгой поддержке, когда требования с развитием меняются настолько кардинально, что стартовая модель перестаёт работать, становится очень сложно адаптировать требования заказчика. Поэтому цели заказчика следует направлять в необходимое русло в таких случаях, а просто удовлетворить его уже не получится.
Да, часто встречается непрофессиональный подход к управлению проектом. Так сказать, поверхностный, когда менеджер не вникает и не понимает мысль заказчика и соответственно не будет с ним на одной волне.
Почему бы не сменить менеджера или как попытаться согласовать с ним действия, вмешаться в процесс?
Не каждый программист может сменить менеджера проекта =)). А если серьёзно, то согласовать свою работу с менеджером не всегда просто (данная конфликтная ситуация была в моём личном опыте). Часто слышишь ответ — не лезь не в свою работу. Поэтому сейчас работаю без менеджера и предельно счастлив. =))
как правило, заказчики бывают правы, и смотрят они зачастую более стратегически выгодно, нежели разработчики.
Они смотрят стратегически выгодно для своего бизнеса, но не понимают, что решения, которые они принимают при развитии продукта, могут быть противоречивыми с точки зрения архитектуры. Это довольно большая проблема для динамически развивающегося приложения.
Скорее всего возможно модифицировать идею заказчика, чтобы она его продолжала устраивать и казалась ему его. Но в тоже время перестала быть лажей в реализации.
Честно говоря, непонятно за что заминусовали топики. Вполне понятно, что сделано это не специально, а есть какая-то проблема с добавлением комментария.
У меня тоже подобная проблема — в основном переделывание нескольких старых проектов под изменяющиеся требования. Но для меня всегда интересно реализовать лучше, чем было, добавляя новые возможности, которые просит сделать заказчик и применяя там новые технологии.
Даже ликвидация последствий бывает приятной, когда видишь, что проект начинает работать стабильнее и отношение заказчика также меняется, т.к. там есть всё, что он хочет и работать это всё начинает как надо. Но, конечно, соглашусь с вами, что намного приятнее создавать, чем исправлять.
3. Порядок и список аргументов в функциях/методах были составлены по одному принципу и сочетались с именем.
Не уверен в этом пункте, как вы. Современные IDE, тот же Zend Studio, говорит в каком порядке и какие аргументы у функции (при достаточном комментировании конечно же). Для стандартных функций это тем более доступно. Поэтому вопрос: зачем засорять имя функции такой информацией?
Про это я писал выше. Но хочу отметить, что имея проект на долгой поддержке, когда требования с развитием меняются настолько кардинально, что стартовая модель перестаёт работать, становится очень сложно адаптировать требования заказчика. Поэтому цели заказчика следует направлять в необходимое русло в таких случаях, а просто удовлетворить его уже не получится.
Не каждый программист может сменить менеджера проекта =)). А если серьёзно, то согласовать свою работу с менеджером не всегда просто (данная конфликтная ситуация была в моём личном опыте). Часто слышишь ответ — не лезь не в свою работу. Поэтому сейчас работаю без менеджера и предельно счастлив. =))
Они смотрят стратегически выгодно для своего бизнеса, но не понимают, что решения, которые они принимают при развитии продукта, могут быть противоречивыми с точки зрения архитектуры. Это довольно большая проблема для динамически развивающегося приложения.
Даже ликвидация последствий бывает приятной, когда видишь, что проект начинает работать стабильнее и отношение заказчика также меняется, т.к. там есть всё, что он хочет и работать это всё начинает как надо. Но, конечно, соглашусь с вами, что намного приятнее создавать, чем исправлять.
Не уверен в этом пункте, как вы. Современные IDE, тот же Zend Studio, говорит в каком порядке и какие аргументы у функции (при достаточном комментировании конечно же). Для стандартных функций это тем более доступно. Поэтому вопрос: зачем засорять имя функции такой информацией?