Я працюю над невеликою бібліотекою, яка забезпечує реалізацію основних, добре відомих рядкових показників. Переважно для моєї власної освіти. Тож розвиток відбувається коли-небудь у мене трохи вільного часу.
Через це я автоматизував більшість процесів, тому я можу випускати версію так часто, як я працюю над нею без особливих зусиль. Однак підтримка Java-документа все ще є тягарем, оскільки вона включає приклади.
У міру розвитку API я повинен вручну перевіряти кожен приклад знову і знову. Чи є кращий спосіб зробити це?
Я розглядав можливість переміщення документації та прикладів в окремий проект (наприклад, Підручник з суппорта ), щоб він міг бути повторно розроблений і складений разом із звичайним кодом. Однак це відсуває документацію від класу, про який йдеться.
Так що так. Я хотів би мати свій торт і їсти його теж. : D
* <h2>Tokenization</h2>
*
* Tokenization cuts up a string into tokens e.g.
* <code>chilperic ii son of childeric ii</code> is tokenized into
* <code>[chilperic, ii, son, of,
* childeric, ii]</code>. Tokenization can also be done repeatedly by tokenizing
* the individual tokens e.g.
* <code>[ch,hi,il,il,lp,pe,er,ri,ic, ii, so,on, of, ch,hi,il,ld,de,er,ri,ic, ii]</code>
* <p>
*
* <pre>
* <code>
* {@code
* return new StringMetricBuilder()
* .with(new SimonWhite<String>())
* .tokenize(new Whitespace())
* .tokenize(new QGram(2))
* .build();
* }
* </code>
* </pre>
*
* <p>Якщо вище, це занадто абстрактно. Це зразок документації. В даний час я додаю статичні конструктори, як радить Ефективна Java, наприклад Tokenizers.createQGram(2), знецінюючи метод конструктора. Кожен раз, коли я роблю щось подібне, мені доведеться оновлювати приклад коду вище та перевіряти, чи він все ще працює.