Кстати, я стараюсь весь код выносить в модули и после изменения, запускаю build_project.bat perl Build.PL perl Build perl Build test perl Build manifest perl Build dist perl Build install
и так как у меня t выглядит: 00.load.t perlcritic.t pod-coverage.t pod.t то он проверяет и на critic и на pod так что хочешь не хочешь, а приходиться добавлять в модуль хотя бы =item * C<< gen_cnt( $key, \%hash_rez, \@$date_arr ) >> Generate rows record for jira =back хоть и мало (так как лень и не времени), но хоть что-то, за то потом можно хоть как-то разобраться в коде, который написан 1 год назад (и исправить его, если нужно) 17.11.2011, 01:40, "Yury Pats" <[email protected]>: > On Thu, Nov 17, 2011 at 00:36, Andrei <[email protected]> wrote: > >> 16 ноября 2011 г. 22:32 пользователь Yury Pats <[email protected]> написал: >>>>>>>> В больших командах лучше наоборот. >>>>>>> В больших командах есть документ code style и процесс code review, >>>>>>> что >>>>>>> гораздо эффективнее. >>>>>> Нету ни того, ни другого. >>>>> Вообще большие команды перл разработчиков это миф. >>>> У нас человек 50 будет. >>> Это не одна команда, а несколько разделенных. >> А code base один. При этом ни code review, ни code style. > > Че, PCritic есть? > >> -- >> Andrei Protasovitski >> < andrei[dot]protasovitski[at]gmail[dot]com > >> Diemen, Netherlands >> >> -- >> Moscow.pm mailing list >> [email protected] | http://moscow.pm.org > -- > WBR, Yury Pats > skype: yuripats > cellular: +375 (29) 5870723 > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org -- Nikolay Mishin -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
