Резюме для программиста
Вобщем, резюме для программиста оказалось делом десятым. Опыт хотя бы 1 год в местных или просто известных фирмах, язык на уровне - и резюме нужно будет лишь формально. Поэтому дрочь на его вылизывание и узнавание каких-то якобы секретов его оформления, из-за которых вас тут же позовут на интервью и обязательно возьмут - туфта всё это. Разве что при поиске первого места работы это может как-то помочь. Но и то лучше "придумать" (не сильно привирая, правда) себе опыт работы, чем пытаться как-то особенно оформлять резюме - оно вернее сработает. Судя по опыту многих других - оно и у них вернее срабатывало.
Офигеть! Королла у них не машина. Зажрались! Этот и предыдущий комменты.
Может кто-то объяснить, в чём суть, когда пишется один файл с кодом, а потом добавляется как ссылка (add existing file - add as link) к другим проектам? Чем это отличается от добавления проекта с этим файлом как зависимости?
А иногда и оба варианта сразу - добавляются одновременно и ссылка на файл с кодом, и библиотека с этим файлом как зависимость. Что за выкрутасы супер-архитектора?
Для этого и существуют всякие семизнаки на форумах - чтобы прийти и молча поправить всё быстро дать чёткий и по делу совет. ))
Вы лучше скажите, зачем в один и тот же проект одновременно добавлять и файл как ссылку, и ссылку на проект, в котором этот файл находится? Кто-то "мисскликнул"?
добавляются одновременно и ссылка на файл с кодом
оочень редко довольно удобная штука - расшаренный файл.
Используй файл где хочется, но при этом имеется только один оригинал.
Например, хотим иметь одни и те же коды ошибок в разных проектах. Городить целую либу для этого как то не хочется.
Т.е. расшаренный файл это заменитель маленькой либы?
А как его может использовать проект, который ссылку на такой файл имеет? Полный доступ к классам этого файла без подключения либы, его содержащей, как зависимости (project reference)?
Получается, что в принципе для работы на одной машине либы не нужны - можно всё такими расшаренными файлами расшарить? А либы лишь для дистрибуции создавать?
Я имею ввиду, вот есть у нас солюшен с проектами. И есть другой проект, который в солюшен не включен. Чтобы получить доступ к классам этого проекта, мы можешь либо подключить проект в солюшен, либо подключить либу, либо просто добавить ссылку на файл? И все классы из этого файла подгрузятся в солюшен, и можно будет перейти в этот файл по, например, команде "Go to Definition"? А при компиляции этот файл тоже будет скомпилирован? А проект этого файла будет скомпилирован? Ведь он не подключен.
Вот я и спрашиваю, насколько подключение файла как ссылки делает его полноценным участником открытого солюшена с проектами. И если такое подключение неполноценное, то зачем добавлять?
Если что, под добавлением файла как ссылки я имею ввиду файл с исходным кодом (например .cs), не уже скомпиленную ДЛЛку. Этой ДЛЛки может просто не быть - исходник не скомпилен, а лишь подключен по ссылке. Если же при подключении по ссылке там под капотом делается куча операций, типа компиляции и подключения ДЛЛек, то это бред какой-то - проще уже весь проект с исходником или саму ДЛЛку подключить - нафига нужна новая сущность "добавить файл как ссылку"?
А закомпилить один лишь файл, без всех остальных файлов проекта, не всегда можно - может, у него зависимости от других файлов (классво) проекта? Тогда надо по цепочке подключить и всё остальное. Тогда проще весь проект подключить.
Короче, вся эта линковка - это какой-то бред. По крайней мере по отношению к файлам кода, которые должны компилиться. Уже существует механизм расшаривания файлов кода через подключение проектов и ДЛЛек, нахрена городить третий механизм и потом трахаться с добавлением залинкованных файлов в систему контроля версий и прочие. Может, для некомпилируемых файлов, типа ресурсов каких, это лучше подходит. Но и ресурсы тоже через подключение проектов и ДЛЛек шарятся.
Вот тут чел распинается, но нам важно, что в конце ("Why Would We Want to Link Files?") он приводит пример, когда это якобы полезно - иметь общий код среди проектов, которые нельзя подключить друг к другу. Тогда давайте мол шарить файлы через линковку. А если в пошаренных файлах юзаются пространства имён и классы, которые недоступны в типе проекта, который ты линкуешь? А вы мол не юзайте такие. Тогда почему бы не юзать .NET Standard, который как раз предназначен, чтобы иметь код, который общий для разных типов фреймворков, и шарить этот код между типами фреймворков, не подключаемыми друг к другу непосредственно (например .NET Framework и .NET)? - А куй его знает. Чел придумал костыль с линковкой и рад.
Короче, как я и думал, это очередной костыль для дерьма, которое нагородили в Майкрософт со своим зоопарком фреймворков, которые между собой несовместимы. Когда они раздуплятся и перейдут на один стандарт, один тип фреймворков (например текущий .NET), то вся эта херня станет не нужна.
Вот у меня сейчас в проекте переход с .NET Framework на .NET. Там до меня пытались это сделать - создали проекты .NET Standard и залинковали туда кучу файлов из .NET Framework. Нахрена? Если файлы эти по коду совместимы с .NET Standard, то почему бы сразу не создать эту либу и подключить её к проектам .NET Framework? А там, оказывается, не все файлы совместимы. Поэтому придётся проект на .NET Framework дробить - часть выносить в .NET Standard, а часть оставлять в .NET Framework. Он не хотел этого делать, и часть файлов залинковал, а часть переписал, чтобы были совместимы с NET Standard. В результате имеем мешанину из проектов, залинкованных файлов и прочей мути.
По-моему, лучше было всё таки раздробить на проекты. Потому что управление проектами в Студии и системе контроля версий как-то работает - для этого есть инфраструктура, а управление залинкованными файлами работает через задницу и вообще вносит кучу путаницы.
А вот и коммент оттуда про инфраструктуру (точнее её отсутствие) поддержки залинкованных файлов:
"All fine and good until you move the folder. Then you have to readd all the files by hand. If there are a thousand files.. might as well use another ide."