• Web MVC приложение без фреймворков и сервлетов
    +5
    А можно я заберу это, чтоб на код ревью предлагать кандидатам во время собеседования?
  • Почему Senior Developer'ы не могут устроиться на работу
    0
    РФ, СПб, никаких супертехнологий, сплошной опенсорс — spring, activiti, drools, mongodb, ну и по мелочи всякое.
  • Почему Senior Developer'ы не могут устроиться на работу
    0
    Видимо, джуны могут быть очень разными. Я никогда не видел таких хороших джунов, но это не значит, что их не бывает. )
  • Почему Senior Developer'ы не могут устроиться на работу
    0
    Я провожу собеседования только на свой проект, считаю, сложность некоторых реальных задач проекта значительно превышает сложность задач на интервью.
    Не Гугл, Фейсбук или Эппл.

    А средняя зарплата — это какая, по вашему мнению?
  • Почему Senior Developer'ы не могут устроиться на работу
    +2
    Полноценный парсер JSON — боюсь, слишком круто для полутора часов, если в языке нет какой-то специфической поддержки и нельзя использовать сторонние библиотеки. Ну разве что какое-то подмножество покрыть можно.
  • Почему Senior Developer'ы не могут устроиться на работу
    +1
    Не стою, не занимаюсь микроменеджментом, не грожусь уволить (да и не могу).
    Но вы немножко передергиваете. Интервью не предполагает увольнения или наказания за «плохой код».
    Это встреча двух профессионалов, которые должны решить, хотят ли они работать друг с другом, причем собеседуемый заранее знает, что от него будет требоваться.
  • Почему Senior Developer'ы не могут устроиться на работу
    0
    Я не знаю, какой у вас стек и ЯП, может, у вас реалии другие. Но в Java джун редко хорошо знает стандартную библиотеку. Он может хорошо зазубрить ответы на стандартные вопросы, но с практическим использованием у него туго, допускает много ошибок, опыта мало. Даже если такой человек умен и схватывает быстро, я не могу его порекомендовать к найму.

    Если кандидат на практическом уровне знает Java и JDK, способен реализовать тестовую задачу с многопоточностью, способен понять, какие тесты нужны и написать их — сеньор почти наверняка.

    Вот описанная вторая задача — она как раз по существующему коду, ее сеньор за 15 минут решает, если на четверку знаком с языком программирования и имеет
    некоторый опыт поддержки реальных приложений.

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

    Таким образом, сочетание задач позволяет с приемлемой долей вероятности позволяет отличать новичков в Java, мидлов и джунов от сеньоров.
  • Почему Senior Developer'ы не могут устроиться на работу
    +1
    А вы не могли бы привести пример задачи на час — полтора, с учетом того, что решать будет сеньор и можно пользоваться IDE и документацией?
  • Почему Senior Developer'ы не могут устроиться на работу
    +2
    У вас все разработчики пишут сервисы под вашим пристальным взглядом и на время?
    Таки да. Сами при планировании дают оценки, а потом иногда укладываются в них. Непосредственно во время разработки наблюдения нет, зато потом перекрестное code review проходят вообще все, разработчики, лиды, архитектор. Причем люди уже поняли, что тащить сомнительное себе дороже, если нужна ранняя критика — сами придут к коллеге и попросят взглянуть.

    А вообще есть только один способ узнать, может ли человек работать — это нанять его и поработать с ним вместе относительно длительное время.
    Менеджмент к такому не готов, потому что на большом и сложном проекте человек за испытательный срок не выходит на полную мощность, а после — его уже просто так не уволить.
    Так что приходится идти на компромиссы.
  • Почему Senior Developer'ы не могут устроиться на работу
    +2
    К сожалению, не могу раскрывать детали тестового задания, чтобы убедить вас.
    Никто не требует от кандидата слишком многого.
    Речь не идет о коде качества, достойного production. Сервис, который нужно сделать, имеет одну зависимость (с единственным методом), и сам тоже имеет единственный публичный метод. Протестировать нужно ровно те кейсы, которые упомянуты в требованиях, их три. Это много?
  • Почему Senior Developer'ы не могут устроиться на работу
    +1
    Год уже как участвую в найме — провожу техническое интервью. Никакой теории не спрашиваю, сплошная практика.
    За отпущенные 2 часа большинство не успевает.
    Всего две задачи, можно использовать IDE.
    Первая — разработать некий сервис + тесты, из сложностей — нужно уметь читать требования на английском, иметь базовые навыки многопоточного программирования, уметь писать юнит-тесты. Разрешаю пользоваться документацией, даже гуглить при сильных затруднениях.
    Вторая — до 20 строк забагованного кода, нужно почитать и найти косяки (уже без документации).
    Обе задачи вполне себе боевые, первая имитирует процесс разработки, вторая — кодревью.
    За год я смог одобрить 9 человек, прошло через меня несколько десятков.
    А резюме почти у все были хорошие. Многообещающие.
    Зато многие кандидаты говорят, что это был их лучший собес за все время. )))
  • Самодокументируемый код – это (как правило) чушь
    –2
    Если DSL выражен средствами языка программирования — его будет легко поддерживать.
  • Сколько стоят юнит тесты?
    0
    Я не упомянул другие инструменты только потому, что тема — юнит тесты. А так — согласен. Одного уровня обороны слишком мало.
  • Сколько стоят юнит тесты?
    0
    Согласен. Но это не должно быть единственным поводом для написания тестов. )
  • Сколько стоят юнит тесты?
    0
    Они простые.
    Минимум — демонстрация замысла автора. В прямом смысле — глядя на тест должно быть понятно, что и зачем автор хотел сделать.
    Остальное определяется возможностью повторного использования компонента.
    Если компонент идет «в народ» — тесты должны быть ковровыми. В остальных случаях возможны компромиссы.
  • Сколько стоят юнит тесты?
    0
    Все это есть. Я как раз пишу на языках со строгой типизацией, использую статический анализатор, и это не отменяет необходимость юнит тестов. И ревью тож практикую. Первое, на что смотрю при ревью — это именно тесты.

    Ваш пример с генератором SQL достаточно интересен. Возможно, юнит тестом тут не обойтись — придется использовать интеграционный. А если в качестве СУБД поиспользовать встраиваемую СУБД, например H2, то интеграционный тест будет не шибко сложнее юнит теста.

    А еще можно попробовать разбить генератор SQL на 2 компонента — генератор модели и транслятор модели уже в SQL. Относительно дорогое решение, но в некоторых случаях оправданное, и позволяет обойтись юнит тестами.
  • Сколько стоят юнит тесты?
    +2
    За 13 лет работы я прошел этапы восприятия юнит-тестов от «что это вообще» до «без некоторого разумного покрытия юнит-тестами модуль не считается разработанным».
    На том и стою.
  • Кратко об абстракциях
    +3

    текут

  • Цивилизация Пружин, 5/5
    0

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

  • Про ИТ-бизнес и не только
    0

    Бесполезно лгать, уговаривать и принуждать к добру, когда нужно впихнуть невпихуемое. Приложение либо нужно ещё вчера, либо не нужно вообще. А потом что выросло — то выросло. )))

  • Развитие цифровой экономики России обойдется государству в 1,8 трлн рублей
    +7

    Развитие экономики обычно не "обходится", а "приносит".

  • Как написать код, который будет понятен всем?
    +1
    Вот список практик моего текущего проекта, которые в разной степени направлены на поддержание понятности кода.

    • Придерживаться общего для проекта стиля. Да, его нужно выработать, задокументировать и автоматизировать контроль.
    • Давать осмысленные названия переменным, классам, функциям, пакетам.
    • Выровнять уровни абстракции. В том числе в рамках одного файла.
    • Стремиться сохранить линейный формат кода на каждом уровне абстракции. Считайте, что вам удалось, если возможно сделать близкое к реальности предположение о том, что делает функция, прочитав её всего лишь раз сверху вниз.
    • Избегать повторяющихся проверок. В идеале — вытеснить неопределенность в данных на максимально высокий уровень абстракции и сделать некорректное состояние невыразимым на нижележащих.
    • Написать тесты, которые как минимум демонстрируют замысел.
    • Зачищать ненужный код, комментарии, и т.д..
    • Хороший комментарий в коде — это ссылка на документацию или объяснение, почему сделано именно так, а не иначе.
    • Снабжать commit'ы внятными комментариями.
    • Не объединять в одном commit'е разрозненные по смыслу вещи.
    • Делать обзор собственного кода перед созданием pull-request'а.
    • Не создавать слишком большие pull-request'ы. Если изменений слишком много — лучше создать несколько pull-request'ов.
    • Делать code review. Никакого merge до консенсуального исправления всех значимых замечаний.

    Я, наверное, что-то упустил, но это не важно. Важно то, что всех этих практик все равно оказывается недостаточно. )))
  • Списки в Kotlin. Haskell подход
    0
    Если вам в Kotlin нужна ленивость и бесконечность — берите Sequence.
  • Программисты своими руками лишают себя работы
    +8
    Человек имеет право выполнять свою работу любым законным способом.
    Если работодатель не разбирается в аспектах своего бизнеса и не понимает способов решения связанных с бизнесом задач — это его проблема.
  • Манифест Чистого Программиста или краткий конспект книги «Чистый Код» Роберта Мартина
    +2
    Чтоб научиться писать хороший код — нужно много писать и читать код, периодически возвращаясь к доработке уже написанного. Без такой практики этот список не поможет, а вот качестве дополнения будет очень полезен.
  • Не пишите лишнего
    0
    Невменяемые сроки и плохая постановка задач — все это есть. Но в хорошем проекте это скорее исключение, чем правило.
    Я, конечно, люблю идеальный код, но не являюсь его неуёмным фанатом. Должны существовать измеримые критерии качества кода, и никакой код в проекте не должен быть хуже, чем предусмотрено этими критериями. Критерии, конечно, у каждого проекта могут быть свои.
    Очень хорошо, если заказчик понимает, что качество кода непосредственно влияет на качество продукта, на стоимость его развития и поддержки. Если не понимает — лучше инвестировать время в разъяснение, окупится.
    А так — да. Никому не нужна корова, всем нужно молоко, шкура, мясо. Никому не нужен бетон, всем нужны мосты и здания. Никому не нужен Х, всем нужен У.
  • Не пишите лишнего
    +5
    Если человек не страдает самоконтролем, то никакие добрые советы ему не помогут. Неоднократно во время PR review наблюдал откровенный говнокод, которого могло бы не быть, если бы человек просто посмотрел на свою писанину второй раз.
    Мне стоило некоторого труда научиться задавать себе вопрос, а не говнокод ли я написал только что?
    К сожалению, многие разработчики не задают себе такой вопрос вообще никогда.
  • Петиция за отмену блокировки Телеграма в России
    +7

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

  • Swift vs. Kotlin. Отличия важны
    0
    Ну вот навскидку:
    • Отделение контракта чтобы не тащить за собой зависимости реализации.
    • Раздельное управление API и реализацией.
    • Добавление явных декораторов вместо неявных аспектов.
    • Улучшение читаемости API.
    • Сокрытие платформозависимого компонента, конечно же.

    Можно, наверное, еще подумать, зачем может быть нужен интерфейс с единственной
    реализацией, но и приведенного должно быть достаточно.

    Конечно, легко себе вообразить проект, где перечисленные выше причины вообще никогда не возникнут, но в моем текущем проекте и во всех предыдущих за последние лет 6 наличие интерфейса практически у любого сервиса подразумевалось по умолчанию.
  • Swift vs. Kotlin. Отличия важны
    –1
    Не очень понятно, за что минусы. За стиль? Или кто-то полагает, что моки из final классов — это хорошо?
  • Чего боятся программисты?
    +1
    Боюсь пропустить говнокод во время code review.
    Иногда побаиваюсь сложных задач.
    Боюсь языков программирования со слабой типизацией.
  • Swift vs. Kotlin. Отличия важны
    –3

    Необходимость мокать final классы, говорит о просветах в дизайне.

  • Java EE 8: краткий и весьма оптимистичный обзор новых возможностей
    0
    Необходимость поднятия всего окружения для тестирования одного бинчика почти всегда говорит больше о разработчиках, чем о технологии.
  • Kotlin, puzzlers and 2 Kekses: Вы уверены, что знаете, как ведет себя Kotlin?
    –1
    Нууу…
    Пазлер 9 — спорно. Можно рассматривать и так, и так. Возможно, JetBrains выбрали менее удобный вариант, но лично я предпочитаю использовать ключевое слово when, если веток больше чем 2.
    Пазлер 10 — не баг, однозначно. Из доки следует, что делегат это объект с вот такими методами:
    //на чтение
    operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
            return "$thisRef, thank you for delegating '${property.name}' to me!"
    }
    //на запись 
    operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
            println("$value has been assigned to '${property.name} in $thisRef.'")
    }
    

    У интерфейса kotlin.collections.Map нет таких методов, зато есть соответствующие экстеншн функции в файле MapAccessors.
    То есть синтаксис объявления делегата по мапе не магия, которая от нас сокрыта, а вполне традиционный для котлина способ делегирования.
  • Kotlin, puzzlers and 2 Kekses: Вы уверены, что знаете, как ведет себя Kotlin?
    0
    промахнулся, отвечая пользователю Moxa, см ответ выше
  • Kotlin, puzzlers and 2 Kekses: Вы уверены, что знаете, как ведет себя Kotlin?
    +4
    Настоящий паззлер — это Пазлер 11. Все остальное — это ожидаемое поведение.
  • Эти токсичные, токсичные собеседования
    +12
    Чтобы понять, хорош ли ли человек в работе, нужно с ним поработать. Другого надежного способа нет.
  • Почему я ненавижу Spring
    0
    Звучит как «если вы всё сделали правильно и ничего не забыли, компонент гарантированно инициализируется корректно». Вот у меня Spring-конфигурация на Java и, по моему опыту, она вообще ничего не гарантирует. Проект скомпилируется и обосрется через 2 минуты инициализации контейнера, потому что тут не завайрился бин, а тут пропертю забыли подсунуть в файл. Вот это удовольствие автор и имел в виду, когда говорил, что в Spring нет compile time safety.

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

    В зрелом проекте дерьмо неизбежно. Если не Spring, то еще что-нибудь.
    Еще как виноват, потому что хеллоуворлды на нем выглядят просто и весело, создавая иллюзию, что вот за тебя крутые дядьки подумали и сделали мегафреймворк на все случаи жизни, а ты просто пишешь 2 строчки кода — и вуаля, у тебя сама собой вырастет шикарная архитектура и все девки будут твои.

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

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

    В этом высказывании можно заменить Spring на любую другую не самую простую технологию, смысл особо не изменится. Но, честное слово, я не видел такого не разу. Либо джун Василий не совсем пустоголовый и способен обучаться, либо он не пройдет собеседование и не попадет в проект.
    А именно — используем Spring в проекте. Шутка (но с долей правды).

    Юзер rraderio выше все правильно сказал. Spring'ом можно инициализировать бины, которые про Spring не знают.
    Вообще это здравая мысль, вот только почему-то в поддержку Spring часто звучит такой «аргумент», что он якобы учит молодежь правильной архитектуре.

    Виноват ли в том Spring?
  • Почему я ненавижу Spring
    +4
    Тружусь в относительно большом проекте, несколько сотен тысяч строк кода, все на Spring'е, пока все хорошо.
    Хочется сказать пару слов в защиту:
    • Магия — это действительно плохо. Ряд приемов, например, autoscan, лучше использовать с осторожностью или не использовать совсем, тем более что магия часто замедляет инициализацию контекста.
    • Конфигурировать лучше с помощью Java конфига. Будет вам compile time safety.
    • Импортировать Java конфиги не легко, а очень легко.
    • Spring умеет очень много, сложность его велика, но документация очень неплоха, а главное — никто не вываливает всю эту сложность на программиста за раз. Обычно бывает наоборот: нужна какая-то штука, и в попытках найти решение вдруг оказывается, что в Spring'е есть и это!
    • Подъем контекста Spring'а крупного приложения занимает заметное на глаз время, поэтому в тестах лучше Spring'ом не злоупотреблять. Если же оказывается, что без Spring'а протестировать класс, например, нереально — вы что-то делаете не так.
    • Spring сам по себе не делает мир лучше. Если бардак в головекоде — начинать надо не со Spring'а.