Как стать автором
Обновить
6
0
Алексей Барышников @chelovekkakvse

Инженер-разработчик

Отправить сообщение

Г-ди, испанский стыд то какой

Так рекурсивный подход используется в динамическом программировании, разве нет? И если рекурсия хвостовая, то ее можно написать в виде цикла.

Рекурсивно и динамически?

Меня больше всего волнует мусорность коммитов и, как было описано выше, коллизии с пулреквестами. Так же сталкивались со временем сборки, которая в лучшем варианте была полчаса. Что касается зависимости бэка и фронта, то в данном случае придётся тестировать сразу 2 ПР. Мы мокали заранее оговоренный сваггер и пушили в свои ветки. Потому это все поднималось на дев среде в контейнерах и тестилось е2е. Потому все поднималось на проде. П.С. У нас был ньюанс. Было с десяток фронтовых микроаппов и около 20-ти микроаппов бэка, что не так много.

Если про фронт я ещё могу понять идею моно репа, то как вы относитесь к монорепу, где лежит и бжу и фронт?

Да, виноват, по диагонали код автора прочитал. Там впринципе тупо сделано.


Пожалуй надо было так:


class BaseTooltip {
  type = 'baseTooltip';
  content;

  constructor(someField) {
    this.content = someField;
  }

  render() {
    console.log(this.type, this.content);
  }
}

class SpecialTooltip extends BaseTooltip {
  type = 'specialTooltip';

  constructor(content) {
    super(content);
  }
}

const newChild = new SpecialTooltip('child');
newChild.render();

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

Просто кто-то не знает как работает прототипное наследование. Не буду оригинальным — RFM.

Друзья, вы меня конечно заминусите, но:
  1. Прежде чем жать кнопу «Опубликовать» посмотри как выглядит текст — больше половины жирным шрифтом.
  2. Тащить сюда говнокод и называть это «поисковые алгоритмы» оскорбительно для аудитории.
  3. Где здесь HTML5? В тегах написано...
  4. Зачем jQuery для этой задачи в принципе и почему эта либа тут упоминается для меня осталось загадкой.


eval(search))


Это… ну я даж не знаю… Автор, прочти..

Цитирую Badoo: Подход из статьи нам близок: при решении своих задач мы тоже чаще всего используем связку PHP и Go, получая преимущества от обоих языков и не отказываясь от одного в пользу другого.

Затем, что проект размера Badoo, большая часть которого написана на пхп, двумя пальцами на жаве не перепишешь. Это слишком дорогой. Кроме того, зачем ломать то, что работает? Ещё и штат новый набирать? А со старыми что делать?

Не оправдывая DSL, считаю, что основной проблемой платформы является ее монопольность. Если были бы другие интерпрайзные решения по бухгалтерии и складу, особенно опенсорс, то и 1С пришлось бы развиваться. А так… Зачем?

Если честно, то хочется спросить — иии? Где пример реализации и прочий контент?

Ну так я и написал, что рефакторинг не столько про код-стайл. Однако автор поста кодстайл приравнял к рефаторингу, поэтому я и обратил внимание.

Не соглашусь с Вами по поводу переработки логики программы. Можно оптимизировать алгоритмы, переопределить классы, использовать паттерны, но если у вас на выходе должен быть массив данных определенного формата, то он де должен и остаться после реафкторинга.
Они влияют на читабельность кода. А читабельность кода влияет на скорость правок, дополнений и тд. Если в команде единый кодстайл, то каждому будет легче читать чужой код. В общем-то рефакторинг не только (и не столько) про «скобки по феншую».

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


Чтобы сократить эстетического приведения кода в порядок — линтеры. Их можно настроить как хуки, перед комитом/сейвом будет все форматироваться или ругаться. Для похапе (мб и для других) есть кодсниффер, который переоткрывает таск разрабу, который закомитил код не по стилю. Так что некоторые вещи при рефакторинге можно автоматизировать, а другие спасут вашу попу в случае "Мэй Дэй". Но по кодстайлу надо договориться на берегу, чтобы потом не было "так положено".

Мне кажется тогда проще использовать прототипирование. Иначе какой-то дуализм выходит.

Честно говоря не совсем понимаю Крокфорда. Если в мире сложились стандарты и общие представления ООП для всех языков, то зачем в JS городить свои велосипеды и все усложнять? Основное преимуществ ООП, на мой дилетантский взгляд, легкость обслуживания приложения в дальнейшем. И если в JS ООП будет, как и везде, то жить станет легче.
Главное — не останавливаться :)

Ни в коем разе :)
Да, когда писал смотрел куда в другую сторону, поправил.

Я, честно говоря, не вижу в данном подходе какой-то сложности. По-моему это типичное решение аля синглтон. Мы имеем один экземпляр сервиса в приложении и в случае обращения нему — обращаемся к этому экземпляру или создаем новый, если он не был создан ранее. Если, конечно, мы не создаем сервис внутри директивы\компонента и т.д.

П.С. Прозвучит как оправдание, но это мой первый опыт перевода.
1

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность