Обычно по уровню ответственности. Junior — решает очень локальную тактическую задачу. Middle — уровень конкретных задач. Senior — решает проблемы (уже может поговорить на тему предметной области с PM, дать свои рекомендации и главное — отвечать за решение проблемы). Team Lead -отвечает за всю систему целиком.
Например — мы пишем игру
Нарисовать красный пункт меню с текстом «Поехали!» — задача джуниора
Сделать полоски здоровья и маны — задача мидла
Написать систему поиска пути для юнитов — задача сеньера
Написать игру — задача тим лида
Есть несколько замечаний:
1. Ну идея определять время жизни объекта в том месте где ты его инжектишь — как минимум странная. Клас по идее вообще не должно волновать — какое время жизни у объекта — главное он есть и доступен.
2.
Объект времени исполнения (Runtime). Все клиенты используют один и тот же объект, который может изменяться во время работы программы.
Очень странное поведение. Я не могу придумать ни одной идеи где подобный подход был-бы оправдан. Плюс он создает кучу проблем (на вскидку — синхронизация переменных внутри класса, обновление значений во всех созданных объектах, что делать с тем от чего зависит этот объект).
3. Инжектить в поля — это моветон. Мешает использовать ваш объект без DI фреймворка, и делает зависимости класса менне явными (плюс много черной магии)
4. Макросы — больше черной магии в коде, которую фиг поймешь, фиг отладишь и даже затрейсишь.
Вообще статическая типизация и DI дружат очень хорошо (как раз с динамической намного больше проблем). Просто в С++ не достает средств интроспекции чтобы сделать все красиво. Посмотрите например на Dagger для Java (http://square.github.io/dagger/) он мало того что работает поверх языка со статической типизацией, как еще и проверят весь граф объектов на момент компиляции.
Имхо в C# есть 3 вещи которые к сожалению C++ пока не снились и которые очень сильно ускоряют разработку:
1) Нормальный туллинг (Отличный отладчик в VS и ReSharper + NuGet). Ничего подобного уровня в C++ просто не существует. Блин я 2014 году экосистема у которой нет управления зависимостями — это полный… (и не надо мне говорить про CMAKE например — тот еще ужос)
2) Языковые возможности которые дают писать, предсказуемый и читабельный код (Async-Await, Generics, LINQ). Этого крайне не хватает.
3) Библиотеки. Я промолчу про стандартную библиотеку. Но без Autofac, WCF, WPF, MEF и еще череды отлично задизайненых и сделанных библиотек разработка оказывается очень тяжелой. Да у C++ есть boost — но лучше бы его не было. В этой мешанине классов, подходов и темплейтов очень сложно разобраться. Имхо единственная логичная библиотека на C++ это stl. Но в ней очень маленький набор примитивов.
В это месте вы можете вернутся по тексту назад и поменять C# на Java. Результат будет практически тот-же (поменяются названия библиотек и языковые возможности).
В общем, надо на C++ уметь работать — и тогда никакого желания на C# переходить не возникнет.
Эта фраза мне напоминает — вобщем надо уметь водить тогда с 9ки на BWM желаниея пересесть не возникнет.
Это далеко не так. (Я при это не сравниваю С++ с 9кой а C# с BMW, просто хочу показать на некорректность вашей фразы)
нам пришлось бы реализовать 6 полей вместо одного, принимая решение о том, что показывать, а что нет за уровень представления.
И я абсолютно за такой подход. ViewModel это модель View. Они неразрывно связанны. Единственная разница заключается в том что уровень ViewModel очень просто тестировать, а вот View слой тестировать достаточно сложно. Ну и separation of concern -> логика View уходит во ViewModel, а вот стиль отображения остается во View. В моей практике — так получалось проще.
Вообще там есть опции типа «зарплата больше 67.5к в год или 5 лет опыта» == «диплом» но они вроде как не приняты. Работодатели на счет диплома не особо беспокоятся и переживать из-за этого не стоит.
Общался с дамой из Blue Card программы, это 5 лет подтвержденного опыта заменяют диплом.
Камрады! Сколько можно писать хрень что сделано у нас, если у нас только собрано?!
Действительно. А ну немедленно прекратите!
Вас как-то не задевает что компоненты серверов HP произведенны далеко не только HP. Тоже самое с миллионом других продуктов. Важно кто сделал ПРОДУКТ, а не его составляющие.
Тем что очень тяжело автоматически хеджироватся с него, есть несколько бриджей для ECN (упомянутый Currenex например), но все равно все криво и косо.
Интересно, что мешает использовать ее не-кухонным брокерам, на рынке фьючерсов/акций напр?? Ну кроме отсутствия 'стакана' — который вобщем-то не очень и нужен, если вы — не скальпер…
Тем что это MT. Он вообще не знает нифига о площадке торгов например. Акции на разных площадках могут иметь разную цену.
Ну и это — известная фича МТ, за которую его обожают кухни — возможность руками добавлять квоты. Очередной раз когда у вас лимит слетят на спайке — задумайтесь о том — насколько это крутой софт :)
Слышал звон — не знаю где он
Системы прайсинга и HFT настолько далеки от бухгалтерского ПО, насколько ваша игра от программирования реальной ракеты для полета на Марс. И там и там космос, но на столько разный…
Да и структуру и класс (это одно и тоже вообщем) можно создать как в куче так и на стеке. Эта приятная особенность С++ мне известна. Я намекал SVLad о том что пользователи намного чаще хотят C#-style структур в Java. Особенно те кто пытается снизить нагрузку на GC.
То что она создестя на куче а не в стеке не важно? Если нет то все ок. Но автору коментария (и многим кому приходится оптимизировать работу с памятью) важно.
Баротравма легких вообще не связанна с кесонной болезнью (растворение азота в тканях а потом его обратное превращение в газ при уменьшении давления), хотя кесонка тоже возможна при резкой разгеметизации (растворенный азот все равно есть в такнях, просто его концентрация ниже). И тут смысл не в абсолютных величинах давления, а в его перепаде. На баротравму можно нарватся при перепаде давления в 2-3 раза (от 3 атм на 20 метрах до 1 амт на поверхности). А вы говорите о перепаде давления практически в бесконечность раз. Мелкие баротравмы — ушей и пазух при такой разгерметизации будут 100% — для них очень маленький перепад нужен.
Да вы впринципе все правильно говорите. Господам неверующим — погуглите что такое баротравма легких. Есть такой эффект при знаятии дайвингом. Здесь будет тоже самое.
Хотя я нежно люблю Objective-C за ясность, некоторую приятную мнгословность и безусловную логичность, в асинхронном программирование C# куда выразительней.
Например — мы пишем игру
Нарисовать красный пункт меню с текстом «Поехали!» — задача джуниора
Сделать полоски здоровья и маны — задача мидла
Написать систему поиска пути для юнитов — задача сеньера
Написать игру — задача тим лида
1. Ну идея определять время жизни объекта в том месте где ты его инжектишь — как минимум странная. Клас по идее вообще не должно волновать — какое время жизни у объекта — главное он есть и доступен.
2.
Очень странное поведение. Я не могу придумать ни одной идеи где подобный подход был-бы оправдан. Плюс он создает кучу проблем (на вскидку — синхронизация переменных внутри класса, обновление значений во всех созданных объектах, что делать с тем от чего зависит этот объект).
3. Инжектить в поля — это моветон. Мешает использовать ваш объект без DI фреймворка, и делает зависимости класса менне явными (плюс много черной магии)
4. Макросы — больше черной магии в коде, которую фиг поймешь, фиг отладишь и даже затрейсишь.
Вообще статическая типизация и DI дружат очень хорошо (как раз с динамической намного больше проблем). Просто в С++ не достает средств интроспекции чтобы сделать все красиво. Посмотрите например на Dagger для Java (http://square.github.io/dagger/) он мало того что работает поверх языка со статической типизацией, как еще и проверят весь граф объектов на момент компиляции.
1) Нормальный туллинг (Отличный отладчик в VS и ReSharper + NuGet). Ничего подобного уровня в C++ просто не существует. Блин я 2014 году экосистема у которой нет управления зависимостями — это полный… (и не надо мне говорить про CMAKE например — тот еще ужос)
2) Языковые возможности которые дают писать, предсказуемый и читабельный код (Async-Await, Generics, LINQ). Этого крайне не хватает.
3) Библиотеки. Я промолчу про стандартную библиотеку. Но без Autofac, WCF, WPF, MEF и еще череды отлично задизайненых и сделанных библиотек разработка оказывается очень тяжелой. Да у C++ есть boost — но лучше бы его не было. В этой мешанине классов, подходов и темплейтов очень сложно разобраться. Имхо единственная логичная библиотека на C++ это stl. Но в ней очень маленький набор примитивов.
В это месте вы можете вернутся по тексту назад и поменять C# на Java. Результат будет практически тот-же (поменяются названия библиотек и языковые возможности).
Эта фраза мне напоминает — вобщем надо уметь водить тогда с 9ки на BWM желаниея пересесть не возникнет.
Это далеко не так. (Я при это не сравниваю С++ с 9кой а C# с BMW, просто хочу показать на некорректность вашей фразы)
И я абсолютно за такой подход. ViewModel это модель View. Они неразрывно связанны. Единственная разница заключается в том что уровень ViewModel очень просто тестировать, а вот View слой тестировать достаточно сложно. Ну и separation of concern -> логика View уходит во ViewModel, а вот стиль отображения остается во View. В моей практике — так получалось проще.
Это не самый лучший подход. Тесты получаются не так выразительны как могли-бы быть. Гораздо лучше делать свойство типа Visibility во View Model
Общался с дамой из Blue Card программы, это 5 лет подтвержденного опыта заменяют диплом.
Действительно. А ну немедленно прекратите!
Вас как-то не задевает что компоненты серверов HP произведенны далеко не только HP. Тоже самое с миллионом других продуктов. Важно кто сделал ПРОДУКТ, а не его составляющие.
Тем что это MT. Он вообще не знает нифига о площадке торгов например. Акции на разных площадках могут иметь разную цену.
Ну и это — известная фича МТ, за которую его обожают кухни — возможность руками добавлять квоты. Очередной раз когда у вас лимит слетят на спайке — задумайтесь о том — насколько это крутой софт :)
Слышал звон — не знаю где он
Системы прайсинга и HFT настолько далеки от бухгалтерского ПО, насколько ваша игра от программирования реальной ракеты для полета на Марс. И там и там космос, но на столько разный…
Хотя я нежно люблю Objective-C за ясность, некоторую приятную мнгословность и безусловную логичность, в асинхронном программирование C# куда выразительней.
Достаточно часто. Плюс задержки на 15-20 минут это вообще норма.