Pull to refresh
-11
0
Сергей @tac

Программист

Send message

Это конечно смело, на моем канале много еще чего смелого, например критика, да чего уж там, высмеивание, Принцип единой ответственности  ... и ведь действительно, сейчас популярно молиться на эти глупые принципы и не думать своей головой ... Смелость тут только в том, что высказываются адекватные аргументы, а не то, что считается популярным у студентов ..

Да о чем тут с тобой дискутировать, уровень школьника ... грубость с моей стороны, да, нет её, просто не могу серьезно обсуждать с тем у кого шоры на глазах и недостаточное образование. Да, и хамить ты начал сам ...

Спасибо за перевод этой статьи, переписал на C#, буду использовать в своей игре, как симуляцию песчаной бури.

Начните от сюда (это все мои статьи, так или иначе связанные с MVC)
https://habr.com/ru/post/138461/ - Правильное использование паттерна «Мост» (Мост с двухсторонним движением) или MVC->«Бизнес-сущность — Визуализация — Контроллер»

https://habr.com/ru/post/219445/ - Где наша бизнес-логика для идеалиста?

https://habr.com/ru/post/668928/ - Как учат создавать игру вида TowerDefence — ошибки «новичков»

https://habr.com/ru/post/670884/ - Когда в Unity нужно MVC, как сделать Binding визуальных контроллов с методом

А затем, я думаю, вам будет полезно посмотреть и прилагающиеся видео, это в том числе - они вас погрузят глубже, чем статьи. Правда не факт, что у вас такая цель. Но для того, чтобы разобраться в теме - это лучше.

Наверно, если у вас нет, что конструктивно сказать - это уже показатель. Советую, лишь читать и слушать - независимо от формата, что говорят взрослые дяди, такие как я и не перечить старшим. Это не вам должно быть удобно, а мне ...

а проблема того, что хабр давно стал токсичным местом, увы, не моя ... но именно такие как вы делают в это большой вклад, но большая ответственность конечно на владельцах.

Вы упорствуете в своем невежестве. Хорошо. Вот вам просто мои статьи на этот же вопрос, когда вы под стол пешком ходили. https://habr.com/ru/post/138461/

https://habr.com/ru/post/670884/

https://www.youtube.com/watch?v=joEGQ_Lb14M

думаю вы там мало чего поймете, но это статьи когда и как нужно использовать MVC

это статья о том когда не нужно.

И еще есть видео, во что превращается код, когда такие как вы не понимают когда, нужно и когда не нужно

https://www.youtube.com/watch?v=QYNaaxkfH-Y&t=30s

upd. внезапно, прошел по первой ссылке и увидел, что еще и тогда, вы так и не понимали ничего о контроллерах, читая мои статьи на этот счет, думаю - это проф. не пригодность. Но теперь у вас есть больший выбор, с того времени я для таких написал и снял разные вариации, чтобы они хотя бы немного поняли бы границы применения MVC. Успехов!

Правилами не запрещено, но в формате статьи так подробно не получится донести, поэтому привыкайте. Будет интересовать действительно тема, а не промотать по диагонали - послушаете, а нет проходите мимо. Мало ли чего вы там хотите, у меня вот в таком формате, таймкоды дал.

А то, что тут неадекватно оценивают - так это не новость, хабратушканчиков давно знаю :)

Да, задача бизнес логики решать через какое UI работать в том или ином случае. И делает это вышестоящий в иерархии класс. Несмотря на ваши общие тезисы без примеров, я их могу привести. Например, класс Society в моем примере будет решать в зависимости от поведения игрока, показать ему информацию о персоне упрощенно, или подробно. Да, именно он настроит это вместо избыточного контроллера.

т.е. изменения все равно будут, разница лишь в том - где? Только вместо того, чтобы вводить избыточную сущность контроллера, изменения затронут просто вышестоящий в иерархии класс (модель верхнего уровня)

