Как совместить гармонично совместить теорию и практику на C#?

Question

[gustafsson]

Уважаемые коллеги, хотел бы проконсультироваться:
Несколько лет пишу на ASP.NET WebForms/ ASP.NET MVC.

Но к стыду своему, каждое собеседование становится для меня проблемой.
Обычно собеседование делится на 3 части + 1-2 общих вопроса по работе интернета.

1) Часть, которая касается SQL, я прохожу достаточно легко, т к пишу довольно много запросов и при этом достаточно объемных.

2) По javascript фулстеков ASP.NET глубоко гоняют редко, про замыкания и тонкости прототипного программирования не спрашивают. Умеет человек ajax запросы отправлять, с DOM'ом поиграться, слайдер на jquery прикрутить - обычно этого хватает, чай не на фронтенда человек претендует. А если еще и Angular хоть как-то использовал, так вообще красота.

3) А срезаюсь я на C#. Да, стыдно, каждый день его использую, но валюсь на элементарных вещах.Например:

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

-В C# существует достаточно большое количество типов коллекций. В реальной жизни мне обычно хватает List.
Поэтому когда начинают пытать про очередь, стек, hashtable и т д - я сливаюсь, поскольку мне не попадалась задача, в которой list не покрывал бы мои потребности, что мне понадобилось бы разбираться с тонкостями других коллекций. Ну еще Dictionary иногда использую.

Я уж молчу, когда спрашивают про рефлексию или домены приложений. Ума не приложу, куда их можно запихнуть в ASP.NET проект, чтобы извлечь из них пользу.

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

Нет, я не ленивый, читал Рихтера, Троелсена, но в голове осело процентов 10 именно по причине неумения сопрягать теорию с практикой.

Поделитесь опытом, как гармонично развиваться .NET (ASP.NET) программисту, как сопрягать теорию с правктикой, чтобы через 5-6 лет не прийти к ситуации "программист C# 10 лет опыта не знает ответы на базовые вопросы и не понимает элементарных вещей"

Антисовет "Если от какой-то конструкции тебе нет пользы - не применяй ее" луше не предлагайте. Я вот сейчас живу по этому принципу и пришел как раз к этой теме.

Answer 1

[Rou1997]

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

Но полезность структур осознать не сумел, поэтому в реальных проектах использую только классы.

Это стоит познать практически чтобы уметь сказать хоть что-то, но лучше цитируйте литературу.

очередь, стек, hashtable и т д

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

про рефлексию

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

домены приложений.

Это стоит познать практически чтобы уметь сказать хоть что-то, но лучше цитируйте литературу.

Comments

[gustafsson]

Во-1, спасибо за ответ!

>>>Не может быть чтобы не было задач с хеш-таблицами, в отличие от списка они позволяют не создавать >>>класс или структуру только ради того чтобы к значениям добавить ключи

Ну я потому и написал про то, что пользуюсь Dictionary, он умеет то, что умеет hashtable, а так же то, чего он не умеет. А вопросы про стек и очередь меня вымораживают. Ну какая разница, кто там первый пришел, кто первый ушел, когда можно все сложить в list или dictionary, отсортировать как надо.

[Rou1997]

gustafsson:

Ну я потому и написал про то, что пользуюсь Dictionary, он умеет то, что умеет hashtable, а так же то, чего он не умеет.

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

Answer 2

[MrDywar Pichugin]

У меня наоборот было.
Начитался про C#, а вот практики мало, и валился на простых вещах.
Сейчас уже и эти пробелы закрыл.

Раз книги читал, то сходи на ITVDN курс мидл и проф.
Просто заучи, повторяй раз в неделю, месяц, полгода заметки из книг.
Выписывай то что считаешь главным, своими словами.
У меня набралось на 3-4 часа чтения.
Но зато это покрывает ~5 книг сразу.

Коллекция нужна только если используется Add, Remove. Книги то читали, вот например заметки из Jon Skeet C#:

List - внутренне хранит массив и отслеживает логический размер списка и размер поддерживающего массива. Добавление элемента является либо простым случаем установки очередного значения в массиве, либо (если массив уже заполнен) копированием существующего содержимого в новый массив большего размера (обычно в два раза, т.е. происходит удвоение, но это недокументированно) и затем установки в нем значения. Сложность O(1) или O(n) в зависимости от того требуется ли копирование значений. Удаление элемента из List требует копирования расположенных за ним элементов на позицию назад, поэтому сложность составляет O(n-k), где k - индекс удаляемого элемента. По индексу RemoveAt() удалять значительно быстрее чем по значению Remove(), т.к. во втором случае происходит сравнение каждого элемента где бы он не находился сложность O(n).

**Массивы** - самый низкий уровень коллекций в .Net. Унаследованы от System.Array, и они единственные имеют прямую поддержку в среде CLR. Массивы всегда изменяемы в терминах своих элементов, но всегда фиксированы в терминах своих размеров.
Foreach для массива использует его свойство Length и индексатор массива, а не создает объект итератора.

**LinkedList** - связанный список, каждый элемент которого имеет ссылку на предыдущий и следующий элемент. Быстро можно удалять, вставлять новые элементы, т.к. происходит только изменение ссылок на соседних узлах. Проход по коллекции тоже эффективен, но разумеется нет индекса.

**Dictionary** - подобно List хранит свои элементы в массиве, со всеми вытекающими по вставке и увеличению размера последствиями. Для реализации эффективного поиска использует хештаблицу. Можно либо применять стандартные функции хеширования и эквивалентности внутри самих объектов ключей, либо передать реализацию IEqualityComparer в аргументе конструктора. Ключи должны быть уникальными, но хешкоды могут совпадать, что снижает эффективность поиска. Словарь даст отказ, если ключи являются изменяемыми и меняют свои хешкоды после того, как были вставлены в словарь. Внутри этого словаря нет гарантии порядка следования элементов, так что рассчитывать на него нельзя. Вставка происходит на основе ключа (что-то вроде индекса), а не последовательности заполнения словаря.

**ReadOnlyDictionary<,>** - просто оболочка, которая скрывает все изменяемые операции за явной реализацией интерфейса, и генерирует исключение если они все же вызываются. Но если лежащая в основе коллекция (та что передается конструктору) модифицируется, то модификации будут видны через оболочку.

APS.NET без рефлексии и доменов не работал бы.

Comments

[mletov]

Спасибо, наверное, так и буду делать. Уже надоело позориться на собеседованиях.

[pro100saniok]

а можна у вас купить ваши заметки ?

[MrDywar Pichugin]

Можем списаться в telegram.
Продавать не собираюсь, а поделиться могу.

Answer 3

[Артём Токаревских]

Нахожусь в аналогичной ситуации. Программирую с прошлого века. Сейчас мой стек — это C#, T-SQL, JScript, JavaScript, XSLT, CSS. Собеседование пройду максимум на мидла.

Решил подтянуть и систематизировать знания, опираясь прежде всего на C#. В качестве фундамента собираюсь выбрать две вещи.

Во-первых, перечитать книгу Скита "C# in depth", реализуя примеры. Книга опускает элементарные основы языка, но даёт перспективу его развития.

Во-вторых, перепройти Стэнфордский или Принстоновский курсы по алгоритмам на coursera.org, реализуя их на C#.

Не только это в планах, но данные пункты выбраны в качестве основы.