vsb>Мне кажется, в РФ не может быть 7% безработицы. По простой причине — для того, чтобы не умереть, нужно жильё и еда. Бесплатно деньги в РФ не раздают. И жильё тоже не раздают. Поэтому люди без работы просто умрут.
В деревне вполне, люди в 90-е так и жили. Жильё — частный дом, еда с огорода, дрова напилены в соседнем лесу, на остальные расходы — пенсии пожилых.
Здравствуйте, Gradiens, Вы писали:
G>Записи читались из базы, классы инстанцировались, поля проставлялись через отражение.
Это не легаси, а абсолютно нормальная практика. Предлагаешь вместо этого читать и присваивать все вручную?
Похоже, что вам с barn_czn предстоит еще очень многое для себя открыть.
Здравствуйте, _AND, Вы писали:
vsb>>Мне кажется, в РФ не может быть 7% безработицы. По простой причине — для того, чтобы не умереть, нужно жильё и еда. Бесплатно деньги в РФ не раздают. И жильё тоже не раздают. Поэтому люди без работы просто умрут.
_AN>В деревне вполне, люди в 90-е так и жили. Жильё — частный дом, еда с огорода, дрова напилены в соседнем лесу, на остальные расходы — пенсии пожилых.
Это не безработица, это самозанятость.
Ну и если относительно внезапно несколько миллионов людей станут безработными, вряд ли в деревне найдётся место для них всех. Это пока там всё стоит копейки (хотя для безработного даже несколько сотен тысяч рублей может быть неподъёмной ценой), а при возрастании спроса цены улетят в облака. Да и уметь нужно жить в деревне. Одно дело жить имея в кармане денег на несколько лет пропитания или пассивный доход: снесла курочка яичко — хорошо, сдохли все курочки, ну неприятно, купим у соседей яички, а другое дело когда неурожай означает, что у тебя вообще нуль. Особенно с возросшим уровнем преступности. В 90-е с нашими соседями была история, когда приехали воры к ним на дачу, подпёрли дверь вилами, показали ножик забузившему в окне деду, спокойно собрали всю картошку и уехали. Вот тебе и еда с огорода.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Closer, Вы писали:
C>>Опят же, как и всегда, тут надо включать голову т.е. если вы разрабатываете небольшой проект и на 100% уверены что не будете публиковать интерфейсы, то можно и List везде использовать (в крайнем случае сделаете небольшой рефакторинг если потребуется реализацию поменять).
C>Именно, надо включать голову, а не лепить интерфейсы везде-везде-везде. Кроме того, остается открытым вопрос, что плохого в "public int MyInt;"
Если не нужна реактивность, то вполне сойдет.
Чем меньше кода тем он проще.
насчет коллекций есть хорошая практика делать именованные типа Persons, если уж совсем трушно, то доступ к данным ограничить нужными методами.
Но это же лишняя работа.
А так да реализацию проще будет менять и код опять же станет проще: IList<Person> длиннее Persons в два раза.
В целом в сообществе C# преобладает культура "простых решений", ЯП к этому подталкивает,
если допустим перейти на ФЯП типа F# там уже культура кода гораздо выше, хотя тоже есть Person list,
но в то же время активно используются алиасы, которые делают простым объявление доменных типов
type Persons = Person list
let persons = Persons [
{
Id = 1
Name = "Alice" }
]
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Gradiens, Вы писали:
G>>Записи читались из базы, классы инстанцировались, поля проставлялись через отражение.
C>Это не легаси, а абсолютно нормальная практика. Предлагаешь вместо этого читать и присваивать все вручную?
Предлагаю, во-первых, использовать ORM а не изобретать велосипед на костылях.
А во-вторых, основная претензия — это не наличие данных, которые переливаются в поля. Это наличие записанных в безе _имен_ полей, классов, пространств. То есть сам маппинг хранится в базе.
И при попытке хоть как-то отрефакторить классы (что-то переименовать, потому что имена вида _OPS_Material_Type раздражают, или переместить) все падает, причем в совершенно непредсказуемых местах.
C>Похоже, что вам с barn_czn предстоит еще очень многое для себя открыть.
И не только нам. Кое-кому другому тоже неплохо было бы не судить опрометчиво. Как говорилось в Адвокате дьявола "тщеславие — мой самый любимый из грехов"
vsb>Мне кажется, в РФ не может быть 7% безработицы. По простой причине — для того, чтобы не умереть, нужно жильё и еда. Бесплатно деньги в РФ не раздают. И жильё тоже не раздают.
Но по факту, обеспеченность своим жильем в РФ — наверное, самая высокая в мире. Безо всяких ипотек и пр. форм мозгое.ства. И налоги на него тоже смешные, по сравнению со Штатами особенно.
_>Я вас понял — новичок должен пострадать. Наверно это ваш опыт, но не мой. Даже когда я был джуном и пришел в очень известную канадскую компанию — мне дали доступ на все сразу после подписания NDA.
В этом месте любой банк смотрит на Вас и тихо ржет во все голоса СБ и ДИБ
K>Есть мнение, что наружу стоит выставлять интерфейсный тип IList<> вместо конкретного класса List<>. То же самое касается и других стандартных контейнеров типа IDictionary<,> vs Dictionary<,>.
Ну, это уже на конкурсе строевой подготовки тянуть мысок и нагуталинивать сапоги, по-моему.
Здравствуйте, Glestwid, Вы писали:
vsb>>Мне кажется, в РФ не может быть 7% безработицы. По простой причине — для того, чтобы не умереть, нужно жильё и еда. Бесплатно деньги в РФ не раздают. И жильё тоже не раздают.
G>Но по факту, обеспеченность своим жильем в РФ — наверное, самая высокая в мире.
Если это и так (есть статистика?), то скорей это наследие кровавого совка, который подарил всем хотя бы по коммуналке. Но подарки рано или поздно развалятся, вроде уже разваливаются, и тут всё вернётся на круги своя, кмк.
G>Безо всяких ипотек и пр. форм мозгое.ства.
Степень мозгоества ипотеки зависит от экономики. Если у тебя там проценты смешные, экономика стабильная, ты ходишь на работу 30 лет и 30 лет получаешь примерно одну зарплату, то бишь у тебя вся жизнь распланирована и в ней ничего такого особо не может случиться, а если даже и случится, то всё это ещё и застраховано за те же копейки, почему бы и нет.
G>И налоги на него тоже смешные, по сравнению со Штатами особенно.
Это да, вообще этого не понимаю. В Казахстане то же самое, за квартиру плачу по-моему рублей 50 налогов, за машину около 500. А вот как ИП уже плачу около 50 000, и это ещё если НДС не считать с покупок. Социальное государство.
Здравствуйте, Gradiens, Вы писали:
G>Предлагаю, во-первых, использовать ORM а не изобретать велосипед на костылях.
Ты не писал, что там был велосипед. Любой ORM прекрасно подходит под твое описание.
G>А во-вторых, основная претензия — это не наличие данных, которые переливаются в поля. Это наличие записанных в безе _имен_ полей, классов, пространств. То есть сам маппинг хранится в базе.
А про это ты ничего не писал. Если основная претензия в этом — значит, про это и надо было писать.
Здравствуйте, varenikAA, Вы писали:
AA>насчет коллекций есть хорошая практика делать именованные типа Persons, если уж совсем трушно, то доступ к данным ограничить нужными методами.
Зачем? Чтобы тем, кто будет пользоваться этими коллекциями, жизнь медом не казалась?
Мне например регулярно хочется найти автора какого-нибудь NameValueCollection, сложить в сумку паяльник и тиски и поехать преподать ему урок хорошего кодирования.
_>Что это было, зачем это им? Не понимаю, просто шлю проклятья.
у меня самого бывали такие проколы в работе. Ищешь человека на должность (а это иногда может занимать несколько месяцев), вот он выходит на работу, а у тебя в спринте нет ни одной подходящей задачи (где не надо глубоко знать предметную область, средства разработки, етс). Ну тогда даешь какую-то заведомо легкую задачу, которая не сильно и горит, но плавно погрузит человека в проект. Иногда такие задачи никогда не доходили даже до релиза (да, бывало), иногда это были как раз ресечи разных сервисов. Такая ситуация не красит менеджмент, но бурная реакция на такую заминку меня бы, как работодателя, насторожила.
отдельно отмечу про powerpoint — у меня такие же диалоги были "что это не входит в мой job description". Закончилось тем, что в job description в "написание документации" дописали "(включая презентации)", но это лишь одна из граней проблемы. Сама же проблема заключается в том, что кроме сферического программирования, есть еще реальный мир, с которым надо как-то кому-то взаимодействовать. Когда компания на старте, то у каждого члена команды есть выбор чем заниматься — менеджментом, комплаенсом, продажами, поддержкой, маркетингом, партнерствами, супортом, етс. Многим нравится контакт с внешним миром и общение с людьми, многим — нет. В этом нет ничего ни хорошего, ни плохого, но когда ты выбираешь кого-то на повышение по должности, то, конечно, будешь брать человека, который умеет общаться с другимим людьми (не обязательно техническими).
Сюда же можно записать реплики про руководство, которое ничего не понимает в программировании. Среди моих знакомых почти все основатели fintech компаний не написали ни одной строки кода в жизни. А зачем, если есть СТО, который умеет говорить человеческим языком?
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, varenikAA, Вы писали:
AA>>насчет коллекций есть хорошая практика делать именованные типа Persons, если уж совсем трушно, то доступ к данным ограничить нужными методами.
C>Зачем? Чтобы тем, кто будет пользоваться этими коллекциями, жизнь медом не казалась? C>Мне например регулярно хочется найти автора какого-нибудь NameValueCollection, сложить в сумку паяльник и тиски и поехать преподать ему урок хорошего кодирования.
Я же говорю культура. Кто к чему привык.
На самом деле C# не очень поощряет к созданию системы типов для решения конкретной задачи.
Все держится на примитивах базовой библиотеки.
Это источник множества багов. Особенно когда внезапно требуется сменить один тип на другой,а сравниваются не типы конкретные, а какой-нибудь IRecord { int Id {get;set;}.
По сути, то что должен делать язык программисту приходится делать самому — держать в голове и контролировать всю систему типов конкретной модели.
С появлением рекордов возможно ситуация слегка улучшится, но не кардинально.
Не зря его назвали "СИ".
Другой пример enum — алиас к int.
enum Status{
Open, Close
}
var x = (enum)42;
WriteLine(x); //=> print 42
сработает. вот такая отличная система типов в типобезопасном языке.
G>>А во-вторых, основная претензия — это не наличие данных, которые переливаются в поля. Это наличие записанных в безе _имен_ полей, классов, пространств. То есть сам маппинг хранится в базе. C>А про это ты ничего не писал. Если основная претензия в этом — значит, про это и надо было писать.
Так про это и было написано -- структура класса хранилась в бд. Т.е. что либо поменять без оглядки на содержимое (не структуру) бд нельзя.
Из недавнего: я вот тоже столкнулся с такими полями. Контекстно поискал использование вне класса (я же уже знаю, что такие штуки могут использоваться через отражение). Не нашел. А когда сделал приватными — внезапно приложение стало падать в случайных местах. О казалось, в базе данных были записи с именами этих полей и этих классов. Записи читались из базы, классы инстанцировались, поля проставлялись через отражение.
Здравствуйте, varenikAA, Вы писали:
AA>Я же говорю культура. Кто к чему привык. AA>На самом деле C# не очень поощряет к созданию системы типов для решения конкретной задачи.
Серьезно, а к чему он тогда поощряет?
AA>Другой пример enum — алиас к int.
Это не алиас к int. Это именование какого-то целого, не обязательно int
AA>
AA>enum Status{
AA>Open, Close
AA>}
AA>var x = (enum)42;
AA>WriteLine(x); //=> print 42
AA>
AA>сработает. вот такая отличная система типов в типобезопасном языке.
А вот кстати, дельное замечание. Возможно даже исключение бросать в данном случае.
Здравствуйте, Sharov, Вы писали:
S>Так про это и было написано -- структура класса хранилась в бд. Т.е. что либо поменять без оглядки на содержимое (не структуру) бд нельзя. S>
S>Из недавнего: я вот тоже столкнулся с такими полями. Контекстно поискал использование вне класса (я же уже знаю, что такие штуки могут использоваться через отражение). Не нашел. А когда сделал приватными — внезапно приложение стало падать в случайных местах. О казалось, в базе данных были записи с именами этих полей и этих классов. Записи читались из базы, классы инстанцировались, поля проставлялись через отражение.
Я просто подумал, что самом деле имеется в виду совпадение имен классов/полей в проге и БД. Слишком косноязычно все сформулировано. Я бы написал просто — "использовалась самопальная кривая ORM".
Здравствуйте, varenikAA, Вы писали:
AA>Это источник множества багов. Особенно когда внезапно требуется сменить один тип на другой,а сравниваются не типы конкретные, а какой-нибудь IRecord { int Id {get;set;}.
Есть немало вещей, которые приводят к множеству багов, но эта — даже не в топ 10.
AA>Другой пример enum — алиас к int. AA>
AA>enum Status{
AA>Open, Close
AA>}
AA>var x = (enum)42;
AA>WriteLine(x); //=> print 42
AA>
AA>сработает. вот такая отличная система типов в типобезопасном языке.
Есть такая проблема в дизайне, но нормальные люди просто не приводят int к enum.
C>Я просто подумал, что самом деле имеется в виду совпадение имен классов/полей в проге и БД. Слишком косноязычно все сформулировано. Я бы написал просто — "использовалась самопальная кривая ORM".
Здравствуйте, Codealot, Вы писали:
C>Есть такая проблема в дизайне, но нормальные люди просто не приводят int к enum.
Данные могут откуда угодно прийти, нужно будет вручную проверять. эту проверку легко забыть.
понятно, что подобные строгости нужны более менее опытным кодерам.
Но рано или поздно человеческий фактор срабатывает.
Т.е. строгости в сишарпе мало, в отличии от его младшего брата F#
type Status = Open | Close
let getStatus v =
match v with
| 0 -> Open
| 1 -> Close
| v -> failwithf "%d не является значением типа Status" v
(*
val getStatus : v:int -> Status
> getStatus 1;; => val it : Status = Close
> getStatus 0;; => val it : Status = Open
> getStatus 11;; => System.Exception: 11 не является значением типа Status
*)