при изменении элемента UI, менять биндинг, менять другие связанные элементы, чего бы не было в случае классической реализации MVC

Или я не понял ваш комментарий, или вы лукавите. Расскажите мне как при изменении элемента UI в MVC ничего не меняется? Если вы добавляете отображение скажем Description.text , то как же не изменится биндинг, если такого свойства вообще раньше не было? А если переименовываете скажем Name в NamePerson - у вас действительно не изменится биндинг и он продолжит синхронизировать не существующие уже свойство Name?

Так какое изменение вы имели введу?

Теперь мне приходит в голову, что переменная thisAmount стала избыточной. Ей присваивается результат each.charge, который впоследствии не изменяется ..

37 стр.

Ну, что же. Очевидное разъяснение про MVC в итоге не понравилось. Псевдо-учителя учат тому, что не знают сами для чего нужно, в итоге 10-кратный оверхед. Людей, которые это ценят меньше. Бред про коде стайл, да еще очевидно неверный - плюсуют. Здесь серьезно есть специалисты? Думаю, нет. За, сим, откланиваюсь, пока тут не появятся думающие люди, разбирающиеся хоть немного в профессии программиста, а фрики мне как то поднадоели.

Кто же все таки захочет задать вопрос или прокомментировать - прошу на мой канал.

Мне кажется используя тот же Zenject решить проблему можно было бы гораздо меньшими усилиями.

Серьезно? Чтобы решить пустячковую задачу - потянем в свой код, какой то не нужный фреймворк? Вот поэтому я пишу свои статьи, тем кто не хочет излишнего кода в своих проектах.

Но давайте так, я уеду на 2 недели, а вы реализуйте биндинг на Zenject  - вы же это предлагали? А я приеду почитаю, покритикую, сделаем win-win :) ?

На мой взгляд вы ведете себя очень не профессионально для человека с вашим стажем.

Ох, пристыдил то как ... но единственной моей задачей было сбить спесь, и заставить не писать так безапелляционно, таким как вы ... Теперь, когда вы еще кому ни будь напишите про коде стайл, пишите именно так (сделаю вам win):

  1. "вариант читается на мой взгляд гораздо легче. Я допускаю что в некоторых компаниях предпочитают так не делать ..."

    • Да, я в такой работаю ..

    • "Зачем два раза писать имя класса? Визуальный мусор " - это глупость в том месте тип не написан, во время рефакторинга необходимо многое править в зависимости от типа, наличие var - очень сильно замедляет рефакторинг, а тут я могу по праву сослаться на опыт :)

  2. "Она не лишняя, её предназначение - удобочитаемость. "

    • у Фаулера почитайте про временную переменную - это признак кода с душком , а вы мне предложили её ввести. Отличие опытного программиста, это не подаваться на провокации :) И нет удобочитаемостью вы пожертвовали столько раз, что это уже не аргумент

    • Дальше откройте, книгу "Балена Ф. и Димауро Д. - Современная практика программирования на Microsoft Visual Basic и Visual C# - 2006"

    • Но это (Фаулер) входит в противоречие с правилом 12.25 - но в моем случае и не было, как минимум длиной вложенности

  3. "Это наверное самое субъективное из всего списка. Вариант с явным сравнением с false сильнее визуально нагружает, на мой взгляд. "

    • Как не странно, но правило 18.9 за ваш подход. Но, в случае конкретно этого случая - там не простое сравнение с переменной в моем случае (вы то ввели бесполезную), поэтому, тут мне надо писать , имхо, знак ! плохо виден в отличие от единообразного сравнения с == flase / == true (да, и слова "сильнее визуально нагружает" - надо воспринимать так, что для этого то я это и делал)

  4. О return - Правило 14.16 Единственная точка выхода ... тут вам надо просто подучить мат. часть

  5. Так же у Фаулера читайте про декомпозицию и консалидацию условных выражений, для вас будет полезно, не будете делать больше такие ошибки, но т.к. вы не ответили на это изначально, будем думать что поняли свои ошибки ...

