То, что описано в топике, это часть процесса, связанная непосредственно с разработкой конечного функционала. Еще взаимодействие с заказчиком, аналитика, и т.п.
Хм. Посмотрите с точки зрения разработчика на 2 и 3ий пункт.
Вот к примеру я, разработчик-раздолбай. У меня есть 5 незакрытых задач, по которым мне надо произвести работы. Приходит ПМ, весь такой модненький, говорит — чувак, гляди. У нас есть новая задачка. Сделай ее по workflow. Окей. Я смотрю — ха, ну, задачка то дерьмо, сделаю быстро. Но я ведь хитрый, я не люблю большого брата. Срок поставлю больше, чтобы прикрыть свою задницу и успеть сделать какую-нибудь ту из пяти задач.
Я к тому, что разработчики будут врать в свою пользу, какими бы прилежными они не были. Поэтому я согласен, что здесь имеет место быть перевод ответственности с ПМа на разработчиков. Причем, сам же ПМ подставляется. В худшем случае он разработчиков уволит, он и новую работу найдут, потому что они производят код, а ПМ будет с пробитым проектом.
Последнее — на мозоль наступаете. Почему то это такая долгоиграющая болезнь российского софтостроения, когда к разработчику относятся как к производственному материалу. Он производит код, критерии к этому коду с точки зрения отечественного софтопроизводителя — максимально простой, максимально быстро, максимально одноразово.
Это уж разработчик сам старается себе работу облегчить и накопить себе инструментарий. Почему-то (точнее, понятно, почему) самые лучшие фирмы (для разработчика), это те, где менеджмент каким-то образом связан с западом.
В этом случае, когда задачи большие и их несколько сложно разбить (например, пишем здоровенный веб-метод для портала), помогают scrum-митинги. Это так, к слову. Менеджер или лид прибегает, слушает что сделано, помечает прогресс. Заодно можно друг другу помочь трудности обходить.
У нас ПМ такой:) Почему это долго делать? Потому что сложно. Что, сложно одно поле в базу добавить? Вот я когда работал на дельфях в 95-м году… блаблабла.
Или — вот, почему так много ошибок в программе? Почему не тестируете? Потому что требования каждый раз меняются, а если не меняются то приходят новые. Не успеваем. Ну, не понимает человек что такое качество ПО.
Так и живем:) В результате разработчиков выгоняют работать в выходные, потому что управление накосячило. Но с точки зрения управления, все верно, оно думает что это мы такие дебилы:) Бесконечная война.
Сейчас перечислю то, шо мне говорил мсье разработчик доменных моделей:
— Есть табличка Dictionary. Туда надо уложить граф объектов примерно четырех уровней вложенности (класс линейный словарь-класс иерархический словарь-класс словарь с ключем на другую таблицу-специфический класс словарь с ключем на другую таблицу плюс кучка энумов-пропертей в довесок). Я тогда мычал (мычал, потому что специализируюсь в клиентской части), что дескать, наследование есть, но надо в нем разобраться, и т.п. Сейчас те коменты, что выше, дают надежду на решение этой задачки.
— Задача срезок данных. Требуется загрузить не весь граф объектов целиком, а три связи. Например, ассоциации-ключ ассоциации-тип ключа (линейный словарь). Ну и сюда же до кучи (цитата) «вот возвращает у меня хранимка 5 табличек. Как я объясню EF'у, что у меня именно конкретные объекты переданы, а то и только ченжи».
— Вон народ выше на лэйзи лоад ругается. Надо мне, предположим, иерархический справочник (возьмем тот же ОКТМО со всеми муниципальными образованиями), пользователю давать открывать в дереве. Ну, я не спорю, можно извернутся и каким-то образом через линк подгружать объекты в дерево, но опять же, это надо пробовать, это надо настаивать что оно будет работать, убеждать и т.п.
Сами понимаете, как тяжело в наш нынешний век недоверия новым технологиям вводить инновационность:)
А, понял.
Т.е. например, есть класс Car, есть наследник ColoredCar, в наследние дополнительное проперти висит — Color. В таблице у записей соотв. Car поле Color null. Мы загружаем все Car, и EF прочитает все Color, хотя вроде бы и не требовалось. Так?
О, спасибо!
Не совсем понятно, чем иерархия отличается от конкретного типа? И там и там граф объектов ложится в одну таблицу, правильно? Во втором случае мы граф бьем на подграфы, так?
Вот и хочу узнать, будет ли у меня, например, работать синхронизированный синглтон (это где в момент гета лочится объект синхронизации) в асп-нет приложении, если приложением будет пользоваться много пользователей?
Стоп стоп стоп. Вы упускаете очень критический момент в разработке. Сделать своему не согласовав решение с аналитиком или с заказчиком — это значит огрести очень большой риск выкинуть то, что сделали. Вы не правы:) По-своему, не значит правильно и уж точно не значит так, как нужно заказчику (в конце концов, он же приемщик и он платит деньги)
Вы никогда не работали с государственными заказчиками?:) Поверьте, с ними лучше не общаться с точки зрения компромиссов, я молчу про изменяющиеся в ходе разработки требования. Да в вообще говоря, вы про какие компромиссы?:) Легкие хотелки можно отфуболивать, но что касается написанного тз, то тут уж прости-подвинься, но изволь исполнить. Поэтому, имхо, хорошая архитектура, это такая архитектура, которая максимально гибкая. EF, к сожалению, такой гибкости не проявил, очень надеюсь, что пока не проявил и к 2010 студии ее дошлифуют.
Простите, а возможны применения технологий многопоточности в асп-нет приложении? Сам я занимаюсь толстыми клиентами, но возможно, скоро придется перпрофилироваться:)
Во первых, вам повезло:)
Во вторых, вы не совсем правы. Аналитики, по большему счету, те, которые работают с заказчиком, документы пишут для заказчика. Если обычному программисту дать почитать то, что говорят аналитики, то у него как минимум зашевелятся волосы, ибо реализовать то, что пишут аналитики для заказчика нереально. Но однако, полным виженом системы могут обладать только те, кто общаются с заказчиком и вполне реально, что завтра вот та симпатичная девочка Таня подойдет к тебе и скажет «Илья, а нам нужно чтобы вот эта хренька работала вот так!» И ничего не останется сделать, как утерется:)
Вот к примеру я, разработчик-раздолбай. У меня есть 5 незакрытых задач, по которым мне надо произвести работы. Приходит ПМ, весь такой модненький, говорит — чувак, гляди. У нас есть новая задачка. Сделай ее по workflow. Окей. Я смотрю — ха, ну, задачка то дерьмо, сделаю быстро. Но я ведь хитрый, я не люблю большого брата. Срок поставлю больше, чтобы прикрыть свою задницу и успеть сделать какую-нибудь ту из пяти задач.
Я к тому, что разработчики будут врать в свою пользу, какими бы прилежными они не были. Поэтому я согласен, что здесь имеет место быть перевод ответственности с ПМа на разработчиков. Причем, сам же ПМ подставляется. В худшем случае он разработчиков уволит, он и новую работу найдут, потому что они производят код, а ПМ будет с пробитым проектом.
Это уж разработчик сам старается себе работу облегчить и накопить себе инструментарий. Почему-то (точнее, понятно, почему) самые лучшие фирмы (для разработчика), это те, где менеджмент каким-то образом связан с западом.
Или — вот, почему так много ошибок в программе? Почему не тестируете? Потому что требования каждый раз меняются, а если не меняются то приходят новые. Не успеваем. Ну, не понимает человек что такое качество ПО.
Так и живем:) В результате разработчиков выгоняют работать в выходные, потому что управление накосячило. Но с точки зрения управления, все верно, оно думает что это мы такие дебилы:) Бесконечная война.
— Есть табличка Dictionary. Туда надо уложить граф объектов примерно четырех уровней вложенности (класс линейный словарь-класс иерархический словарь-класс словарь с ключем на другую таблицу-специфический класс словарь с ключем на другую таблицу плюс кучка энумов-пропертей в довесок). Я тогда мычал (мычал, потому что специализируюсь в клиентской части), что дескать, наследование есть, но надо в нем разобраться, и т.п. Сейчас те коменты, что выше, дают надежду на решение этой задачки.
— Задача срезок данных. Требуется загрузить не весь граф объектов целиком, а три связи. Например, ассоциации-ключ ассоциации-тип ключа (линейный словарь). Ну и сюда же до кучи (цитата) «вот возвращает у меня хранимка 5 табличек. Как я объясню EF'у, что у меня именно конкретные объекты переданы, а то и только ченжи».
— Вон народ выше на лэйзи лоад ругается. Надо мне, предположим, иерархический справочник (возьмем тот же ОКТМО со всеми муниципальными образованиями), пользователю давать открывать в дереве. Ну, я не спорю, можно извернутся и каким-то образом через линк подгружать объекты в дерево, но опять же, это надо пробовать, это надо настаивать что оно будет работать, убеждать и т.п.
Сами понимаете, как тяжело в наш нынешний век недоверия новым технологиям вводить инновационность:)
Т.е. например, есть класс Car, есть наследник ColoredCar, в наследние дополнительное проперти висит — Color. В таблице у записей соотв. Car поле Color null. Мы загружаем все Car, и EF прочитает все Color, хотя вроде бы и не требовалось. Так?
Не совсем понятно, чем иерархия отличается от конкретного типа? И там и там граф объектов ложится в одну таблицу, правильно? Во втором случае мы граф бьем на подграфы, так?
Во вторых, вы не совсем правы. Аналитики, по большему счету, те, которые работают с заказчиком, документы пишут для заказчика. Если обычному программисту дать почитать то, что говорят аналитики, то у него как минимум зашевелятся волосы, ибо реализовать то, что пишут аналитики для заказчика нереально. Но однако, полным виженом системы могут обладать только те, кто общаются с заказчиком и вполне реально, что завтра вот та симпатичная девочка Таня подойдет к тебе и скажет «Илья, а нам нужно чтобы вот эта хренька работала вот так!» И ничего не останется сделать, как утерется:)