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

Достижения

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

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

Все теги (125)

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

Все ответы (597)
  • Как передать на бекенд требования к API?

    @Vitsliputsli
    Многие фронтендеры относятся к беку, как к некой обертке для работы с базой данной. Когда такие становится лидом команды и начинают диктовать свои требования беку, начинается ад, проект даже с простым беком превращается в нечто монструозное, разваливающиеся на ходу. Но, так как снаружи бек не виден, руководство считает, что дело в отдельных тупых бек-разработчиках, которые артачатся, не хотят работать и увольняются.
    Судя по вашим фразам, вы скорее всего один из них. Так как уверены, что приложение - это то, что на фронте, что api - это хрень, которая завязана на отображении информации на фронте, что разработчики бека не нужны при разработке архитектуры и вообще пофиг, что они там делают, главное чтобы давали то, что хочет фронт.
    Но, раз вопрос задан, значит сомнения вас посещают. Поэтому: приложение это не только фронт, а зачастую фронт это не самая сложная его часть. Бек - это не обертка над базой данных, и если вы поменяете значение в базе, это не значит, что к примеру, в потоковом вещании сменится кодек (вот, кому-то может и смешно, а мне в такой ситуации ни фига не было весело). С помощью API получают данные, поэтому не важно, что там у вас напроектировали дизайнеры, или как эти данные выводит фронт, API должен быть универсальным и не зависить от того как вы отображаете данные, поэтому, к примеру, бек может вам дать для получения данных несколько универсальных запросов, а не один специальный. В общем, все гораздо сложнее, и ваш вопрос как состыковать фронт и бек перерастает в вопрос как формировать архитектуру проекта, и как управлять командой.
    Ответ написан
    17 комментариев
  • Какой самый экономный дистрибутив Linux?

    @Vitsliputsli
    Места в принципе не жалко, но это не значит, что я должен впускать таджиков в 10-комнатную квартиру, даже если живу там один,

    Chrome один займет 8 из 10 комнат.

    нужна только для доступа в интернет через Chrome, другие программы использоваться не будут

    если это действительно так, можно вообще не использовать DE и запускать только иксы и в них Chrome
    Ответ написан
    Комментировать
  • На собеседовании сказали, что не все функции - замыкания. Так ли это?

    @Vitsliputsli
    Абсолютно понимаю автора, он цитирует определение замыкания, а ему в ответ - определения не нужны, они лишь путают. Он спрашивает, а как тогда? Ему кто про мусорщик, кто про стек, и у него создается ощущение, что сами не могут договориться. Но кроме этого, автор прав, его функция - замыкание.
    Замыкания везде работают одинаково. Если функция содержит ссылки на переменные объявленные вне тела этой функции, и которые не являются ее параметрами - это и есть замыкание. Что значит фраза - все функции в javascript - замыкания? Дело в том, что в других языках область видимости может просто не позволить обращаться к внешним переменным, в таких языках функция не будет замыканием, но может быть возможность превратить функцию в замыкание через специальный синтаксис. В javascript таких манипуляций не нужно, поэтому в нем любая функция - замыкание.
    Т.е. замыкание это возможность в функции создать ссылки на внешние переменные. А здесь уже как следствие, работа мусорщика, если есть рабочая ссылка, то объект не уничтожается, а в приведенных примерах с 2 функциями она рабочая, так как можно получить доступ из корневого объекта, что удовлетворяет требованиям алгоритма mark-and-sweap. Но это следствие, а не принцип работы замыкания.
    Поэтому автор абсолютно прав - его функция это замыкание. Потому что ни в одном определении замыкания нет никаких упоминаний о мусорщике, а значит разницы нет на какие внешние данные ссылаться.
    Другое дело, все хотят видеть не замыкание, а его хитрое использование, а именно сохранение ссылки объявленной в замыкании при уничтожении ссылки во внешней функции. Не надо считать собеседующего бездарем, если бы вы ему объяснили свою точку зрения, он вполне мог бы и согласиться, хотя и не факт, многие собеседования проходят в виде допроса, что говорит о неадекватности или о слабой квалификации собеседующего, в такие конторы не стоит идти.
    Ответ написан
    1 комментарий
  • Есть ли смысл использовать Git?

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

    @Vitsliputsli
    Ничего страшного, допишите еще один case и метод, и все будет нормально. Да, это нарушает принцип, но все так делают, просто хрен кто признается. Не пытайтесь здесь вкрячить какого-нибудь монстра, сложный код - это потенциальные ошибки, если возможно написать просто, так и нужно сделать.
    Принципы - они принципы, а не законы, надо следовать не букве, а смыслу. Принцип открытости и закрытости оберегает нас от ошибок и дополнительных затрат на тестирование кода, который вроде бы и так уже работает и хорошо себя зарекомендовал. Т.е. если бы у вас был один метод и вы там внутри как-то хитро разруливали работу с разными типами и при добавлении нового типа изменяли бы его - это было бы ужасно. В текущей реализации, вам нужно будет добавить новый метод (это не изменит поведение класса до вмешательства), и добавить новый путь при использовании нового типа - да, вмешательство, но оно минимально. Если умудритесь накосячить здесь, то вас уже никакие принципы не спасут.
    Если же у нас, что-то гораздо более сложное, либо класс физически недоступен для изменений, или он уже вовсю используется, а новый тип нужен только для конкретной реализации, то, пожалуйста, есть наследование. Наследуете класс, в потомке добавляете метод и заменяете метод, выполняющий перенаправление (не забывайте, что есть вызов parent). Это будет полностью соответствовать принципу.
    Но я бы больше уделил внимание тому, почему мы ориентируемся для выбора метода на внутреннее свойство, точно ли это должны быть методы, а не отдельные классы. И вполне может быть получится так, что все эти танцы с бубнами не нужны.
    Ответ написан
    Комментировать