Ну никогда человек правляющий людьми не будет получать меньше самих этих людей. Это просто глупо.
Программиста найти намного проще чем управленца.
Ну грубо говоря если проджект менеджер может вести пару тройку проектов с кажем с 20 людьми подчиненными он принесет прибыли ну просто в 20 раз больше чем программист, смысл ему платить меньше то ?
Наверно очень глупая ситуация когда начальник получает денег меньше чем его подчиненные.
Очень интересно это где так что у менеджера меньше зп чем у программиста под ним?
планирование там, настройка процессов...
Чем больше проект, как правило, тем меньше ему подходит стандартный фреймворк, он вместо того, чтобы помогать, всё больше мешает.Вообще говоря нет. Недальновидно выбранный фреймворк - мешает.
И тогда начинают что то дописывать, как то хатчить сам фреймворк.
Если у вас большой проект, скажем там 1кк строк бизнес логики, то всё равно основная сложность начинает концентрироваться именно там, а не в самописном фреймворке.
Нет VCS и коммиты не привязаны к тикетам? Команда жаждет адреналина!
Хороший - так же не уберет за собой. Это зануда - уберет, из принципа.
Хорошие разработчики тем и отличаются, что они не часто попадают в экстремальные ситуации.
Главное для нас скорость исполнения кода
чем фреймворки порой не могут похвастаться
просто не хочется делать эту бессмысленную дополнительную работу
вероятность ошибки при ручной работе
Jira же знает какие коммиты вошли в задачу и скорее всего там можно запустить какие-то post-скрипты после смены статуса задачи.
// Рабочий код
class SomeClass
{
public function assertPositive(int $positive): void
{
if ($positive <= 0) {
throw new \InvalidArgumentException('');
}
}
}
// Тест
(new SomeClass())->assertPositive(100);class SomeClass // покрыта
{ // покрыта
public function assertPositive(int $positive): void // покрыта
{ // покрыта
if ($positive <= 0) {
throw new \InvalidArgumentException('');
}
} // покрыта
} // покрыта
Это замечательно. У человека, который будет это делать и выясните.
В этом и проблема. По хорошему вы вообще не должны это представлять и определять.
Ваш вопрос не корректен не потому, что вот вы не знаете (это вполне нормально чего-то не знать). А потому, что вы спрашиваете его не там. Понимаете, я как и участники этого обсуждения (предположительно) не имею ни малейшего представления о том:
1) а что вы за WMS используете? Какие там у вас задачи с ней? В каком состоянии тот проект? Какой технологический стек используется? Кто его сейчас поддерживает и на каком уровне?...
2) те же вопросы, только к сайту
3) вытекает из 2)
4) Чем текущий плох? Есть ТЗ? Какие требования к нагрузкам? Почему именно CMS?...
6) Не хило))
Итого у вас 4,5 проекта, на одного человека. Если планируется вести их параллельно - готовьтесь к большой текучке.
Если подытожить: задайте тот же вопрос человеку, который будет проводить техническое собеседование.