вот — очень круто сказал:) 20-30 разработчиков и тестеров, но в РФ никто в ИТ не понимает необходимость такого подхода. Минимизация такова, что пусть напишут говно, которое тестируется уже в проме на клиентах, чем будут держать штат из кучи разработчиков.
Такое делают только те люди, которые сами проработали в Штатах\Лондоне и все на своей шкуре почувствовали. Яркий пример — Parallels — ребята жгут напалмом, софт один из лучших.
Не знаю, что надо сделать, чтобы у нас были такие команды разработчиков? Разве что самому бизнес организовывать.
Последний предложенный вопрос\метод — это создание всемирного управлятора. Собственно, было опробовано у нас, спасибо, хватит:)
По-моему, чем толще система, тем разнесеннее нужно делать уровни. Слои, черные ящики и т.п. — конкретно что и как должно быть не скажу, не знаю какая у вас там должна быть кухня. Я у себя сделал слой данных, слой бизнес-логики, которая по факту оборачивает методы слоя данных и т.п.:) получается кошерно, жалко нет времени все добротно доделать.
С аттрибутами знаю точно, должны спасти DTO. Если все интерфейсы между слоями определить через dto то доработки по добавлению\удалению полей будут идти в несколько раз легче. Но что-то мне говорит, что никто тебе\вам этого сделать не даст:)
Нет, ну мы были достаточно разумны, чтобы не лезть в исходники или апдейтиться при каждом выходе новой версии.
Все таки все это от лешего, все эти финтифлюшки и гемор там не из-за докрутки функционала, а из-за того, что не существует общего поведения контролов. Датасорс девэкспрессовского комбобокса не биндится, например. MRUEdit не умеет искать по вхождению. CheckedComboboxEdit не позволяет биндиться на отмечаемые коллекции. В treelist нет галочек, опять же как класса — нужно подпихивать свои иконки. И т.п.
Короче все эти мелочи жутко досаджают — приходится писать тонну своих элементов. В конце концов пришло понимание — что да, это таки красиво и юзабельно, но блин, сколько же лишнего!
А в чем фишка IronRuby, по сравнению с типизированными языками, c# например? Чем он круче шарпов?:) Объясните холопу-девелоперу или киньте ссылкой (может, кто какую хорошую видел по теме) — буду признателен.
Такое делают только те люди, которые сами проработали в Штатах\Лондоне и все на своей шкуре почувствовали. Яркий пример — Parallels — ребята жгут напалмом, софт один из лучших.
Не знаю, что надо сделать, чтобы у нас были такие команды разработчиков? Разве что самому бизнес организовывать.
По-моему, чем толще система, тем разнесеннее нужно делать уровни. Слои, черные ящики и т.п. — конкретно что и как должно быть не скажу, не знаю какая у вас там должна быть кухня. Я у себя сделал слой данных, слой бизнес-логики, которая по факту оборачивает методы слоя данных и т.п.:) получается кошерно, жалко нет времени все добротно доделать.
С аттрибутами знаю точно, должны спасти DTO. Если все интерфейсы между слоями определить через dto то доработки по добавлению\удалению полей будут идти в несколько раз легче. Но что-то мне говорит, что никто тебе\вам этого сделать не даст:)
Юниттесты все же круче тем, что они отделены от кода, тогда как контракты должны быть с ним тесно связаны.
Но тема интерсная, спасибо.
Все таки все это от лешего, все эти финтифлюшки и гемор там не из-за докрутки функционала, а из-за того, что не существует общего поведения контролов. Датасорс девэкспрессовского комбобокса не биндится, например. MRUEdit не умеет искать по вхождению. CheckedComboboxEdit не позволяет биндиться на отмечаемые коллекции. В treelist нет галочек, опять же как класса — нужно подпихивать свои иконки. И т.п.
Короче все эти мелочи жутко досаджают — приходится писать тонну своих элементов. В конце концов пришло понимание — что да, это таки красиво и юзабельно, но блин, сколько же лишнего!
Фишка контрактов в изначальной интегрируемости?