Эта статья по поводу вечного джуниорского вопроса =) Где взять опыт работы, если опыта нет, а на работу берут только с опытом. Вот мой опыт.
Так получилось что у меня есть ментор. Это человек который может помочь советом, проревьюить код, если в хорошем настроении =) рассказать что-то новое.
И вот какое-то время назад он рассказал про один проект. OrientDB — это opensource графическая NOSQL база данных, интересная очень штука. Но конкретно OrientDB позиционирует себя как очень быстрая база, а еще у нее есть клевый графический модуль, еще она поддерживает blueprints. Поддержка вершин (vertex) и ребер (edge). И в частности про ETL процессор. Это такой тулз, который принимает на вход различные файлы с данными, и конвертит их в базу.
У него возникли проблемы с трансформацией из CSV файла. Предложил нам покрыть его тестами, и провести реформат кода. Тесты писались в JUnit. За основу для написания тестов была взята документация непосредственно из OrientDB и из RFC 4180. В ходе покрытия тестами было выявлено несколько багов. К примеру вот баг с представлением отрицательного числа как строки. Вот еще такой баг,
согласно RFC 418
(6. Fields containing line breaks (CRLF), double quotes, and commas should be enclosed in double-quotes. For example:
"aaa","b CRLF bb","ccc" CRLF
zzz,yyy,xxx )
тоесть если внутри двойных кавычек есть CRLF, то это всеравно одно строковое поле.
Вот еще такое issue о неправильной обработке null в значении поля. Ну и конечно реформатирование кода.
В результате наш CSV трансформер более или менее работоспособен. Но конечно доделывать его еще надо. Изучен фреймворк JUnit3,JUnit4. Изучена работа с GitHub. Немного просмотрены внутренности этой DB. Получена куча фана.Теперь я контрибъютор в большом проекте.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