Jak nie tworzyć parsera Markdown w Node.js

Jak nie tworzyć parsera Markdown w Node.js

Wymyśliłem sobie ostatnio nowy projekt - parser markdown w node.
Założenia były proste - parser miał wczytywać plik tekstowy (proste) i zwracać wynikowy HTML (trudne).
Tekstu nie można parsować po prostu linia po linii, bo (przykładowo), w bloku blockquote może znaleźć się dowolny inny znacznik i on też musi być poprawnie sparsowany.
W projekcie wyodrębniłem kilka warstw:

• Tokenizer, dzielący tekst na zagnieżdżone podbloki tekstu o takim samym formatowaniu. Jest potrzebny, ponieważ Markdown może zawierać zagnieżdżone cytaty czy bloki list. 
• TemplateChooser, który przyporządkowuje parser do bloku, na podstawie analizy tekstu przez regexy. 
• Kilka parserów, do parsowania różnych typów tekstu objętego znacznikami. Przykładowe nazwy, to HeaderParser czy BlockquoteParser. Każdy parser, wykorzystuje odpowiedni regex pobierany z utils. 
• Format danych, w którym słownie opisuje, jaki typ danych zawiera dany block i linia. 
• Obsługę wejścia.

W projekcie szybko zaczęły pojawiać się pytania, takie jak:

• Jak ma wyglądać hierarchia dziedziczenia? 
• Czy parsery powinny dostawać tekst ze znacznikami markdown, czy należy je najpierw wycinać? Ma to duży wpływ na potencjalne zmiany w bibliotece regexów. 
• Jak testować, czy nie dochodzi do regresji? 
• Jak wywoływać poszczególne metody z klas? Logiczne może wydawać się ich zagnieżdżanie, jednak z czasem pojawia się coraz więcej podpoziomów co nie wygląda dobrze. Możliwe rozwiązania,

uwzględniające asynchroniczność, to RxJs albo promises.
Gdy wyrywałem sobie włosy z głowy, ponieważ rezultaty prac były dalekie od sukcesu, mimo poświęconych kilku dni pracy, zobaczyłem to repozytorium...
https://codepen.io/kvendrik/pen/Gmefv
Twórca zastosował zupełnie inne podejście. Zamiast obiektowej nadmiarowości, wykorzystał w pełni potęgę funkcji replace() i całe parsowanie, wykonuje za pomocą wyrażeń regularnych. Cały tekst jest replacowany() przez kilkanaście wyrażeń regularnych, w wyniku dając oczekiwany wynik.
Bez kilku dziedziczących po sobie parserów. Bez tokenizera. Bez nadmiarowego formatu danych.

Jaki z tego wniosek?

Cała otoczka, którą zaplanowałem dookoła rozwiązania, była nadmiarowa. Podczas szukania rozwiązań problemów programistycznych, warto skupić się na tym, co już możemy wykorzystać - w moim przypadku, były to wyrażenia regularne. Dzięki temu, nasz kod może robić więcej i być znacznie prostszy.

Z drugiej strony, nadmierne uproszczenie kodu i przeparsowanie go przez kilkadziesiąt regexów może bardzo utrudnić późniejsze zrozumienie kodu oraz późniejsze wprowadzanie w nim zmian.