Как стать автором
Обновить
4
0

Пользователь

Отправить сообщение
3D принтер — не единственный способ сделать оружие — можно на токарном станке выпилить из дерева вырезать и т.д. К тому же я уверен, что пластиковый пистолет будет иметь слабую надёжность и точность, да и люди могут не воспринимать его всерьёз…
Информация должна быть открытой — глупо это запрещать (и даже бесполезно). А вот изготовление (а тем более применение) оружия — это уже преступление.
Ну тогда это не с семьи, т.к. в одной семье могут работать и двое и трое (дети например).
У вас всего лишь три параметра, которые довольно часто обратнозависимы
Чаще всего там нет обратной зависимости. Чем меньше кода написано, тем проще его понимать, расширять и модифицировать. (Это конечно не значит, что всё нужно писать в Code-Behind onclick)

код выглядит одинаково, но вызывается из разных мест
— Это как раз признак того, что код написан по DRY — вызовов много, а вызываемый код — общий. Конечно, если нужно поменять сами вызовы, то без поиска и замены не обойтись, но предполагается что весь код написан по DRY — т.е. количество вызовов максимально сокращено…

А какой код нужный и какой код ненужный?
Ненужный в данном случае — неиспользуемый/мёртвый или закомментированный.

Вы когда-то такое делали? Ну, не в домашнем своем проекте, а в реальном, где куча людей, параллельно разрабатывают какие-то фичи, а еще нифига нет тестов и прочее?

Конечно делал! Но соблюдение этих принципов не значит «забивание» на архитектуру приложения. Если код вызывается в куче мест, то он должен быть написан так, чтобы его можно было модифицировать (но если этого не предусмотрели изначально — значит нужно добавить) — всё-же пройтись по десяткам методов и заменить класс на интерфейс сделать проще, чем разбираться с кучей ненужных абстракций, зависимостей и конфигураций

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

DRY — Изменения должны происходить в минимальном количестве мест (не всегда получается сделать что только в одном). При внесении изменений не должен меняться одинаковый код (например поиском и заменой по коду).

YAGNI — Не пиши лишний код и удаляй ненужный (если он есть в системе контроля версий конечно).

По поводу необходимости изменения кода там, где нет абстракций — значит пришло время их добавить… (Что соответствует данным принципам). Если код написан по KISS и DRY — добавление абстракции произойдёт в одном месте и затронет минимальное количество кода.
По поводу абстрактного класса — всё зависит от того — внешний это интерфейс или внутренний. Если интерфейс реализован только для расширяемости / юнит тестирования, либо если это API и наружу виден только интерфейс в виде json-объекта, то вынесение абстрактного класса на данном этапе лишнее, т.к. не факт что 2ой потомок вообще появится. (получается что это будет лишнее усложение. Когда появится — тогда и вынесем). Если же реализована система плагинов или планируется возможность переиспользования и расширения модуля, то тогда абстрактный класс — must have…
сложно найти баланс между расширением и сложность архитектуры и производительностью

