Контакты

Достижения

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

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

Все теги (29)

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

Все ответы (71)
  • Есть ли смысл использовать typescript на node.js бэкэнде?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    типизация, дженерики, продвинутое ООП, это не круто, а необходимость контроля над ошибками, быстрой навигации, и декомпозирование сложных сущностей, а вобщем более надежная от ошибок разработка сложных систем и более понятная и легкая поддержка кода. Скорее, да, для простых проектов это может быть излишне (дополнительный код), для сложных и больших, наоборот все окупается. Это как экскаватор и лопата, для мелких ям лопата, для больших котлованов экскаватор.
    Ответ написан
  • Какой необходимый уровень знаний для Junior Angular 4+ разработчика?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    Лучше всего не задавая вопросов, попросить показать портфолио, и посмотреть вместе исходники, поспрашивая параллельно, что и как претендент там делал и сколько времени на это потратил. Если нет проектов в портфолио, то сделайте и показывайте проект, в котором просто будет логин/логаут, регистрация, вход через соц. сеть (типа вконтакте), восстановление пароля. Если человек может сделать такой проект, как правило с остальными задачами проблем не будет. Потом дать небольшое задание на день-два по специфике работодателя и выяснить исполнительность. Вопросы, списки вопросов и т.п. это пустая болтовня, ни работодатель, ни претендент не поймет подходит ли человек на позицию. В случае невыполненной работы(проекта) работодатель потеряет деньги, а претендент время, квалификацию, репутацию, нервы и самоуважение. Человека нанимают не на вопросы отвечать, а продукты делать.
    Ответ написан
  • Стоит ли использовать Angular2, vue.js для упрощения разработки, если я их не знаю, или стоит остановится на JQuery/Vanilla в моём случае?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    если задача небольшая лучше остановится на JQuery/Vanilla, сообщения нигде не будут подвисать и приходить одинаково по сокетам, а отображение элементов с jQuery быстрее чем любом Vue/Angular/React, они нужны для более понятного организованного кода, и ничего там быстрее не работает. Открою вам страшную тайну на React/Vue/Angular переходят из-за опасения запутаться в собственном коде.
    Ответ написан
  • Как быть с camelCase на фронте и snake_case на бэкенде?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    Если бекендер очень высокого уровня, то есть умеет красиво и оптимально проектировать методы и данные под потребности клиентских app, четко это документировать (swagger) и покрывать тестами свои методы, то обычно таких проблем не возникает.
    В противном случае контролируйте все что приходит с бекенда, сделайте статические мапперы, подстраиваться под бек не вариант, всякие линтеры начнут ругаться, вы начнете запутыватся в плохоименованных переменных, уговаривать бекендеров слать данные в нужном формате то же больше времени потратите, третий вариант сам приемлемый, бекенд часто шлет, не то что в нужном формате а еще много того что не нужно на фронт.
    Например: бекенд шлет (это частая ситуация, так в бд например хранится, а правила кодирования у разных клиентов (web, ios, android) свои, но они могут использовать один и тот же бек)
    {
      ID '2342',
      stu_cfg: 'werwer'
      pfu_num: '1231'
      sys_created: '2000-12-10'
      register_date: '06 Mar 2017 21:22:23 Z'
    }

    бы обозначаете что вам нужно и в каком виде (в тайпскипте например) (или в js комментариями)
    interface SomeEntity {
      id: string,
      status: string,
      created: Date
      registered: Date 
    }


    class MyMapper {
        static someEntityToClient(data): SomeEntity {
            const someEntity: SomeEntity = {
               id = data['ID'],
               status = data['stu_cfg'],
               created = moment(data['sys_created']).toDate
               registered = moment(data['register_date']).toDate 
            }
            return someEntity;
        } 
    }

    И вызовите маппер сразу после апи вызова как только получили данные. Таким образом вы решите проблемы:
    1) ненужные данные отфильтруете, чтоб не ломать голову (что это? зачем?) потом во время отладки фронта
    2) в коде будет единый стандарт именования переменных (плюс закодированные имена (cfg, klk и т. п.) пропишете понятно).
    3) в бизнес логике будет единый стандарт типов данных (как например со временем) (преобразований не надо потом нигде по 10 раз делать, проверки отпадут, вы все проконтролировали на входе)
    Ответ написан

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

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