У нас есть оочень сложные классы (100к loc).

этож сколько там методов то?

один класс на 100к?

Да и не один. Есть легаси система которая жила с 2001 года по принципу append only

если у вас реальный обьект бизнеса зависит от 10 других обьектов - то все стрелятся?!

ну не стрелятся, но с таким тяжко работать

этож сколько там методов то?

phpstorm дохнет

в 2001м году классы не юзались)

А они сначала были набором функции

phpstorm дохнет

а если рефлексией посчитать?

которые потом обернули в class

может стоит начать с удаления мертвого кода?

ооп в действии

которые потом обернули в class

проще было на го переписать, там это ок?

@Enleur как умели и как тогда казалось правильным писали видимо

другое дело в том, что тупо положили на это все последующие 10+ лет

@Enleur как умели и как тогда казалось правильным писали видимо

я ж ниче не говорю, в 2009м году состояниее пхп проектов тоже было не ахти

может стоит начать с удаления мертвого кода?

ммм, хотите я вам еще ужасы расскажу как ненужный код переносят в спец файлы «чтобы не потерялось»

ммм, хотите я вам еще ужасы расскажу как ненужный код переносят в спец файлы «чтобы не потерялось»

ну это проебы разрабов

которые не могут 1) обьяснить манагеру что такое гит 2) воспользоваться гитом 3) воспользоваться жирой

как будто бы я не видел (и не поддерживал что самое печальное) говнокода 8летней выдержки

мы гавнокод 8летней выдержки на живую резали и переводили под 2ю зенду. об этом никто не знал из руководства)

гит с 2005 и то не сразу стал популярен

кстати о JIRA jql может кто нить скинуть, который показывает манагеру - к каким задачам разработчик вчера проставлял время ;)

svn был

ну а в реалиях пхп

ftp only

кстати о JIRA jql может кто нить скинуть, который показывает манагеру - к каким задачам разработчик вчера проставлял время ;)

тоже часики проставляете?)

в 2007 году был svn :)

svn 2000й вроде

а до этого еще cvs был

тоже часики проставляете?)

для себя проставляем, нужно же иметь статистику для оценки задач

еще perforce был

для себя проставляем, нужно же иметь статистику для оценки задач

а, ну у нас почасовая оплата. у нас от этого зависит сколько денег в месяц получишь)

да и ретроспективы неплохо делать, для себя

а как манагеры эту инфу юзают даж хз

а, ну у нас почасовая оплата. у нас от этого зависит сколько денег в месяц получишь)

а какую точность вы используете при указании отработанного времени? как учитываете время на чай/кофе и туалет?

ух помню времена со всякими отчетами

по вечерам где отчет по затраченному времени

каждую неделю за дни

и каждый месяц

и зп считалось от этого, были специальные таски у нас типо

обед

общение с коллегой или консультация коллеги

и время списывали туда

меня миновал timesheet и все его прелести, но знаю ребят которые рисовали 8 часов для получения зп

а какую точность вы используете при указании отработанного времени? как учитываете время на чай/кофе и туалет?

ну где-то 10 минут погрешности допустимо, там кофе сделать или в парашу сходить. а отойти на час пожрать это уже не считается округляется все до 15 минут

я люблю с работой ковыряться даже на выходных, поэтому мне выгодно, т.к сверх нормы постоянно выходит

ну где-то 10 минут погрешности допустимо, там кофе сделать или в парашу сходить. а отойти на час пожрать это уже не считается округляется все до 15 минут

спасибо за ответ

а если привык целый день хуйней на офисе страдать.. то тогда наверное сложно хотя бы 4 часа отработать

на одной работе перед уходом ввели требование записывать каждые 15 минут чем занимался

не, такого маразма нет)

типо весь день разбит на 15 минутки

и надо записать что в каждый из них делал

жесть просто

у нас в принципе доверяют разрабам, и еще не было инцендентов с наебаловом

надо 32 записи сделать

на самом деле это пиздец вместо работы заполняешь нахуй не нужные штуки

я часто в конце дня не могу вспомнить чем занимался и приходится из переписок и истории восстанавливать че я делал)

но это примерно 2-3 задачи, иногда одна задача тянется на пару дней

имхо лучше всего мотивирует работать

это демо в конце спринта

и тут видно кто что за спринт сделал полезного для всех

время занимает минимум а пользы максимум

и все новые фитчи становятся известны сотрудникам

то что в релиз уйдет

по пулреквестам всегда понятно кто в каком темпе работает

Ну такое себе, честно говоря

а демо.. ну хз)

есть люди у кого куча пулл реквестов

но потом сидишь баги правишь

а по демо что? после него багов нет?

причем некоторые чтобы найти надо несколько дней ковырять отладчиком ибо бага сложно воспроизводится

по демо как по мне еще больше багов будет

спринты это вообще пздц

и как тут быть если ты изменил одну строчку

зажимать себя в рамки 1-2 недель спринта

а чтобы найти строчку и причину и фазу луны затратил дохуя времени

зажимать себя в рамки 1-2 недель спринта

а это нормально)

таски не должны быть длиннее 8 часов

сами себе проблему создаете, а потом боритесь со своими же дедлайнами

Если больше - хреново декомпозировали

можно убрать слово спринт

таски не должны быть длиннее 8 часов

одна таска может состоять из двух дюжен

и сделать слово перед релизом

а если релизы постоянные?)

одна таска может состоять из двух дюжен

Значит её нужно распилить

релизы делать по меге готовности тасков

Значит её нужно распилить

ну я за подтаски говорю, уже распилянные

а если релизы постоянные?)

по мере готовности функционала нового или фикса багов

по мере готовности функционала нового или фикса багов

если тестеров много

Значит её нужно распилить

сложность в том что иногда никто не знает как будет выглядеть таска

и самое сложно как раз в этом

любую таску можно распилить

а не в том чтобы налабать код

даже когда требования нихуя непонятные и не доконца известные

ну то такое

хз, мне нравится идея с часами рабочими

сразу скептически относился

любая идея имеет плюсы и минусы

и много зависит от проекта