Нет — это не так сложно. Есть простые принципы KISS, DRY и YAGNI
Чем проще написан код, тем проще его расширять и поддерживать. Многие программисты страдают от «универсальности». К примеру пришла задача обработать данные по протоколу (К примеру команды по MODBUS или CAN) Некоторые разработчики начинают задавать себе вопрос, а что если завтра нужно будет добавить ещё один протокол или изменить получателя… В результате вместо простой связки интерфейса и класса рождается монстр, близкий по функционалу к BizTalk с возможностью изменения протоколов в конфигурации. Только часто бывает, что день, когда вас попросят добавить 2ой протокол так и не наступит, а вам придётся поддерживать и исправлять ошибки в десятках тысяч строк ненужного кода (а ведь могло быть всего пара сотен строк...) Если бы у меня была такая задача, то я бы сделал интерфейс (для возможной расширяемости в будущем) и его реализацию в виде класса, который делает только то что нужно для данного протокола. Закинул бы его через DI или ServiceLocator и всё…
После перехода всех на Agile общее качество продуктов ухудишлось (зато стала быстрее скорость доставки — что нужно бизнесу). Всё дело в том, что в стандартной водопадной модели проектирования очень много внимания уделяется проектированию, архитектуре и пишутся технические задания и т.д. Т.е. система рассматривается и разрабатывается от целого к частному. В Agile же система — это набор фич. И в результате получается что лепится ядро, а потом к нему начинают прилеплять фичи. А так как о большинстве фич изначально даже и не думали, то появляются монстры которые трудно поддерживать…
Я конечно не агитирую за возврат к водопадной модели, но даже с аджайлом можно уделять больше внимания проектированию и архитектуре.
Да, поддерживаю. При работе с деньгами такие вроде-бы простые на первый взгляд вещи как откат транзакций (да и транзакции вообще), закрытие операционного дня и т.д. превращаются в очень сложные процессы (особенно, когда это происходит для каждого отделения в отдельности). Там очень много тонкостей начиная от округления при расчёте итогов и до конвертации валют. Простой пример: при расчёте пени можно сначала округлить до копеек, а потом посчитать итог, а можно сначала посчитать итог, а потом его уже округлить — а в результате разница в отчёте может оказаться в несколько сотен тысяч рублей…
А вот про единую банковскую платформу — это конечно интересно, но скорее всего невозможно из-за разных процессов в каждом банке (которые они чтят и берегут как традиции), да и сейчас преимущество в софте — это почти единственная разница между банками. Так что единую систему мы ещё очень не скоро увидим…
Вот перед вами 50 резюме от кандидатов. Как вы определите по ним М-людей? Ну допустим кто-то менял работу каждые пол-года, а дальше как? Как вы определите кого звать на интервью в первую очередь? Мне кажется предыдущий опыт и знание требуемых технологий всё-таки приоритет №1. А уже из них нужно выбрать не «М»-людей…
Поддерживаю. В Канаде библиотека — это не хранилище книг, а научный и культурный центр. Чтобы туда зайти даже не нужен читательский билет, а все книги доступны и ты можешь взять любую и почитать. Конечно, если хочешь взять домой, то тут уже нужена карточка библиотеки. В моём городе, например, в центральной библиотеке недавно открыли maker-space — т.е. место где ты можешь что-то делать своими руками. Там есть 3Д-принтеры, швейные машинки, компьютеры с программами для работы с изображениями, видео и т.д.
Так что мне не жалко $500 в год из моих налогов на это…

