Егор показал результат — доказал, что он крутой специалист, и Таня стала ему доверять. С доверием появилась и прозрачность. Теперь ему достаточно было описать работу в общих чертах, и Таня знала, что он занят делом.
Мне кажется или Егор сделал работу Тани, зачем Таню держат на фирме?
Если Егор решил одну бизнес область на отлично, означает ли это что Егор специалист? Специалист в программировании или в той области в которой непонятно что делает Таня?
Вопросы похожи на тролинг, но все таки я хочу понять для себя прав я или нет.
Проблема прозрачности — почему менеджеру не выпытать у программиста всё что можно? Что еще за проблема прозрачности.
Пункт А. Любой новый сотрудник находится здесь. У него есть минимальный запас доверия
На картинке наоборот, максимальный уровень доверия.
Несмотря на провал, меняться и рассказывать про новые задачи Петя не хотел. Пришлось расстаться
меняться это пассивный залог? Вопрос, а «Таня, директор по маркетингу» как то меняла программиста, сообщила что ожидает?
Что выгоднее сменить программиста на нового или немного (?) изменить конкретного программиста?
Была ли от Тани обратная связь? Если нет, то Таня интроверт?
Экстраверт умеет и любит работать в команде. На раз-два налаживает контакты и генерирует идеи на лету.
Интроверт продуктивен в тиши и одиночестве. Предпочитает общаться реже, лучше в чатике. Для идей ему нужно время, зато они будут взвешенными со всех сторон.
Рискую быть не оригинальным но несколько вопросов:
Экстраверт продуктивен в тиши и одиночестве, либо в шуме и толпе?
Экстраверт на раз-два налаживает контакты — а что значит налаживать контакты? Может экстраверту только показалось что он наладил контакт, а человек на против просто оказался вежливым?
Может два интроверта быстрее и прочнее установят контакт чем экстраверт с интровертом?
Экстраверт генерирует идеи на лету, и что, эти идеи просто выплеск бестолочи или идеи будут взвешенными со всех сторон?
Интроверт предпочитает общаться реже, лучше в чатике.
Точно реже, может просто не в толпе, по крайней мере не в той толпе где все галдят, а в той где слушают и понимают? Речь об интровертах не аутистах же?
тогда Lazy Loading точно не нужен!
Но это не значит что нужно убрать virtual у свойств, просто используйте Select() и явную загрузку данных (ToList(), ToArray()...).
А уже после явной загрузки данных, делайте в памяти что хотите.
Два варианта.
1) .Take(n).Skip(m); — то есть пейджинг.
2) .Select(x=> {x.Name, un = x.User.Name}).ToList().Select(x=>x.Name+" "+un);
синтаксис не помню, с головы привел, смысл в том что сначала тянем из базы массово нужную проекцию полей, а потом делаем конкатенацию строк.
Представим что в промежутке между загрузкой заказа из базы и обращением к свойству OrderLines содержимое заказа было изменено. В результате мы получим содержимое заказа на текущий момент, а не на момент загрузки самого заказа из базы.
Все таки неплохо было бы эти два предложения переписать/уточнить.
Представим что в промежутке между загрузкой заказа из базы и обращением к свойству OrderLines содержимое заказа было изменено в базе, в другой транзакции.
В результате мы получим содержимое заказа на текущий момент (что значит получим, заказ был на момент первого (и единственного) считывания, почему мы получим другой результат?), а не на момент загрузки самого заказа из базы. (Почему это вдруг?)
Если нет транзакции, а был изменен OrderLines, то получим несогласованные данные между Order и OrderLines.
В общем эти два предложения надо раскрыть подробнее.
Так оберните в одну транзакцию, да еще с каким нибудь «повышенным» уровнем изоляции, например Repeatable read.
Еще, например, почему бы не сделать что бы в
using(var context = new Context())
new Context() не стартовал бы себе транзакцию, либо не стартовать транзакцию еще как нибудь?
При этом подобные ошибки не так то просто отловить на этапе разработки/ревью и подобный код может выстрелить уже в боевой среде.
У меня в привычке всегда использовать SQL Profiler и тогда не приходится ломать голову над правильным составлением linq запросов, сразу видно если что то нужно поправить.
Отдыхает каждый час минут по пять и этот отдых — часть техники безопасности, без него работать невозможно.
Скорее 15 минут на каждый час.
Итого 6 часов за 8 часов, и то, только при условии если не мешают работать.
Но так как приходится общаться с коллегами, уточнять документацию и т д, то бывает и 4 часа в день не наработать (не накодить).
Я бы сказал что в хорошую неделю — два или три дня удается поработать по 6 часов чистого времени, а часто ни одного дня в 6 часов в течении недели.
В среднем, наверно 4 — 5 часов чистого времени в день, скорее 4 чем 5.
Если вы ошиблись в коде теста, значит вы ошиблись в выражении того, какое поведение вы считаете желаемым.
Вот кстати, ведь в реализации метода можно использовать больше или меньше условий чем подразумевает тест.
Инструменты покрытия, считают процент только по строкам кода, или еще и по количеству комбинации условий в операторе IF?
Если не ошибаюсь, Кнут шутил/утверждал что в любой программе, есть меньшая по объему корректная программа.
На практике все программы не идеальные, помимо того что они должны делать, они содержат какие то избытки либо недостатки логики.
Мне довелось работать на медицинском проекте, где по стандартнам необходимо 100% тестирование.
Так вот, в основном это были юнит тесты, которые тестировали не только ту работу, которая необходима для устройства, но и какой то левый непонятный код.
Поскольку был не TDD, то есть не сначала тесты, а сначала несколько лет писалась логика, потом, перед сдачей, выделили время на покрытие тестами.
Как это делалось — бралась ветка if(condition){block1}else{block2} и под условия писался юнит тест.
Что тестировал этот тест?
Все что мог, в том числе излишнюю логику и даже замораживал, а не тестировал, код тех баг, которые неосознанно в код внес программист.
Это была заморозка логики, а вовсе никакой нифига не тест.
Поскольку программы пишутся не минимальные то и 100% покрытия это абсурд.
То есть если видишь что у тебя 70% покрытия тестами, то думаешь ну и фиг с ним. Будут баги, на багу сделаю интеграционный тест, если % покрытия при этом увеличится то и хорошо, а если нет то и пошел этот процент в Ж.
Вот именно, не больше, не меньше.
Но разве это ценность?
Причем не значимая строчка кода, а просто строчка кода.
Мне думается это не совсем тот результат который я бы хотел.
Мне лично, удобно использовать Solitary (одинокий) UnitTests для TDD, для быстроты разработки. Изолированность класса тут то что надо.
А для тестирования системы необходим инструмент который тыкает на кнопки вместо пользователя, ну или хотя бы дергает сервисы по сценариям пользователя.
Я к тому что процент покрытия тестами это на мой взгляд достаточно бесполезная метрика.
Если Егор решил одну бизнес область на отлично, означает ли это что Егор специалист? Специалист в программировании или в той области в которой непонятно что делает Таня?
Вопросы похожи на тролинг, но все таки я хочу понять для себя прав я или нет.
Проблема прозрачности — почему менеджеру не выпытать у программиста всё что можно? Что еще за проблема прозрачности.
меняться это пассивный залог? Вопрос, а «Таня, директор по маркетингу» как то меняла программиста, сообщила что ожидает?
Что выгоднее сменить программиста на нового или немного (?) изменить конкретного программиста?
Была ли от Тани обратная связь? Если нет, то Таня интроверт?
Экстраверт продуктивен в тиши и одиночестве, либо в шуме и толпе?
Экстраверт на раз-два налаживает контакты — а что значит налаживать контакты? Может экстраверту только показалось что он наладил контакт, а человек на против просто оказался вежливым?
Может два интроверта быстрее и прочнее установят контакт чем экстраверт с интровертом?
Экстраверт генерирует идеи на лету, и что, эти идеи просто выплеск бестолочи или идеи будут взвешенными со всех сторон?
Точно реже, может просто не в толпе, по крайней мере не в той толпе где все галдят, а в той где слушают и понимают? Речь об интровертах не аутистах же?
Но это не значит что нужно убрать virtual у свойств, просто используйте Select() и явную загрузку данных (ToList(), ToArray()...).
А уже после явной загрузки данных, делайте в памяти что хотите.
1) .Take(n).Skip(m); — то есть пейджинг.
2) .Select(x=> {x.Name, un = x.User.Name}).ToList().Select(x=>x.Name+" "+un);
синтаксис не помню, с головы привел, смысл в том что сначала тянем из базы массово нужную проекцию полей, а потом делаем конкатенацию строк.
Представим что в промежутке между загрузкой заказа из базы и обращением к свойству OrderLines содержимое заказа было изменено в базе, в другой транзакции.
В результате мы получим содержимое заказа на текущий момент (что значит получим, заказ был на момент первого (и единственного) считывания, почему мы получим другой результат?), а не на момент загрузки самого заказа из базы. (Почему это вдруг?)
Если нет транзакции, а был изменен OrderLines, то получим несогласованные данные между Order и OrderLines.
В общем эти два предложения надо раскрыть подробнее.
Еще, например, почему бы не сделать что бы в
new Context() не стартовал бы себе транзакцию, либо не стартовать транзакцию еще как нибудь?
Итого 6 часов за 8 часов, и то, только при условии если не мешают работать.
Но так как приходится общаться с коллегами, уточнять документацию и т д, то бывает и 4 часа в день не наработать (не накодить).
Я бы сказал что в хорошую неделю — два или три дня удается поработать по 6 часов чистого времени, а часто ни одного дня в 6 часов в течении недели.
В среднем, наверно 4 — 5 часов чистого времени в день, скорее 4 чем 5.
Инструменты покрытия, считают процент только по строкам кода, или еще и по количеству комбинации условий в операторе IF?
Не только желаемого, но и инструмент фиксации случайно протестированных багов.
На практике все программы не идеальные, помимо того что они должны делать, они содержат какие то избытки либо недостатки логики.
Мне довелось работать на медицинском проекте, где по стандартнам необходимо 100% тестирование.
Так вот, в основном это были юнит тесты, которые тестировали не только ту работу, которая необходима для устройства, но и какой то левый непонятный код.
Поскольку был не TDD, то есть не сначала тесты, а сначала несколько лет писалась логика, потом, перед сдачей, выделили время на покрытие тестами.
Как это делалось — бралась ветка if(condition){block1}else{block2} и под условия писался юнит тест.
Что тестировал этот тест?
Все что мог, в том числе излишнюю логику и даже замораживал, а не тестировал, код тех баг, которые неосознанно в код внес программист.
Это была заморозка логики, а вовсе никакой нифига не тест.
Поскольку программы пишутся не минимальные то и 100% покрытия это абсурд.
Но разве это ценность?
Причем не значимая строчка кода, а просто строчка кода.
Мне думается это не совсем тот результат который я бы хотел.
Мне лично, удобно использовать Solitary (одинокий) UnitTests для TDD, для быстроты разработки. Изолированность класса тут то что надо.
А для тестирования системы необходим инструмент который тыкает на кнопки вместо пользователя, ну или хотя бы дергает сервисы по сценариям пользователя.
Я к тому что процент покрытия тестами это на мой взгляд достаточно бесполезная метрика.