Бесточечная отладка

Итак, мы используем в работе очень хорошую библиотеку ramda, и это здорово, потому что мы можем использовать в основном бесточечный стиль кода. Проблема в том, что гораздо меньше мест, где можно посмотреть, когда что-то идет не так, указывает на что-то в нашем коде; большинство ошибок во время выполнения возникают из-за неправильного использования составных функций ramda. Объедините это с передачей этих функций в фреймворк, который использует много перенаправления (мы на реакции/редукции), и часто, когда что-то идет не так, это глубоко в библиотечном коде, и очень трудно понять, куда я пошел. неправильный.

Есть ли способ смягчить эту проблему, не отходя от бесточечного стиля?


javascript debugging ramda.js pointfree
person jstaab    schedule 27.10.2016    source источник

Ответы (2)


arrow_upward
7
arrow_downward

Один из вариантов — использовать R.tap, например:

const f = R.pipe(
  R.tap(console.log),  // logs x
  g,
  R.tap(console.log),  // logs g(x)
  h,
  R.tap(console.log),  // logs h(g(x))
  i,
  R.tap(console.log),  // logs i(h(g(x)))
  j,
  R.tap(console.log)   // logs j(i(h(g(x))))
);

f(x);

Другим вариантом является использование Sanctuary, которое вызывает информативные исключения, когда функция применяется к аргументам неправильных типов.

person davidchambers    schedule 27.10.2016
comment
Также полезны treis Рейн Вирта и Ramda-debug. - person Scott Sauyet; 27.10.2016
comment
Я уже использую журнал прослушиваемой консоли (кстати, ваш пример не будет работать, потому что log не привязан к console) для отладки конкретных проблем. Мне больше интересно, как вообще кодировать стиль, когда, если функция ramda вызывается неправильно, я получаю разумную ошибку. Эти библиотеки действительно полезны. Есть ли у них преимущество перед потоком/машинописи? - person jstaab; 27.10.2016
comment
R.tap(console.log) работает в узле, но не в браузере. R.tap(console.log.bind(console)) работает в обеих средах, но набирать его немного неудобно. Конечно, для этого можно определить псевдоним. :) - person davidchambers; 28.10.2016

arrow_upward
4
arrow_downward

Я столкнулся с той же проблемой с Ramda в своих побочных проектах. Это то, что заставило меня отказаться от этого в производстве, на данный момент.

На момент написания этого ответа отладка программ бесточечного стиля в JavaScript очень сложна или невозможна. Это единственная причина, по которой я им не пользуюсь. Я обнаружил, что даже при хорошем покрытии юнит-тестами цикл разработки слишком длинный, а отладка — сложная.

Я остановлюсь на этом: хотя такие инструменты, как Ramda-debug и R.tap(), существуют, они являются активными инструментами отладки, которые вам нужно добавить в свой проект, а в некоторых случаях добавить в свой код и удалить позже в процессе производства. Однако, когда вы получаете сообщение об ошибке, вы не получаете полезную трассировку стека, и вы не можете пройти через отладчик, чтобы понять поток, вам нужно знать поток заранее.

person Madara's Ghost    schedule 27.10.2016
comment
Вы когда-нибудь пробовали что-то вроде потока или машинописного текста? - person jstaab; 27.10.2016
comment
Я нет, я сейчас изучаю TypeScript, хотя - person Madara's Ghost; 27.10.2016
comment
@jstaab Я использую TypeScript каждый день в сочетании с Ramda или Lodash/fp. Позвольте мне сказать вам: TS не любит функциональное программирование. Определение интерфейсов для каррированных функций возможно, но довольно болезненно. В любом случае, это не поможет вам в отладке. Это принесет только некоторую предельную безопасность статического типа. Однако есть и другие преимущества, которые выходят за рамки этого вопроса. - person RIAstar; 28.10.2016