И нет у нас не идеологические разногласия, а разногласия с человеком, который не нюхав пороха решил учить других. Думаете, если бы вы написали бы сразу со всеми этими "я думаю, имхо, для меня, для места, где я работал" - я бы так отреагировал? Моя реакция вызвана, исключительно, вашей без аппеляционностью в первом сообщениии.

И да я не на Марсе, вижу, что вас плюсуют - но вы особо не обольщайтесь ... я отношу это к деградации нашей профессии, иначе бы не отвечал вам ... Буду писать пока мне дадут тут писать ... но не прогибаясь под популярные ,не глубокие, и по сути ошибочные тенденции ...

Да, еще мини урок для любителей схлопывать условия, типа

if (Related != null && !IsDoneBinding(behaviorName))

не делайте так никогда. Код должен быть удобен для рефакторинга, условия это одно из главного, что часто меняется. Понятно когда условие вложено в условие это аналог && но во-первых, это становится не так при наличии else. А во-вторых, и в главных, условия должны быть атомарными, относится к одного рода проверке. Здесь они о разном Related != null - это есть ли партнер для связывания, а IsDoneBinding - был ли биндинг сделан.

Поэтому при малейшем изменении, усложнении задачи все это поплывет, тому кто будет делать рефакторинг придётся разбирать ваше схлопывание. А это и есть критерий нужности таких изменений.

Что собственно и было в моем коде, я писал, что он сложнее, и я его упрощал ...

Ну, и раз зашла такая тема. Некоторые наблюдения.

2 курс. Без разницы как писать код, лишь бы работал ...

5 курс. Начинаешь верить в какую-то идеализацию. Вырабатываешь свои взгляды на стиль ...

1-5 года работы. Смотря как повезет, если такие же молодые как ты - то вы начинаете заниматься ерундой - стандартизировать стиль в компании. Если нет, не понимаешь почему другие мамонты не хотят менять свой стиль.

5-10 лет. Отстаешь от других и просто кодишь сам в том стиле который нравится тебе.

10-15 лет. Не позволяешь другим себя переучивать. Идешь лишь на мелкие уступки.

16-17 лет. Меньше пустозвонства - чтобы не поссорится о стиле кодинга не говорим, моветон - аналогично обсуждать политику, или зарплату.

17-18 лет. пофиг какой стиль, читать можешь что угодно, но если скобки стоят не так как нужно - не понятно что написано.

19-20 лет. увольнять если используешь пробелы вместо табов - кажется правильная идея :)

Мои источники - 5 лет коммерческого опыта

Вы сами понимаете, что этого мало? Что как минимум в раза 4 это меньше моего? Я же имел как минимум авторитетные источники, хотя бы банду 4 назвали бы и ссылку, где они такое говорили? Что это за манера такая, не зная оппонента думать, что он знает меньше вас?

Вот именно, за мозги новичков мы тут и боремся да? Ну, ок пусть так ...

Отвечать вам надо, почему вы думаете, что все что вы написали вообще имеет смысл обсуждать? Зачем мне с вами обсуждать ваши глупости? Ну выучились вы где-то не так ... мне что до этого?

Вам объяснить и так надо ...

  1. Почему вы позволили себе использовать переменную var в строготипизированном языке?

  2. Почему вы бесполезно ввели лишнею переменную behaviorName

  3. if (IsDoneBinding(BindingBehavior[i].Name) == false) - нет именно так и надо, почему вы предпочитаете "усложняющую чтение визуальную нагрузку" аналог ?

  4. Почему вы позволяете себе return в методе ничего не возвращающем, почему не используете goto?

Поэтому не надо тут про "очевидные для более опытного разработчика вещи" - это бред в таких головах, который настоящим программистам сейчас все сложнее становится выбивать из молодежи.

