Style

[Suntrie]

1. Что по названию класса "BuildMap" можно сказать о наборе поставляемых им услуг? По методу buildMap то, что поставляет основную функциональность приложения?
   Кроме этого, требуется явная мотивация, почему Вы пробрасываете в BuildMap результаты парсинга по полям, а не как объект класса (Parser и InputData можно попробовать разделить на 2 разных класса - не уверена, что алгоритмически это так уж требуется, но можно, читаемость
   повыситься, и как передавать данные, возможно, станет очевиднее). Вообще, хорошее упраженение - попросить прочитать кого-либо из коллег код Вашего приложения до
   его сдачи, и оценить, насколько понятно, насколько читаемо.
2. Про то, что такое Builder, можно почитать, например, здесь: https://habr.com/ru/company/otus/blog/552412/. По возможности, нейминга типа build, если он не имеет отношения к этому паттерну, лучше избегать.
   В большинстве случаев build будет относиться к построению объекта, а не к осуществлению каких операций, специфичных для Вашего решения. Т.е., в лучшем случае, когда
   увидите buildOutput(), от него будете ждать построения строки, а не вывода её в нужный "приёмник".
3. GetFilesList - классы, в абсолютном большинстве случаев, называются существительными. Т.е., вероятно, просто FilesList. Методы, наоборот - глаголами/глагольными выражениями.
   Т.е., в соответствии со стандартной нотацией скорее желательно outputToFile (вывести в файл), например, вместо fileOuptut (вывод в файл). Хотя с учетом функциональности это
   скорее proccessAndPrintToConsole ("индейское имя" в качестве названия -> потенциально, лучше заменить на 2 последовательных вызова)
4. HumanOutput. Неиспользуемый метод
5. Typo: parametres -> parameters