Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (15)

Наибольший вклад в теги

Все теги (108)

Лучшие ответы пользователя

Все ответы (446)
  • Почему не могу найти работу Junior'ом C#?

    @kttotto
    пофиг на чем писать
    Это не резюме, это набор слов, ничем Вас не выделяет из общей массы и даже делает низовым в списке общей массы.

    1. Такой кучи тегов даже у меня нет)) Если Вы знаете названия технологий, не говорит о том, что Вы знаете сами технологии. С Вашим опытом никто не поверит, что Вы имели реальный опыт со всем этим, а не просто hello world написали. Выберите те, в которых по Вашему мнению Вы лучше всего разбираетесь.

    2.
    Отличное знание WinForms, ASP.NET, LINQ и WPF. Паттерны: MVVM, MVP, Repository, IoC.

    Для третьекурсника звучит самонадеяно. При такой формулировке на техническом собеседовании будут проверять "отличное" знание и я почти уверен, что Вы его провалите. Лучше сказать что-то подобие: имел опыт работы с, для реализации использовал технологии, имею <начальные> навыки работы с и т.д.

    3.
    Занимался исправлением мелких багов, написанием небольших SQL-запросов и unit-тестов, решал небольшие задачи.

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

    4.
    Если вспомнить css и html

    Вот такое никогда не пишите. Лучше соврать или преувеличить, или даже написать "Отличное знание", но не так как Вы здесь сформулировали.

    5. Не нужно оставлять ссылки на каждый проект в репозитории. Либо один, самый интересный на Ваш взгялд, либо одна ссылка на сам репозиторий. Работодатель пойдет туда только, если Вы заинтересуете его, не раньше. И ему пары файлов хватит оценить ваш уровень. Он не будет делать ревью всех Ваших проектов.

    6. Опыта одного проекта мало. Где опенсерс проекты, где участия в хакатонах, где амбиции стартапов, посещение конференций? Работодатель хочет понимать как Вы заинтересованы развиваться, какие у Вас планы для дальнейшего роста. Он берет вас нулевым не из альтруистических побуждений, а с надеждой, что Вы быстро вырастите и вернете ему прибылью затраченное на Вас время. Из Вашего резюме видно только одно: я студент - дайте работу. А почему Вам, за какие такие заслуги и что с этого будет иметь работодатель - не понятно.

    7. Я посмотрел Ваш код. Я бы не хотел, чтобы так писали у меня в проекте, начиная от именований и заканчивая некоторой логикой. Вас надо очень осторожно подпускать к реальным задачам и контролить, что Вы там напишете, просто чувствуется маленький опыт и до "отличных знаний" там далеко.

    В общем, вывод. Пока у Вас за плечами нет списка реальных проектов, чтобы Вас пригласили, надо себя выпячивать, хвастаться достижениями, демонстрировать амбиции, свою уникальность. Нужно убеждать работодателя, что Вы именно тот, кто ему нужен. В резюме этого нет. Когда у Вас будет пяток законченных проектов, будет наоборот, работодатель будет за Вами бегать и убеждать, что Вам у него будет лучше всего. И на hh студентов практикантов не ищут, поэтому только Вы должны делать отклики на вакансии, обязательно с сопроводительным письмом, в котором парой фраз Вы сможете заинтересовать работодателя.
    Ответ написан
    Комментировать
  • Как править чужой код так чтоб его не сломать?

    @kttotto
    пофиг на чем писать
    Во первых нужно закладывать время на разбор легаси кода, об этом сразу надо говорить с заказчиком. Зная задачу, всегда понимаешь, ЧТО надо написать, но в случае с легаси надо еще и понять КУДА это написать. Без этого никак и поэтому это время надо учитывать.

    Второе. Когда-то меня учили, что код нужно менять только дописывая его, в крайнем случае удаляя, но ни в коем случае не переписывая. Поэтому, если надо изменить поведение - наследуешься, переопределяешь метод и используешь новый класс. Мне сложно судить о php, как этот проект реализован, но ООП для того и придумали, что его легче поддерживать и он легче модифицируется.

    Следующий вариант изучить код, начинать писать тесты к нему. Я этим способом пользуюсь редко, в основном пишу на то, в чем я не уверен, что боюсь сломать.

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

    А вообще чтение легаси, это дело опыта. Я помню первые свои чужие проекты, я думал, что попал в ад. Сейчас копаться в чужом коде, это мое любимое дело) Я могу часами сидеть разбирать чужой код, что начальству приходится меня попускать: "я понимаю, я тоже это люблю, но надо дело делать")) Люблю просто на гитхабе полазить по чужим проектам, посмотреть как люди думают.
    Ответ написан
    Комментировать
  • Где, когда, зачем и почему надо применять DTO?

    @kttotto
    пофиг на чем писать
    1. DTO модели, это всего лишь прослойка между сервисами и их предназначение перенести данные от одного сервиса/слоя к другому. Это всегда чистые POCO модели. Если Вы из одного сервиса сразу будете передавать данные в другой сервис, то у Вас выйдет зависимость от типа данных. Т.е., если в первом сервисе изменится тип отдаваемых данных, то придется менять тип входных данных второго сервиса и возможно что-то даже править в коде.

    Прослойка из DTO моделей от этого защищает. Если в первом сервисе изменится тип отдаваемых данных, то Вы просто меняете правила мапинга отдаваемых данных на DTO модель и во втором сервисе ничего править не придется. Тоже самое касается и в обратную сторону. Ну и плюс, с точки зрения философии, позволяет эффективнее работать с моделями на уровне предметной области самого сервиса, не зависеть от моделей предметной области стороннего сервиса.

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

    Собственно по поводу конкретики применения я ответил: перед тем как отдать данные - мапите в DTO, получили DTO - сразу мапите в локальные модели. Больше внутри нигде их не используете, они только переносят данные.

    2. Фабрика нужна там, где нужен контроль создания объекта. Либо ограничение прав его создания, либо принятие решения создания по условию и.т.д.
    Ответ написан
    Комментировать
  • Как правильно дождаться выполнения всех потоков, созданных в цикле?

    @kttotto
    пофиг на чем писать
    У Вас не правильный подход. Во первых забудьте про Thread и используйте TPL. Во вторых для распараллеливания запросов в цикле есть замечательный метод Parallel.ForEach. В третьих для ожидания выполнения всех параллельных задач есть Task.WaitAll.
    В общем Вы можете создать список Task-ов и запихнуть их в Task.WaitAll, но лучше пройдитесь параллельным форичем по Вашему периоду и внутри запускайте Ваши методы. Код за форичем будет ожидать завершения всех потоков в цикле.
    Ответ написан
    2 комментария
  • Какие решения для создания UI вы используете?

    @kttotto
    пофиг на чем писать
    Windows Forms устаревшая технология. Сейчас для десктопа под виндовс разрабатываются на WPF. Там спецом все сделано для возможности гибкого дизайна.
    Ответ написан
    3 комментария

Лучшие вопросы пользователя

Все вопросы (25)