Вот не согласен. using, lock — это все сахар от компилятора, я буду уверен, что возьму любой другой проект и увижу такие инструкции — они будут работать 100% однообразно. А сейчас мы ведем речь о разного рода поделках отдельных людей, без стандартов, без согласований и т.д. Которые могут решать одну и туже задачу, но в разных проектах — накладывать совершенно различные ограничения и приводить к неожиданным результатам.
Проблема в том, что термин «понятность» очень субъективен. И степень его субъективности всегда повышается с применением таких вот «фишек», которые отступают от общепринятых практик и становятся зависимыми от автора, который их создал.
делать руками то, с чем отлично справляется машина
Автоматизировать нужно до такой степени, до которой сохраняется понятность кода, а то можно придти к такому варианту, что конечный результат будет отлично читаться машиной, а вот другому человеку все останется на уровне «абрыкадыбры», которое проще выкинуть и сделать с нуля, чем попытаться внести правки.
А чудак у них update не весь выделило, забыло where
Какой же он чудак? В систему, минуя API, разрешали лезть руками, что не очень профессионально. Такое может с кем угодно случится. Не зря придумали публичные API, а нарушение инкапсуляции рано или поздно приведет к выстрелу в голову.
Сейчас так и делаю, смотрю кто решал те или иные проблемы на github, развивается ли проект и т.д. и внедряю по возможности.
boooring
Ну не знаю, мне вот в бизнес интересней вникать, чем в очередную новомодную библиотеку. Точнее интереснее когда применение некоторых практик помогают эффективней решать проблемы бизнеса.
У написание своего велосипеда должны быть причины. Одно дело, когда причина — так что нет аналогов или аналоги не очень удовлетворяют требованием. И совершенно другое, когда авторам велосипедов просто лень разбираться в чужом коде/подходе. Вот второй случай я и считаю самым неудачным для проекта в целом.
идеальной стадии для экспериментов
Microsoft выпустили джина из бутылки. Это очень мощный инструмент, неправильное применение которого на стадии экспериментов может превратить в будущем проекты в совершенно не поддерживаемое легаси.
И что до вопроса по C#, да я бы предпочел в будущем проекты, которые используют стандартные и широко зарекомендованные приемы, чем велосипеды, только в которые требуется дополнительное длительное погружение, а не в предметную область бизнеса.
Работа интересная, но такие «велосипеды» я бы поостерегся в продакшен пихать. Когда первый раз читал про SG, так и думал, что этот достаточно мощный инструмент будут пихать куда нужно и не нужно. Множественного наследования принципиально в язык не добавляли, этому способствовали многие причины, и если каждый будет делать что-то на коленке и добавлять в реально работающие проекты, ломая основной посыл C# причем совершенно кустарным способом — ничего хорошего не будет. Я так в одной компании один день проработал — у них там 70% кода c# проекта просто генерировалось через самописный DSL, возможность быть спецом именно по этому языку, который дальше их компании не ушел (и никогда не уйдет) — не очень перспективная тема.
Сам я рассматриваю и допускаю использование SG в своих проектах только в контексте генерации некоторых моделей для/из контрактов и как некую замену Reflection в плане увеличения производительности.
То есть на каждом проекте есть выделенный архитектор
Где я такое писал? Я придерживаюсь мнения, что на одном проекте должен быть один архитектор за которым последнее слово- это да, иначе очень сложно согласовать систему. А почему его нет это вопрос уже к бизнесу. Может быть не считают нужным, может денег нет, а может и то и другое.
Так и не понял, архитекторы это выделенные единицы или каждый лид это архитектор? Если отдельные, то получается архитекторов много, т.к. команд может быть много. Вот у меня и сомнения в достижении консенсуса несколькими архитекторами одновременно.
На мой взгляд, с пустыми структурами, логику понять можно — для них нет других вариантов кроме default(MyEmptyStruct).
А вот с другими сборками — да это довольно интересное поведение, которое трудно хоть как-то объяснить:)
Но пока вас меньше некоторого k можно договориться хоть языком жестов.
Вы так много написали, но наверное не поняли о чем я. Фейл проекта зависит не только от количества вовлеченных участников — можно сфейлить и в одного и в тысячу. Я о том, что не нужно возводить в «карго культ» все эти техники — серебряной пули увы нет. А вот некоторая доля скепсиса и критики никогда не помешает)
Хороший код, это такой код который решает бизнес задачи. Пусть он будет трижды выполнять требования SOLID и отточен до последнего такта процессора, но не решает первоначальную задачу — вот это плохой код.
Если есть возможность пробовать другие методы. Вот читаю сейчас книгу www.piter.com/product/sovershennyy-soft
Там автор предлагает использовать метод декомпозиции основанный на осях нестабильности.
Вот не согласен. using, lock — это все сахар от компилятора, я буду уверен, что возьму любой другой проект и увижу такие инструкции — они будут работать 100% однообразно. А сейчас мы ведем речь о разного рода поделках отдельных людей, без стандартов, без согласований и т.д. Которые могут решать одну и туже задачу, но в разных проектах — накладывать совершенно различные ограничения и приводить к неожиданным результатам.
Проблема в том, что термин «понятность» очень субъективен. И степень его субъективности всегда повышается с применением таких вот «фишек», которые отступают от общепринятых практик и становятся зависимыми от автора, который их создал.
Автоматизировать нужно до такой степени, до которой сохраняется понятность кода, а то можно придти к такому варианту, что конечный результат будет отлично читаться машиной, а вот другому человеку все останется на уровне «абрыкадыбры», которое проще выкинуть и сделать с нуля, чем попытаться внести правки.
Какой же он чудак? В систему, минуя API, разрешали лезть руками, что не очень профессионально. Такое может с кем угодно случится. Не зря придумали публичные API, а нарушение инкапсуляции рано или поздно приведет к выстрелу в голову.
Сейчас так и делаю, смотрю кто решал те или иные проблемы на github, развивается ли проект и т.д. и внедряю по возможности.
Ну не знаю, мне вот в бизнес интересней вникать, чем в очередную новомодную библиотеку. Точнее интереснее когда применение некоторых практик помогают эффективней решать проблемы бизнеса.
У написание своего велосипеда должны быть причины. Одно дело, когда причина — так что нет аналогов или аналоги не очень удовлетворяют требованием. И совершенно другое, когда авторам велосипедов просто лень разбираться в чужом коде/подходе. Вот второй случай я и считаю самым неудачным для проекта в целом.
Microsoft выпустили джина из бутылки. Это очень мощный инструмент, неправильное применение которого на стадии экспериментов может превратить в будущем проекты в совершенно не поддерживаемое легаси.
И что до вопроса по C#, да я бы предпочел в будущем проекты, которые используют стандартные и широко зарекомендованные приемы, чем велосипеды, только в которые требуется дополнительное длительное погружение, а не в предметную область бизнеса.
Сам я рассматриваю и допускаю использование SG в своих проектах только в контексте генерации некоторых моделей для/из контрактов и как некую замену Reflection в плане увеличения производительности.
Видно мы друг-друга не поняли.
Где я такое писал? Я придерживаюсь мнения, что на одном проекте должен быть один архитектор за которым последнее слово- это да, иначе очень сложно согласовать систему. А почему его нет это вопрос уже к бизнесу. Может быть не считают нужным, может денег нет, а может и то и другое.
Так и не понял, архитекторы это выделенные единицы или каждый лид это архитектор? Если отдельные, то получается архитекторов много, т.к. команд может быть много. Вот у меня и сомнения в достижении консенсуса несколькими архитекторами одновременно.
А как для/у вас — архитектор это не выделенная персона, а размазанная по команде ответственность?
Кажется я нашел пункт который говорит, что Empty структуры в Out параметрах можно не инициализировать в теле функции:
Тут
На мой взгляд, с пустыми структурами, логику понять можно — для них нет других вариантов кроме default(MyEmptyStruct).
А вот с другими сборками — да это довольно интересное поведение, которое трудно хоть как-то объяснить:)
Ну так ноги растут из того, каким образом компилятор C# работает со структурами из отдельных сборок.
Липпет говорит о том, что подобное поведение было известно еще лет 10 назад.
тут: stackoverflow.com/a/58633459
и Тут: docs.microsoft.com/en-us/archive/blogs/ericlippert/a-definite-assignment-anomaly
Вы так много написали, но наверное не поняли о чем я. Фейл проекта зависит не только от количества вовлеченных участников — можно сфейлить и в одного и в тысячу. Я о том, что не нужно возводить в «карго культ» все эти техники — серебряной пули увы нет. А вот некоторая доля скепсиса и критики никогда не помешает)
Хороший код, это такой код который решает бизнес задачи. Пусть он будет трижды выполнять требования SOLID и отточен до последнего такта процессора, но не решает первоначальную задачу — вот это плохой код.
Поделитесь примером?
Там автор предлагает использовать метод декомпозиции основанный на осях нестабильности.