И нет, вы позволили себе - учить меня тому, чего я не просил! Учить тому, что как минимум спорная практика, да спорная! Кто вам скажет, если не такие как я ... больше читайте теории, в голове будет еще больше каши. Вы мне еще расскажите как скобки ставить ...

И все это при том, что статья совершенно о другом. Вы утрудили себя хотя бы прочитать предыдущую статью, разобрать в этой и понять когда нужен MVC, и как его учат использовать? А ведь учили там тоже мол учитель в МФТИ с опытом коммерческой разработки ...

Только я подымаю темы серьезные, где надо понимать предмет, а не умничать про три копейки доступа по индексу - смешно. И таких ютуберов, которые по стилю кода позволяют себе что-то то сумничать - надо палками гнать из профессии. (Это не про вас лично, есть один чудак в ютубе, просто вы идете по его стопам, остановитесь ... )

И таки да, вы меня подзавели очевидными глупостями, которые даже обсуждать смешно ... но не я это начал ..

ну договаривайте ... тогда и поговорим ... когда, же мне начинают говорить, полунамеками, не утруждая себя никаким аргументированным тезисом, да еще ad hominem - о чем говорить?

P.S. А о качестве кода я лучше знаю, чем любая автоматизированная шняга ... скорее будут вопросы к её разработчикам.

Вы не правы по всем пунктам, я пояснять не буду. Но прежде, чем придираться к мелочам, начните правильно использовать MVC. Захотите от меня ответов - спросите уважительнее.

тех. артист пилит всякие красивости для V

код связанный с визуалом имеет свойство быть очень объемным и игровая логика может в нём просто потонуть

Серьезно? артист пишет такой код? кого вы пытаетесь насмешить, и тем самым оправдать применение MVC ради самого применения?

Может для декомпозиции кода, нужно не MVC использовать? И не только коде стайл использовать популярный, который просто кричит глупостями?

Если у нас в коде появляется if, вложенный в if, вложенный в цикл, вложенный в if, то что-то явно пошло не так.

Так как это настолько часто возникающая несуразица, я лишь спрошу где источник этого несерьезного утверждения? Вы думаете, заменив это на return вы сделали лучше? Тогда я посоветую вам использовать goto они позволяют убрать больше if :)

P.S. Вы просто думайте, когда насмотревшись по ютубу всяких умников, начинаете учить других ... а то, что это советы от умников - аж сквозит ...

Клиентам - совершенно неважна лирика про архитектуру, Сережа - просто демпингует на рынке, ну и понятно, что история не реальная - лирика ... вообще, я вначале посмотрел бы код Сережи, может так статься, что и не так все плохо, т.к. "мозги" испорченные паттернами восстановить иногда еще сложнее ... но и обратный случай был только был это Каспарс - уволился под моим нажимом ... но начальство хорошо вспоминало, потому что я просил адекватную зарплату, а он работал сколько давали, а клиенты хотели скидку с демпинговой цены гос. закупок ... в итоге не бизнес, а утопия. Может и правда, пусть Сережа программирует, и по ночам исправляет свои баги, потому что клиенты уже не хотели платить за поддержку ... А зажравшимся мордам как я лучше найти коммерческую разработку, а не по гос. дешевизне, чтобы есть пельмени и пахать как индус 12 часов

Ах, да ... походите на Агил сброды, послушайте менеджеров о их пользе, и тогда Сережа будет идеальным для вас программистом ... Только не забываете, что это не больше чем психологическая атака, чтобы сбить цену разработки за счет программистов.

Удалите менеджерский сброд, и Сереж в компании, автоматом не будет

Information

Rating
Does not participate
Registered
Activity

Specialization

Game Developer, Software Architect
Lead
C#
OOP
ASP.Net
MSSQL
Game Development
C++
Programming microcontrollers
Software development
WPF
Unity3d