Ярослав Корнилов

fs.readFile работает асинхронно. Передавайте в getDataObj callback или юзайте промисы.
Примерно так:

const getDataObj = (cb) => {
  const regex = /<email>(\D+?)<\/email>/g;
  fs.readFile('uploads/dataset.xml', "utf-8", function(err, data) {
    let m;
    let result = "";
    while ((m = regex.exec(data)) !== null) {
      if (m.index === regex.lastIndex) {
        regex.lastIndex++;
      }
      m.forEach((match, groupIndex) => {
        if (groupIndex === 1) {
          result += match + '\n'
        }
      });
    }
    return cb(result)
  })
}

app.get('/', function(req, res) {
  parser.getDataObj((message) => {
    res.render(path.join(__dirname, 'views/index.pug'), {
      pageTitle: 'Hey',
      message: message
    });
  });
});

Проблема в том, что разработчики не могут писать код без ошибок.
Более того, в сколько-нибудь сложных программных системах при внесении каких-либо изменений слишком сложно понять, как это отразится на других частях.
Для того, что бы минимизировать поиски этих багов и ускорить их обнаружение пишутся юнит тесты.

ТДД про то, что бы писать тесты до кода.
Зачем это надо? Потому что такой подход помогает лучше структурировать в голове необходимую функциональность перед написанием непосредственно кода.
Такой подход позволяет избегать избыточного усложнения кода, потому что подход "tests first" не позволяет написать полотнище сложного кода, не проверив правильность его работы.
Плюсов достаточно.

Теперь по поводу того, нужно ли ТДД всегда.
ТДД нужно не всегда, как и красивый, производительный и правильно работающий код.
Иногда, нужно закостылить MVP, проверить бизнес-идею и продолжить жить. В таком подходе 20% времени, потраченные на юниты - непозволительная роскошь.
Иногда, вы пишете систему, сложность которой такова, что держать в голове матрицу состояний даже одного модуля не представляется возможным. И тут уже без юнит-тестов никак. Тут ТДД будет полезно.

Резюмируя. ТДД - отличный инструмент. Он позволяет не откладывать на потом написание юнит тестов, добиваться хорошего покрытия и, что важнее всего, контролировать изменения, вносимые в систему. Любая неожиданная ветка поведения приведет к падению тестов.
Как и любой инструмент - ТДД хорошо тогда, когда ты применяешь его своевременно, правильно и по назначению.
Писать тесты когда продакшен в огне, а компания терпит крах - плохая идея. Везде нужен здравый смысл.

const compiledFunction = pug.compileFile('template.pug');

Почему мы потом передаем compiledFunction объект с переменными шаблона, ведь это вроде не функция?

Не смущает ничего? =)
Получаем функцию, скомпилировав шаблон. Передаем туда объект с переменными и получаем результат. По-моему все нормально =)

оператор отрицания превращает все это в выражение. Значение выражения вычисляется.
Так же будет работать если анонимную фунцкию обернуть в скобки.

1. Элемент span не имеет семантической нагрузки. Он нейтрален. Значит код семантичен.
2. ПС умные, см. пункт 1.

Чтобы понять принципы ООП, книги не требуются. Взгляните вокруг себя. Всмотритесь в любой объект в реальном мире, опишите его наиболее подробно (материал, размер, цвет, вес, плотность, составные части и т.д.), это будут его свойства. Опишите, что и каким образом этот объект умеет делать (включаться, складываться, кушать электроэнергию, взаимодействовать с другими объектами или окружающей средой и т.д.), это будут его методы. Подумайте, для чего используется этот объект, что ему нужно изменить или добавить, чтобы использовать в других условиях или целях, и на основе всех собранных знаний создать более удобный экземпляр, это будет наследование и полиморфизм. Теперь немедленно забудьте обо всем, используйте объект по назначению, это будет инкапсуляция. Дальше останутся только тонкости выбранного Вами языка, шаблоны, методологии и прочаяие ересь тренды.

Как уже имели ввиду выше, для написания обычных приложений под смартфоны, сайты, программы, математика особо не нужна. А для нормально кода достаточно нормального мышления и практики.

По началу будет достаточно знаний языка, паттернов, фрейморков и простых алгоритмов. Далее, для более серьезных вещей, желательно будет выучить алгоритмы и мат. методы посложнее, но все уже реализовано до вас, так что от вас будет достаточно знания того, что эти методы и алгоритмы делают, а что у них там внутри уже не ваша проблема.

Я вопринимаю генетические алгоритмы именно как способ оптимизации.

Для моделирования эволюции я бы посмотрел на какие-то решения в области имитационного моделирования, например Beagle