16 мая 2014 г., 0:05 пользователь Ivan Petrov <[email protected]> написал: >> Так у anyevent то же автор.. > > тоТ же угу, typo
> тесты надо писать до кода, а не после :) +1, до, или во время, но главное не после. код без тестов - это фактически половина не сделана. ценность даже мелких cpan модулей, делающих что-то элементарное - в том что у них есть тесты. модуль при желании можно форкнуть, модифицировать и он продолжит работать. так же можно удедиться что он будет работать в бущуем с другими версиями perl. плюс конечно же, меньше багов. а с таким подходом - я написал код, через N лет писать тесты (+ возможно это будет другой человек), то получатся или "интеграционные тесты перед рефакторингом legacy кода" или будет не слабый рефакторинг модуля. а вот докция на модули - действительно проблема. есть у меня код. вроде полезный, тестами покрыт. даже используется в реальной программе (вернее как раз там и используется), без технического долга. но выделить в модуль, объяснить юзерам зачем именно он нужен, почему используется этот подход - уже сложно. и в итоге займёт нишу узкоспециализированных модулей, никакой популярности, маскимум если будут баги, то всплывут молчаливые юзеры с просьбой пофиксить. On 13.05.2014, at 1:55, Тимур Нозадзе <[email protected]> wrote: > Если у кого-нибудь есть идеи на эту тему, с удовольствием выслушаю и включу в > доклад. Есть идея - не забыть что можно делать не только модули (т.е. для других программистов), но и приложения (т.е. для конечных юзеров). Больше приложений на perl - больше юзеров и админов будут знакомы с его деплоем, меньше шансов что линукс дистры выкинут perl из базового комплекта (и будут больше уделять времени бэкпортам багфиксов perl модулей в дистре. Есть у меня одна программа, в её названии даже есть слово Perl (напр. "Perl some application"). Уже два раза заметил что юзеры называют его ""Perl some application" python script" ;) -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