Поэтому предложение отдать библиотеки в частные руки попахивает приближением к миру из «1984» или «Postal 2». Дальше видимо начнут заменять «неправильные» книги «правильными» и создадут министерство правды…
Чем меньше информации, тем больше должен быть диапазон оценки и множитель рисков.
Если есть только общее описание системы, то допустимы отклонения на годы, если есть детальное описание модулей и выбраны технологии, то диапазон оценок может быть в месяцы, если есть детальные юзер-стори, то диапазон оценок может быть в неделях, для конкретной юзер-стори диапазон оценок может быть в днях.
Так если HR не отфильтрует резюме должным образом, то до этапа №2 многие хорошие кандидаты так и не дойдут, потому что в вакансии указано Microsoft SQL Reporting Services, а у кандидата в резюме написано SSRS (что то же самое). Так что HR просто обязан иметь представление о том, кого он ищет и готовиться к поиску сотрудника для каждой вакансии (как я сказал выше — минимум 1-2 дня и со взаимодействием с «заказчиком»). А если он этого не делает, то его лучше уволить, и нанять студента за минималку (искать ключевые слова в резюме) или даже автоматизировать.
Значит нужно пересмотреть систему оплаты — например ввести бонусы за хорошего кандидата или премию, если сотрудник проработал в компании больше года.
Нет, я этого не говорил, но прежде всего мы же ищем специалиста, а только потом человека. Что толку от крайне положительного и умеющего решать логические задачки сотрудника, если он вообще не понимает что нужно делать… Также как и не будет толку от гения программирования, кторый совсем не умеет ладить с людьми и постоянно провоцирует конфликты… Главная мысль предыдущего коментария в том, что HR должен знать кого ищет, разбираться в требованиях к вакансии и уметь сопоставлять их с предыдущим опытом кандидата. Тогда то мы и сможем найти позитивного человека который отлично разбирается в технологии…
Если вы прочитали мой комментарий выше про то, что спрашивать на интервью, то там целых 2 части вопросов о том «не мудак ли человек» — это про «подходит ли человек команде» и «что компания может получить от кандидата» (это те самые неэкономические факторы). Обсуждая предыдущий опыт кандидата и рассматривая ситуационные задачи можно выъявить «мудака», а если это хитрый «мудак», то и гномики вам не помогут…
Не читать резюме, а тем более отсеивать кандидатов выкидыванием половины — это очень большая ошибка. Вы нанимаете человека, на которого будете тратить деньги компании и в ваших интересах найти лучшего кандидата из возможных. Лучше потратить один рабочий день (это допустим $100) на просмотр резюме и найти лучшего кандидата (которому вы будете платить $2000 в месяц). Это намного лучше, чем потратить 2 час выкинув половину резюме, и сэкономив $75, платить не самому лучшему кандидату те же $2000 в месяц.
Кругозор не запретное слово, но одно дело обсудить с кандидатом как работает блокчейн или обсудить его домашние проекты и технологии, которые он считает перспективными и хочет попробовать, и совсем другое — насиловать ему мозг задачами в стиле «почему люки круглые»…
Вообще интервью — это переговоры о сделке, где обе стороны равные и отношение должно быть такое же. Представьте если клиент, который хочет заказать разработку приложения в вашей фирме, вдруг начнёт вас про «гномиков» спрашивать…
Для начала HR-у нужно разобраться в терминологи, понять что значат аббривиатуры, какие у названий есть синонимы и родственные технологии. Допустим мы ищем разработчика отчётов на SSRS. Соответственно HR должен выъяснить что такое SSRS, какие ещё есть системы построения отчётов похожие на него, какие скилы важны (в данном случае SQL), найти синонимы и родственные технологии: MSSQL, Oracle, Crystal Reports, Telerik Reports и т.д. Обсудить требования команды к кандидату.
В результате когда HR начнёт фильтровать резюме и увидит у человека 5 лет разработки отчётов на Crystal Report, он поймёт, что данный кандидат может быть подходящим и пригласит его на собеседование, хотя в резюме ни слова не сказано про SSRS…
Дополню ещё свой комментарий по поводу того, а что спрашивать:
мне кажется вопросы должны быть из 3 категорий: Первая и самая важная — насколько хорошо кандидат будет выполнять свои обязанности. Вопросы и задания для этой категории должны быть связаны с тем, что человек будет делать на позиции. Поэтому никаких задач «про гномиков» быть не должно. Например, если компания делает мобильные приложения, то можно спросить про фреймворки, особенности платформ, попросить описать архитектуру мобильного приложения, спросить про REST-сервисы и т.д. Если хотите проверить насколько кандидат разбирается в коде, то покажите фрагмент кода и попросите рассказать что он делает, найти ошибки, оптимизировать — это, в отличии от написания кода на бумажке, сэкономит ваше время и уменьшит стресс для кандидата.
Вторая категория вопросов — психологические и насколько человек подходит команде. Тут можно спросить несколько ситуационных вопросов, а также обсудить похожие ситуации из предыдущего опыта кандидата или компании.
Третья категория вопросов — что компания может получить в качестве бенефитов от найма данного сотрудника. Тут можно обсудить предыдущий опыт, хобби, предпочтения в карьерном развитии и т.д.
А олимпиадные задачки, задачки на логику, стресс-тесты и написание кода на бумажке должны остаться в прошлом…
Проблема HR-ов в том, что чаще всего они оторваны от потребностей команд, которым нужен сотрудник. В идеале HR должен очень хорошо знать процессы на предприятии и понимать что требуется для каждой конкретной вакансии. Перед тем как начать фильтровать кандидатов хороший HR должен потратить 1-2 дня для формирования требований и составления карты навыков, обсудить все детали с командой, которая заказала найти специалиста и т.д. Т.е. когда HR ищет программиста — он должен иметь представления о терминах, технологиях и т.д. Когда HR ищет охранника — он должен знать всё о том как работает охрана и т.д. При фильтрации резюме HR должен сделать первичную выборку и показать «заказчикам» 2 набора резюме — тех кого приглашаем на интервью, и тех — кто под сомнением. Т.е. нужно постоянно взаимодействовать с командой, заказавшей специалиста. Если HR только улыбается, рассказывает о том, какая у нас хорошая компания, задаёт глупые вопросы вроде «Кем вы видите себя через 5 лет» и фильтрует резюме только по ключевым словам из описания вакансии (или по субъективным представлениям — как на заглавной картинке к статье), то такого HR-а лучше выгнать…

Информация

В рейтинге
Не участвует
Откуда
Winnipeg, Manitoba, Канада
Зарегистрирован
Активность