А я пишу о том, что вижу в статье.
Человек закрывал задачу 2 дня, потому-что стеснялся попросить помощи и сделать все сам, а потом написал статью о том, как он героически эту проблему решил.
Только бизнесу не нужно что-бы сотрудники сидели и сами решали проблемы, можно попросить помощи и за 2 дня решить 5 таких проблем, но уже вместе с тестировщиком, вместо того, что-бы тестировщик простаивал, а разработчик выполнял работу за двоих.
Ваш случай конечно тоже возможен, тут главное поймать золотую середину.
Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование
Вместо того что-бы попросить тестировщика рабочий час которого дешевле раза в 2 к тому же который уже нашел багу — мы сидим и занимаемся не своей работой, нормально так.
Потому что я исследовал, существуют ли другие способы решения получения же проблемы, а не только описанные этапы, как её воспроизвести.
Опять 25, подозреваешь что есть 10 других способов повторить баг? Говоришь об этом тестировщику и он дополняет задачу.
Потому что я потратил время, чтобы проверить, есть ли другие части кода, которые могут быть затронуты этой проблемой.
Уже давно по ctrl+click в любой IDE показывает такие места мгновенно.
И тесты тоже никто не отменял.
Потому что я тщательно протестировал это изменение и убедился, что оно решает проблему для всех различных путей кода, которые были затронуты.
Опять боязнь тестировщика, зачем его нанимали в компанию?
Люди любят заниматься чужой работой, только вот работодатель не любит когда программист на ставке в 40$ занимается работой цена которой 8$
Разрабатываю на angular с 2 версии по 10, не сталкивался с проблемами производительности. Думаю в любом фреймворке/библиотеке проблемы производительности из-за прослоек между креслом и монитором.
У меня там не только модели, а трейты которые раcширяют модель
Например модель User — Entities\Users\User, скоупы для модели User — Entities\Users\User\Concerns\UserScoupes
так как если приложение большое — модель разрастается до пары тысяч строк и в ней нереально ориентироваться, поэтому скопы, мутаторы, релейшены и прочее находятся в папке Concerns
Так теги изначально идут в users
Как могут быть одинаковые теги для пользователя и например для лампочек?
upd
Но если это так необходимо сделать — то я бы в любом случае UserTag отнес бы к users, а не к tags
Что-бы каждый сам себе решал куда скидывать модели, так как папка Models не сильно хорошая практика, но вместо этого люди хранили в App, в таком случае лучше уже Models
В твиттере Тейлора 80% проголосовали за модельки в папке app/Models. В Laravel 4 модельки хранились в папке app/models, затем, начиная с пятой версии их, по дефолту, кидали в корень папки app. И, наконец, в 8-ой версии они снова получают свою собственную папку :)
Если проект чуть больше чем блог — модели в 1 папке хранить неудобно, не важно App или Models, так что не принципиально вообще
Я обычно храню в папке Entities и группирую по содержимому, например таблицы users и users_tags будут храниться в Entities\Users\User и Entities\Users\Tag
Angular Language Service — постоянно тормозит для VSCode.
Думаю это проблема vs code, в webstorm все летает.
с радостью писал бы на Angular, если бы компоненты можно было так же легко писать/рефакторить.
Признаю, что в jsx есть удобные фишки типа передачи компонента в параметры
Но рефакторить и писать компоненты в angular мне намного проще.
Ide рефакторит селектор компонента по всему проекту в пару кликов, то же самое и с названием класса и файла.
1 команда в cli генерирует компонент, дальше пишется только логика.
Может компонент кнопочки и проще писать в react, но все что больше кнопочки — наоборот.
Да, писал в браузере пока разговаривал по телефону)
Исправил
Синтаксис может и проще, но от невнимательности (криворукости) ничего не спасёт.
Только вот этот синтаксис существует в angular с 2 версии с кучей других плюшек
Но почему-то реактеры стараются придумать свое, лишь бы не так как у других, при этом выдавая это за конфетку, а разработчики vue повелись на хайп и подхватили.
Изначально придумали синтаксис с кучей mounted, computed, bind this и так далее, потом переписали это на хуки которые не сильно улучшили читабельность и выдают это за прорыв.
Я думал Боб Мартин еще лет 10 назад написал что хорошо для крупных проектов
Например DI, декомпозиция, продуманный нейминг переменных и классов, изменяемый код и так далее.
Вместо этого нам предлагают писать функции в функциях
Теперь посмотрим на супер новое апи, что читабельнее, функции в функциях:
Человек закрывал задачу 2 дня, потому-что стеснялся попросить помощи и сделать все сам, а потом написал статью о том, как он героически эту проблему решил.
Только бизнесу не нужно что-бы сотрудники сидели и сами решали проблемы, можно попросить помощи и за 2 дня решить 5 таких проблем, но уже вместе с тестировщиком, вместо того, что-бы тестировщик простаивал, а разработчик выполнял работу за двоих.
Ваш случай конечно тоже возможен, тут главное поймать золотую середину.
Вместо того что-бы попросить тестировщика рабочий час которого дешевле раза в 2 к тому же который уже нашел багу — мы сидим и занимаемся не своей работой, нормально так.
Опять 25, подозреваешь что есть 10 других способов повторить баг? Говоришь об этом тестировщику и он дополняет задачу.
Уже давно по ctrl+click в любой IDE показывает такие места мгновенно.
И тесты тоже никто не отменял.
Опять боязнь тестировщика, зачем его нанимали в компанию?
Люди любят заниматься чужой работой, только вот работодатель не любит когда программист на ставке в 40$ занимается работой цена которой 8$
Можно пример пиратского сервиса? Чтобы не было рекламы — можно в личку
Слышал модное словечко и не знаю куда втулить?
Тут о серверной проблеме речь, а Электрон только на клиенте.
Разрабатываю на angular с 2 версии по 10, не сталкивался с проблемами производительности. Думаю в любом фреймворке/библиотеке проблемы производительности из-за прослоек между креслом и монитором.
А что если заказчик попросит вас переехать с numl на react?
angular поддерживает web components.
Например модель User — Entities\Users\User, скоупы для модели User — Entities\Users\User\Concerns\UserScoupes
так как если приложение большое — модель разрастается до пары тысяч строк и в ней нереально ориентироваться, поэтому скопы, мутаторы, релейшены и прочее находятся в папке Concerns
Какой смысл было писать этот комментарий?
Непременно надо было напрягать себя и людей на бессмысленный траффик?
Как могут быть одинаковые теги для пользователя и например для лампочек?
upd
Но если это так необходимо сделать — то я бы в любом случае UserTag отнес бы к users, а не к tags
Если проект чуть больше чем блог — модели в 1 папке хранить неудобно, не важно App или Models, так что не принципиально вообще
Я обычно храню в папке Entities и группирую по содержимому, например таблицы users и users_tags будут храниться в Entities\Users\User и Entities\Users\Tag
Уже лет 5 телефон и компьютер на беззвучном режиме.
Последние пол года если никуда не собираюсь — вечером выключаю телефон, напряжения стало меньше
А в играх сколько FPS?
Думаю это проблема vs code, в webstorm все летает.
Признаю, что в jsx есть удобные фишки типа передачи компонента в параметры
Но рефакторить и писать компоненты в angular мне намного проще.
Ide рефакторит селектор компонента по всему проекту в пару кликов, то же самое и с названием класса и файла.
1 команда в cli генерирует компонент, дальше пишется только логика.
Может компонент кнопочки и проще писать в react, но все что больше кнопочки — наоборот.
Исправил
Только вот этот синтаксис существует в angular с 2 версии с кучей других плюшек
Но почему-то реактеры стараются придумать свое, лишь бы не так как у других, при этом выдавая это за конфетку, а разработчики vue повелись на хайп и подхватили.
Изначально придумали синтаксис с кучей mounted, computed, bind this и так далее, потом переписали это на хуки которые не сильно улучшили читабельность и выдают это за прорыв.
Например DI, декомпозиция, продуманный нейминг переменных и классов, изменяемый код и так далее.
Вместо этого нам предлагают писать функции в функциях
Теперь посмотрим на супер новое апи, что читабельнее, функции в функциях:
Обычный класс
Что читабельней?
А теперь представьте что функций будет больше 1
Из которого в 3 версии делают реакт?
Отличные новости.
Angular — лучик света в мире фронтенда.