Здравствуйте, Codealot, Вы писали:

I>>Именно. Тебя удивляет, откудв в обязанностях менеджера это самое business value.

C>Нет, меня это не удивляет, и ничего подобного я не писал.
C>Споришь с голосами в твоей голове?

Вот смотри, некто пишет с аккаунта Codealot
http://rsdn.org/forum/job/7702980.1

Автор: Codealot
Дата: 10.04.20

I>>Ты бы внимательнее читал, что-ли? Про диссертацию ничего не было.

C>Чувак, а ты реально заврался.
C>

C>Твоё правилом применим к тебе же — тебя можно записать в идиоты на том основании, что у тебя нет докторской по медицине.

Докторская степень. Что тебя смущает? Я не в курсе, во всех ли странах диссертация обязательна или нет, так что про диссертацию здесь только косвенно. Где ты видишь враньё? Что у тебя с восприятием?

I>>Есть проекты, где не делают. С чего ты взял, что это норма?
C>Смотрю на качество проектов.

Так смотреть надо по всему рынку труда

I>>Нету инструментов должных — рефакторинг или не ведется, или только локально.
C>Какие еще "должные инструменты"? Мозги, что ли? Их нету?

Должные инструменты — автоматические — рефакторинг, анализаторы и тд.

Здравствуйте, Ikemefula, Вы писали:

I>Вот смотри, некто пишет с аккаунта Codealot
I>http://rsdn.org/forum/job/7702980.1

Автор: Codealot
Дата: 10.04.20

Некто пишет с аккаунта Codealot, что в задачи ПМа входит всё, что касается планирования и управления проектом, а не только "задачи, которые имеют business value", как это утверждаешь ты. Второе — подмножество первого.

I>>>Ты бы внимательнее читал, что-ли? Про диссертацию ничего не было.
I>Твоё правилом применим к тебе же — тебя можно записать в идиоты на том основании, что у тебя нет докторской по медицине.
I>Докторская степень. Что тебя смущает? Я не в курсе, во всех ли странах диссертация обязательна или нет, так что про диссертацию здесь только косвенно. Где ты видишь враньё? Что у тебя с восприятием?

Никакой докторской степени без докторской диссертации не бывает и быть не может, равно как и наоборот — наличие успешно защищенной докторской диссертации автоматически означает наличие докторской степени.
Так что заканчивай эту шизофазию и иди к врачу, он тебе явно очень нужен.

I>Так смотреть надо по всему рынку труда

Я так и делаю. Результаты удручают.

I>Должные инструменты — автоматические — рефакторинг, анализаторы и тд.

А без автоматических инструментов, конечно, никак нельзя. Мозгов то совсем нет.

Здравствуйте, Codealot, Вы писали:


C>Некто пишет с аккаунта Codealot, что в задачи ПМа входит всё, что касается планирования и управления проектом, а не только "задачи, которые имеют business value", как это утверждаешь ты. Второе — подмножество первого.

Наоборот, первое есть подмножество второго.

I>>Докторская степень. Что тебя смущает? Я не в курсе, во всех ли странах диссертация обязательна или нет, так что про диссертацию здесь только косвенно. Где ты видишь враньё? Что у тебя с восприятием?

C>Никакой докторской степени без докторской диссертации не бывает и быть не может, равно как и наоборот — наличие успешно защищенной докторской диссертации автоматически означает наличие докторской степени.

У меня есть сомнения, но спорить не буду.

C>Так что заканчивай эту шизофазию и иди к врачу, он тебе явно очень нужен.

Ты снова хамишь

C>Я так и делаю. Результаты удручают.

Ага, прямой доступ к рынку труда

I>>Должные инструменты — автоматические — рефакторинг, анализаторы и тд.

C>А без автоматических инструментов, конечно, никак нельзя. Мозгов то совсем нет.

Можно, если качество не нужно и есть бесконечный запас времени. Например, пару сотен или тысяч фиксов вручную не осилить иначе как с потерей качества или долго-долго нудно-нудно колупать проект. Автоматический анализатор находит это за секунды, а автоматический рефакторинг исправляет это за секунды.

Здравствуйте, Ikemefula, Вы писали:

C>>Некто пишет с аккаунта Codealot, что в задачи ПМа входит всё, что касается планирования и управления проектом, а не только "задачи, которые имеют business value", как это утверждаешь ты. Второе — подмножество первого.
I>Наоборот, первое есть подмножество второго.

Это нешуточное открытие, меньше чем на Нобелевку не соглашайся. Если сумеешь доказать.

C>>Никакой докторской степени без докторской диссертации не бывает и быть не может, равно как и наоборот — наличие успешно защищенной докторской диссертации автоматически означает наличие докторской степени.
I>У меня есть сомнения, но спорить не буду.



I>Ты снова хамишь

Ничего личного, просто факт. И к врачу лучше сходи. Это я тебе говорю как человек с опытом из первых рук

I>Ага, прямой доступ к рынку труда

Что сказать то хотел?

I>Можно, если качество не нужно и есть бесконечный запас времени. Например, пару сотен или тысяч фиксов вручную не осилить иначе как с потерей качества или долго-долго нудно-нудно колупать проект. Автоматический анализатор находит это за секунды, а автоматический рефакторинг исправляет это за секунды.

Ага, волшебно-автоматический анализатор и автоматический рефакторинг. И автоматические программисты с автоматическим ПМом.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Ikemefula, Вы писали:

I>>Менеджер: — Нахрена нам рефакториг, какой тут business value ?
C>То есть, твой гипотетический ПМ не знает, что такое рефакторинг и зачем он нужен. Будешь оспаривать?
Я буду.

Вопрос менеджера — какая польза от рефакторинга в конкретной ситуации. Ты ответить не можешь внятно и начинаешь обвинять менеджера во всех грехах подряд.
Судя по всему, ты сам не знаешь, что такое рефакторинг.

Здравствуйте, _ABC_, Вы писали:

_AB>Я буду.

Я вижу, ты никак не можешь пройти спокойно мимо Кстати, на мой прошлый вопрос ответишь? А то складывается устойчивое впечатление, что ты один из тех, у кого чувство совести отсутствует напрочь. Потому что достойные люди либо подтверждают такие обвинения фактами, либо извиняются, если не могут этого сделать. Наговорить таких гадостей и по тихому свалить в кусты — для достойного человека не вариант.

_AB>Вопрос менеджера — какая польза от рефакторинга в конкретной ситуации. Ты ответить не можешь внятно и начинаешь обвинять менеджера во всех грехах подряд.

Это просто полная чушь, как и у предыдущего "оратора". Польза от рефакторинга в любой ситуации — потратить немного времени сейчас, чтобы не пришлось тратить много времени потом. И менеджер, если хоть немного соображает в своей работе, должен выделять какой-то процент времени на рефакторинг всегда и независимо ни от чего.

В мои же обязанности обучение абсолютно некомпетентных менеджеров никогда не входило, да и в любом случае достучаться до их мозга невозможно по причине его отсутствия. Поэтому, набив некоторое количество шишек, я просто с ними не связываюсь — чего желаю и всем остальным программистам. Кроме любителей мазохизма в особо извращенной форме — для них будет в самый раз.

Здравствуйте, Codealot, Вы писали:

C>Я вижу, ты никак не можешь пройти спокойно мимо
Могу. Когда хочу. Впрочем, каждый сам по себе судит...

C>Кстати, на мой прошлый вопрос ответишь?
На какой?

C>А то складывается устойчивое впечатление, что ты один из тех, у кого чувство совести отсутствует напрочь.
Везде своих ищешь, да найти не можешь? Приходится облыжно ярлыки вешать? Понимаю, хотя не одобряю...

C>Это просто полная чушь, как и у предыдущего "оратора".
Ну-ну, конечно...

C>Польза от рефакторинга в любой ситуации — потратить немного времени сейчас, чтобы не пришлось тратить много времени потом.
Сразу пять вопросов от менеджера.
1. Сколько это "немного времени сейчас"? В часах, пожалуйста.
2. Можем ли мы позволить себе это "немного времени" потратить именно сейчас?
3. Сколько конкретно "много времени" потом составляет в часах?
4. Когда конкретно это "потом" настанет?
5. Почему рефакторинг кода нужно выделять как отдельную задачу?

C>И менеджер, если хоть немного соображает в своей работе, должен выделять какой-то процент времени на рефакторинг всегда и независимо ни от чего.
Вот это "независимо ни от чего" есть такая феерическая чушь, что просто уши в трубочку сворачиваются...
А если проект — всего лишь PoC без перспектив доработки в рамках проекта? Тоже время на рефакторинг выделять?
А если проект логически достаточно легкий, структура кода ясная, разрабатывают её крепкие профессионалы и проблем ни с поддержкой, ни с внедрением нового функционала нет, а сроки сжатые и времени свободного нет. Тоже время на рефакторинг выделять?

ИМХО, это программисты должны в оценки свои закладывать необходимость рефакторинга в рамках решения своих задач, а не менеджер сверху нормативы спускать. И если уж промахнулись настолько, что рефакторинг должен выделятся в результате разговора с менеджером в отдельную задачу, то будь добр обоснуй это чем-то вменяемым.

C>В мои же обязанности обучение абсолютно некомпетентных менеджеров никогда не входило
Судя по всему, в твои обязанности вообще никогда не входило ничего за пределами кодинга. Причем по жестко определенным извне спецификациям.

C>да и в любом случае достучаться до их мозга невозможно по причине его отсутствия.
Знакомая позиция безответственного человека. Раз не можешь что-то объяснить, значит дело не в твоём неумении объяснять, а в отсутствии мозга у вышестоящих лиц. Да-да, конечно. Один ты д`Артаньян, стоишь в белом пальто красивый.

C>Поэтому, набив некоторое количество шишек, я просто с ними не связываюсь
Другими словами — сидишь рядовым кодером, т.к. неспособен посмотреть на проект глазами других участников и отстоять свою точку зрения с учетом интересов проекта в целом.

Здравствуйте, Codealot, Вы писали:

C>>>Некто пишет с аккаунта Codealot, что в задачи ПМа входит всё, что касается планирования и управления проектом, а не только "задачи, которые имеют business value", как это утверждаешь ты. Второе — подмножество первого.
I>>Наоборот, первое есть подмножество второго.

C>Это нешуточное открытие, меньше чем на Нобелевку не соглашайся. Если сумеешь доказать.

Открой уже гугл да узнай, что же делает проектный менеджер. Разница с работой разработчика только в том, что менеджер не буквально прибавляет business value, а умножает его. Например, может избавить девелопера от менее важной работы и загрузить его более важной. Следовательно business value растет — эффективность девелопера вырастает. За рост отвечает менеджер, но обеспечивает его девелопер.

Отсюда ясно, что менеджер планирует он не абы что, а работы, активности которые прибавляют business value.
Организует и мотивируют работу не абы какой команды, а именно той, которая непосредственно работает над business value
Трекает время, бюджет не просто так, а именно конкретного проекта, цель — business value. Раздутым бюджетом и сроками можно убить любое business value. Работает с ожиданиями заказчика — напрямую business value, нужно внятно понимать что же нужно заказчику, сегодня или завтра, всё или частями, быстро или качественно, сперва то или это. Риски — снова business value, своего рода защита вложений. Мониторинг прогреса — снова business value. Репорты — опять оно же. И везде это увеличение, умножение business value.

C>>>Никакой докторской степени без докторской диссертации не бывает и быть не может, равно как и наоборот — наличие успешно защищенной докторской диссертации автоматически означает наличие докторской степени.
I>>У меня есть сомнения, но спорить не буду.

I>>Ты снова хамишь
C>Ничего личного, просто факт. И к врачу лучше сходи. Это я тебе говорю как человек с опытом из первых рук

Снова хамство.

I>>Ага, прямой доступ к рынку труда

C>Что сказать то хотел?

Есть сомнения в том, что у тебя есть адекватные сведения о рынке труда. Это следует из твоего "понимания" рефакторинга, знания обязанностей проектного менеджера, путанице с проектными и функциональными менеджерами, и тд и тд.

I>>Можно, если качество не нужно и есть бесконечный запас времени. Например, пару сотен или тысяч фиксов вручную не осилить иначе как с потерей качества или долго-долго нудно-нудно колупать проект. Автоматический анализатор находит это за секунды, а автоматический рефакторинг исправляет это за секунды.

C>Ага, волшебно-автоматический анализатор и автоматический рефакторинг. И автоматические программисты с автоматическим ПМом.

По твоему Find References или Find Usages это магия? Ну и дела Я тебе страшное скажу — это работает тот самый автоматический анализатор. Когда ты делаешь, скажем, инлайн метода, автоматический рефакторинг выполнит корректные подстановки в каждом случае.
Эквивалентные приседания вручную занимают на несколько порядков больше времени.

Здравствуйте, Codealot, Вы писали:

C>Польза от рефакторинга в любой ситуации — потратить немного времени сейчас, чтобы не пришлось тратить много времени потом. И менеджер, если хоть немного соображает в своей работе, должен выделять какой-то процент времени на рефакторинг всегда и независимо ни от чего.

Итого, здесь ты написал, что рефакторинг у тебя есть улучшайзер, а менеджер снова "должен"

Рефакторинг это изменение структуры решения при гарантиях сохранения наблюдаемого поведения. Например, переименовываешь метод X в Y — рефакторинг. Обратное преобразование — снова рефакторинг. И так ты можешь заниматься целый день или даже месяц, вернуться к тому же X и всё равно это будет рефакторинг
business value это не свойство рефакторинга, как ты думаешь, а цель, ради которой он проводится. Применять как локально, так и глобально, как точечно, так и непрерывно. Точечный рефакторинг хорош, но глобального эффекта не даёт. Глобальный рефакторинг тоже хорош, но без непрерывного локального рефакторинга его просто не втащить — слишком много изменений.
Например, есть задача — пофиксить баг. Здесь не надо думать про сейчас и потом, баланс и гармонию, инь и янь. У бага есть причины и есть конкретное место, где ошибка. Исправлять, как правило, нужно и то, и то. Если исправляется только сама ошибка, без воздействия на её причины, количество багов в среднем увеличивается.

А вот выделять рефакторинг в отдельную фазу проекта мягко говоря смысла не имеет, т.к. это превращается в судорожный улучшайзинг(в лучшем случае), а бОльшую часть времени люди будут работать с устаревшей структурой кода. Да и заказчик не склонен ждать даже несколько недель пока закаончится эта фаза.
Чем больше масштаб рефакторинга, тем больше пересекающихся изменений, тем труднее планировать. Соответственно, глобальный рефакторинг никогда не наступает, и проект ожидаемо тонет в дерьме.

Здравствуйте, _ABC_, Вы писали:

_AB>На какой?

Тот, который ты притворился что не заметил. Ты считаешь, что разбираешься в вопросах неврологии лучше врачей-специалистов?
Ну так что, ты в состоянии ответить за свои слова?

_AB>Везде своих ищешь, да найти не можешь?

Искать не надо — сами отовсюду появляются. Но нарциссы мне точно не свои.

_AB>Сразу пять вопросов от менеджера.
_AB>1. Сколько это "немного времени сейчас"? В часах, пожалуйста.
_AB>2. Можем ли мы позволить себе это "немного времени" потратить именно сейчас?
_AB>3. Сколько конкретно "много времени" потом составляет в часах?
_AB>4. Когда конкретно это "потом" настанет?

Все вопросы, которые касаются планирования проекта в целом — это компетенция менеджера или архитектора. В компетенцию программистов от тим лида и ниже они не входят, включительно.

_AB>5. Почему рефакторинг кода нужно выделять как отдельную задачу?

Потому что рефакторинг — это отдельная и независимая задача.

_AB>Вот это "независимо ни от чего" есть такая феерическая чушь, что просто уши в трубочку сворачиваются...
_AB>А если проект — всего лишь PoC без перспектив доработки в рамках проекта? Тоже время на рефакторинг выделять?
_AB>А если проект логически достаточно легкий, структура кода ясная, разрабатывают её крепкие профессионалы и проблем ни с поддержкой, ни с внедрением нового функционала нет, а сроки сжатые и времени свободного нет. Тоже время на рефакторинг выделять?

Если отведенное на рефакторинг время не понадобилось, то его можно без малейших проблем использовать для других задач. Но обычно оно все-таки нужно. И когда девелоперы бьют себя пяткой в грудь, что сделают все идеально с первого раза — в особенности

_AB>ИМХО, это программисты должны в оценки свои закладывать необходимость рефакторинга в рамках решения своих задач, а не менеджер сверху нормативы спускать.

Когда менеджер идиот и не знает смысл слова "рефакторинг" — тогда это по сути единственный вариант.

_AB>Судя по всему, в твои обязанности вообще никогда не входило ничего за пределами кодинга. Причем по жестко определенным извне спецификациям.

Мимо.

_AB>Знакомая позиция безответственного человека. Раз не можешь что-то объяснить, значит дело не в твоём неумении объяснять, а в отсутствии мозга у вышестоящих лиц. Да-да, конечно. Один ты д`Артаньян, стоишь в белом пальто красивый.

Ну раз так — возьмешься научить слабоумных писать качественный код на C++? Ты ведь отлично умеешь объяснять, если верить твоим заявлениям.

_AB>Другими словами — сидишь рядовым кодером, т.к. неспособен посмотреть на проект глазами других участников и отстоять свою точку зрения с учетом интересов проекта в целом.

Мимо.

Здравствуйте, Codealot, Вы писали:

C>В мои же обязанности обучение абсолютно некомпетентных менеджеров никогда не входило, да и в любом случае достучаться до их мозга невозможно по причине его отсутствия. Поэтому, набив некоторое количество шишек, я просто с ними не связываюсь — чего желаю и всем остальным программистам. Кроме любителей мазохизма в особо извращенной форме — для них будет в самый раз.

Коллега, у вас всё очень и очень плохо с пониманием устройства настоящей компании. Это нормально для джуна, который готовится стать миддлом — но уже более-менее компетентный разработчик, не говоря уже о тим-лидерских или архитекторских позициях, обязан понимать немножко больше, чем набор слов из технического жаргона.

Например, понимать, как устроен окружающий бизнес — ну, хотя бы на уровне того, какие отделы есть в компании. Что они делают и зачем. У кого какая ответственность.

Есть такое эмпирическое правило: чем больше сотрудник считает другие службы идиотами, тем менее важную роль в компании он играет. Ну, классика жанра — бухгалтерия считает дебилами экспедиторов, потому что те не могут правильно накладную подписать даже после десяти объяснений и создают проблемы на ровном месте. Сисадмины считают дебилами бухгалтерию, потому что "ну у меня это красное окошко всегда вылезает, я просто его закрываю и всё". Уборщица считает дебилами сисадминов, потому что они никак не могут научиться не ходить по помытому и вечно оставляют обрезки проводов по углам, откуда их шваброй не вытащишь.
Ну, а охрана считает дебилами и дармоедами вообще всех в здании.

Аллегория понятна?
Переходим к основам управления производством: менеджер принимает управленческие решения. Более-менее любой. Хороший менеджер принимает решения, которые увеличивают stakeholder value. Это его обязанность.
Если менеджер принимает решения, которые ухудшают stakeholder value, то рано или поздно от него избавятся (а если он достаточно высокопоставлен, то компания утонет).
Техническая квалификация у него идёт факультативно, а иногда и вредит.

Только очень наивный кодер может ожидать от менеджера глубокой технической экспертизы. Хорошая новость для вас: вы в своих заблуждениях не одиноки. Таких людей — очень много. Вторая хорошая новость — да, плохих менеджеров примерно столько же, сколько плохих кодеров.
Но это не означает, что менеджер обязан разбираться в технических подробностях. Его задача — назначить людей, которые разбираются в технических подробностях, и обозначить фронт работ.

Кодер может сколько угодно считать, что уж он-то лучше всех знает, куда надо вкладывать усилия в проекте — на практике это встречается ещё реже, чем технически грамотный менеджер. У менеджера может быть сотня причин откладывать рефакторинг, или выбрать не лучшую СУБД, или не лучший язык программирования, или принять ещё какое-то странное для кодера решение.

Нужно всегда помнить, что, в отличие от кодера, менеджер (особенно компетентный) знает массу забавных и интересных фактов. Например, что крупному заказчику уже была обещана дата запуска новой версии; у них выделены ресурсы на тренировку людей, запланировано приёмочное тестирование, оборудование заказано к конкретным датам. Срыв сроков в данном конкретном случае чреват таким ущербом, что сожрёт всю прибыль трёх кварталов.

Конечно, хорошо, когда кодер это тоже знает. Но — не обязан. К счастью для него, есть менеджер, который балансирует приоритеты. Если кодер сам не знает, какова ценность данного конкретного рефакторинга для компании, то ему стоит обратиться к сениору, способному это оценить и перевести его невнятное блеяние на понятный человеческий язык, типа "мы ускорим время на разработку новых фич вдвое, а потратить планируем пару недель".
Это если сениор или тим лид не способен грамотно размазать рефакторинг по циклу разработки так, чтобы в отчётах не торчали 600 часов усилий с нулевым выхлопом. А то и отрицательным — "теперь нам надо прогнать 400-часовой цикл ручной регрессии, чтобы убедиться, что наш рефакторинг ничего не сломал".

Нормальный менеджер игнорирует все эти жаргонизмы на митингах и обращает внимание только на наблюдаемые вещи: "на что это повлияет? Сроки релиза? Функциональность? Безопасность?".
Слишком много технических знаний менеджеру мешают: он рискует отвлечься от планирования приоритетов и зависимостей, и погрязнуть в подробностях типа "а в логи в это пишете? А корреляции смотрели? Ну хорошо, а не пробовали в финализаторе это отловить? Ну ок, давайте CLR триггер в базе повесим — он-то уж точно будет вызываться". К тому же, он может ненароком навязать неудачное решение подчинённым, думая, что он прав. А на самом деле это кодеры должны быть технически грамотными, и выбирать наилучшие решения. Роль менеджера — это приоритеты и зависимости.

Техническая грамотность от менеджера нужен только в патологических случаях — например, чтобы увидеть откровенный саботаж. Ну там — после поглощения какой-то компании вам досталась команда с продуктом. И вот почему-то у них всё плохо с качеством и продуктивностью, и непонятно, то ли это унаследованная codebase в плохом состоянии, то ли люди работают плохо.
Даже в такой ситуации полезнее притащить в эту команду technical fellow, который сможет просто посмотреть из-за плеча, изучить код и прочие технические артефакты, и сделать экспертную оценку на понятном менеджеру языке.
Опять же — потому, что менеджер должен подходить к вопросам хладнокровно и беспристрастно: продукт убыточен — закрыть нахрен. Люди некомпетентны — распределить среди персонала компании, по результатам адаптации дебилов и саботажников уволить, толковых оставить и повысить. Технический долг мешает — добавить ресурсов из других отделов, привести всё в порядок. Это всё вещи, которые лучше решать, не имея личных предпочтений, типа "да мы с этим говном десять лет конкурировали — щас я его спишу в утиль" или "я так и знал — на delphi ничего толкового не напишешь".

Здравствуйте, Ikemefula, Вы писали:

I>А вот выделять рефакторинг в отдельную фазу проекта мягко говоря смысла не имеет, т.к. это превращается в судорожный улучшайзинг(в лучшем случае), а бОльшую часть времени люди будут работать с устаревшей структурой кода. Да и заказчик не склонен ждать даже несколько недель пока закаончится эта фаза.

Если твой рефакторинг занимает недели и никак не меньше, то ты делаешь все катастрофически неправильно.

Здравствуйте, Ikemefula, Вы писали:

I>Открой уже гугл да узнай, что же делает проектный менеджер.

1. Activity and resource planning
2. Organizing and motivating a project team
3. Controlling time management
4. Cost estimating and developing the budget
5. Ensuring customer satisfaction
6. Analyzing and managing project risk
7. Monitoring progress
8. Managing reports and necessary documentation

Вообще ни слова про business value, которым ты мне уже все уши прожужжал. По моему, тебе самому надо срочно открыть гугл и наконец узнать, что же он делает.
Кстати, ты там наконец разобрался, что является подмножеством чего?

I>Снова хамство.

Просто факт. Когда человек не помнит, что сам же писал несколько сообщений назад — это серьезная проблема, с которой надо идти к врачу.

I>Есть сомнения в том, что у тебя есть адекватные сведения о рынке труда. Это следует из твоего "понимания" рефакторинга, знания обязанностей проектного менеджера, путанице с проектными и функциональными менеджерами, и тд и тд.

Есть сомнения, что твое мнение по этим вопросам имеет какое-либо значение.

I>По твоему Find References или Find Usages это магия? Ну и дела Я тебе страшное скажу — это работает тот самый автоматический анализатор. Когда ты делаешь, скажем, инлайн метода, автоматический рефакторинг выполнит корректные подстановки в каждом случае.
I>Эквивалентные приседания вручную занимают на несколько порядков больше времени.

С каких это пор инлайн метода стал считаться относящимся к рефакторингу? Обычно делают ровно наоборот — выделяют код в отдельный метод.

Здравствуйте, Sinclair, Вы писали:

S>Аллегория понятна?

Аллегории мне неинтересны, поэтому я просто перейду к конкретике.

S>Только очень наивный кодер может ожидать от менеджера глубокой технической экспертизы.

Ничего подобного я и не писал. Речь шла о базовом понимании того, что происходит в коде. А вас, гражданин, поздравляю соврамши.

S>Но это не означает, что менеджер обязан разбираться в технических подробностях. Его задача — назначить людей, которые разбираются в технических подробностях, и обозначить фронт работ.

И очень важное следствие, которое вытекает из этого пункта. В дальнейшем, его задача — не лезть в принятые ими технические решения. Потому что они разбираются в этих вопросах лучше.

S>У менеджера может быть сотня причин откладывать рефакторинг, или выбрать не лучшую СУБД, или не лучший язык программирования, или принять ещё какое-то странное для кодера решение.

То есть твой менеджер сначала заявляет, что технические вопросы — не его барское дело. А потом заявляет, что в технических вопросах он разбирается лучше всех, и их мнение ему побоку. А когда сроки будут гореть, то виноваты естественно программисты, и теперь им по рангу положено вкалывать круглосуточно и забесплатно, чтобы исправить свою вину.

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

Здравствуйте, Codealot, Вы писали:

C>Ничего подобного я и не писал. Речь шла о базовом понимании того, что происходит в коде.
Что это за зверь "базовое понимание"? Что именно должен понимать менеджер, чтобы успешно управлять проектом?
Ну, вот я к примеру, знаю определение термина "рефакторинг". Кстати, ваше понимание, судя по комментам в других ветках, от него отличается.
Это не означает, что я просто буду разрешать разработчикам списывать произвольные объёмы работ на слово "рефакторинг", потому что "я обязан понимать ценность рефакторинга самостоятельно".
Нет уж, это разработчик обязан быть готов мне рассказать, что за рефакторинг он хочет провести, почему именно сейчас, и для чего нам это полезно.
Должна быть простая и понятная логическая цепочка — например, мы хотим избавиться от завязанности на библиотеку X, потому что у неё перестали выходить новые версии.
Сама замена библиотеки — дело тяжкое, в этот релиз может не влезть. Но мы можем потратить немножко времени в этом релизе для того, чтобы выделить взаимодействие с этой библиотекой в отдельный компонент, что позволит нам легко её заменить в следующем релизе.

C>И очень важное следствие, которое вытекает из этого пункта. В дальнейшем, его задача — не лезть в принятые ими технические решения. Потому что они разбираются в этих вопросах лучше.
Конечно же он будет лезть в принятые технические решения. Потому что он должен оценивать последствия этих решений не только для кодинга, но и много для чего ещё. Например, для мейнтенанса, для саппорта, для внедрения.
Какой-нибудь банальный переезд с .Net FW на .Net Core — стоит ли его делать? Джуны в столовой могут глотки сорвать, споря про "за" и "против".
Увы — только менеджер в курсе, обрадуются ли клиенты возможности переехать с винды на линукс или нет.
И запросто может оказаться так, что "техническое" решение, которое было супер-актуальным вчера, сегодня внезапно уже не нужно и даже вредно. Например, потому что проспект, который собирался заплатить $7500000 инсталляцию и кровь из носу требовал всё только на линуксе, вдруг поговорил со своим CIO и тот ему сказал, что поднять одну машинку с виндой — дело плёвое, тем более это можно сделать в Azure. И они лучше так и сделают, потому что это означает лонч в мае, а не "потом когда мы выпустим новую версию".

C>То есть твой менеджер сначала заявляет, что технические вопросы — не его барское дело. А потом заявляет, что в технических вопросах он разбирается лучше всех, и их мнение ему побоку. А когда сроки будут гореть, то виноваты естественно программисты, и теперь им по рангу положено вкалывать круглосуточно и забесплатно, чтобы исправить свою вину.
Нет. Мой менеджер заявляет, что у всех технических вопросах есть бизнес-последствия, и именно они определяют принимаемые решения. А то, секси ли там какая-то новая технология, и нравится ли унаследованный код разработчику или нет, на решения влиять не должно. И менеджер уже достаточно стар и опытен, чтобы знать, что как раз кажущиеся очевидными вещи чаще всего и оказываются неправильными.

Девелопера может оскорблять то, как реализована в приложении выгрузка .csv — он-то знает способ лучше!
А вот менеджер может увидеть, что реализация — good enough, и не надо там ничего оптимизировать. Клиентов устраивает 30 секунд ждать файл вместо трёх.
Зато вот добавить в начало .csv строчку с "sep=," — это отличная фича, потому что теперь эти CSV будут корректно открываться экселем в Испании и России. Мы на это выделим часы, и даже упомянем это в релиз нотах и в презентации для channel, потому что интернационализация прекрасно согласуется с целями компании, заданными на 2020 год.

C>Твое дальнейшее словесное извержение просто скипаю по причине его бессмысленности.
Ну, как известно, понимание передать невозможно — только информацию. Осознать, как на самом деле обстоят дела, вам придётся самостоятельно. Ещё одна хорошая новость — это возможно.
Лет пятнадцать тому назад я примерно так же относился к менеджерам. К счастью, опыт помогает развиваться. Один из самых замечательных менеджеров, которых я встречал за мою карьеру, имел гуманитарное образование (юрист) и код не мог читать даже со словарём.
При этом техническое образование и глубокое знание кода никак не мешало одному из моих бывших коллег быть просто хреновейшим менеджером, после ухода которого все вздохнули с облегчением.

Здравствуйте, Codealot, Вы писали:

C>Тот, который ты притворился что не заметил.
Опять пытаешься за других отвечать?

C>Ты считаешь, что разбираешься в вопросах неврологии лучше врачей-специалистов?
Нет, я считаю, что лучше тебя разбираюсь в вопросах интервью и связанных с ними законов, в том числе и касающихся инвалидов. Впрочем, я доказал это в прошлый раз прямыми цитатами, на которые тебе не удалось ничем существенным возразить, насколько я помню.

А еще я знаю, что "врачи-специалисты" бывает за деньги выдают инвалидность всяким проходимцам. Я уж молчу о "враче-специалисте", который в прошлом месяце поставил моему брату двоюродному диагноз тонзиллит, при том, что ему гланды удалили два месяца назад.

И молчу о том, что всякие кодалоты в интернете на словах инвалиды со справками, а по факту — сами себе понаставили диагнозов по интернету.

C>Ну так что, ты в состоянии ответить за свои слова?
В отличие от тебя — да.

C>Все вопросы, которые касаются планирования проекта в целом — это компетенция менеджера или архитектора. В компетенцию программистов от тим лида и ниже они не входят, включительно.
C>Потому что рефакторинг — это отдельная и независимая задача.


_AB>>Судя по всему, в твои обязанности вообще никогда не входило ничего за пределами кодинга. Причем по жестко определенным извне спецификациям.
C>Мимо.
Да нет. Точно в цель.

C>Ну раз так — возьмешься научить слабоумных писать качественный код на C++?
Объяснить, почему в данных условиях необходим рефакторинг, если он необходим — возьмусь. И брался. Даже брался объяснять, почему необходимо следующую версию писать с нуля, несмотря на полнейшее нежелание владельца бизнеса это делать. И владелец бизнеса до сих пор иногда мне спасибо говорит за то, что настоял на своем и объяснил что к чему.

Научить писать на С++ — не возьмусь. Банально потому, что С++ — не моя область совершенно.

C>Мимо.
Точно в цель. Только у таких все менеджеры идиоты, одни кодеры умные, только объяснить ничего не могут и отвечать ни за что не хотят, в том числе даже давать оценку потребного времени на решение своих задач.

Здравствуйте, Codealot, Вы писали:

I>>А вот выделять рефакторинг в отдельную фазу проекта мягко говоря смысла не имеет, т.к. это превращается в судорожный улучшайзинг(в лучшем случае), а бОльшую часть времени люди будут работать с устаревшей структурой кода. Да и заказчик не склонен ждать даже несколько недель пока закаончится эта фаза.

C>Если твой рефакторинг занимает недели и никак не меньше, то ты делаешь все катастрофически неправильно.

Важно не "время на рефакториг", а
1 издержки на конкретное изменение, в т.ч. временные
2 издержки на выпуск версии, в т.ч. временные
3 задержки, пока начнется работа над конкретными фичами, фиксами, версией и тд
4 какие будут гарантии качества
итд

Одна из целей разработки это сделать 1, 2 и 3 как можно ниже, а 3 — как можно выше.
Рефакторинг может служить всего лишь одим из инструментов в решении этой задачи. А вот сколько времени — неважно, главное, что бы рефакторинг не останавливал проект, не замедлял его, не являлся препятствием для фиксов, фич и тд.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, Ikemefula, Вы писали:

I>>Открой уже гугл да узнай, что же делает проектный менеджер.
C>

C>1. Activity and resource planning
C>2. Organizing and motivating a project team
C>3. Controlling time management
C>4. Cost estimating and developing the budget
C>5. Ensuring customer satisfaction
C>6. Analyzing and managing project risk
C>7. Monitoring progress
C>8. Managing reports and necessary documentation

C>Вообще ни слова про business value, которым ты мне уже все уши прожужжал. По моему, тебе самому надо срочно открыть гугл и наконец узнать, что же он делает.

Я же тебе примерно это и расписал. Не любые активности планируются, а только относящиеся к конкретному проекту конкретного заказчика. Соответственно, у разработчиков эффективность растёт и business value становится больше. Эффект ясен? Ровно так же и с остальными твоими пунктами.
И цель планирование — это увеличение этого business value, а не абы какая, как тебе кажется.

I>>Снова хамство.
C>Просто факт. Когда человек не помнит, что сам же писал несколько сообщений назад — это серьезная проблема, с которой надо идти к врачу.

Похоже, хамство это один из основных твоих аргументов

I>>Эквивалентные приседания вручную занимают на несколько порядков больше времени.

C>С каких это пор инлайн метода стал считаться относящимся к рефакторингу? Обычно делают ровно наоборот — выделяют код в отдельный метод.

А ты читал вообще того, кто ввёл этот термин? https://refactoring.com/catalog/inlineFunction.html
У каждого рефакторинга есть его инверсия, и это тоже рефакторинг. Пользу дает цель, а не абы какие преобразования в произвольном порядке.
Простой пример — применил ты любой рефакторинг, скажем, без изменения тестов. Тесты зелёные. Пишешь в гите git reset --hard
Что произошло ? Откат сделаных изменений.
Рефакторинг? Абсолютно, т.к. тесты — зелёные.

Здравствуйте, Sinclair, Вы писали:

S>Ну, как известно, [i]понимание/i] передать невозможно — только информацию. Осознать, как на самом деле обстоят дела, вам придётся самостоятельно. Ещё одна хорошая новость — это возможно.
S>Лет пятнадцать тому назад я примерно так же относился к менеджерам. К счастью, опыт помогает развиваться. Один из самых замечательных менеджеров, которых я встречал за мою карьеру, имел гуманитарное образование (юрист) и код не мог читать даже со словарём.
S>При этом техническое образование и глубокое знание кода никак не мешало одному из моих бывших коллег быть просто хреновейшим менеджером, после ухода которого все вздохнули с облегчением.

Humanitarian (comparative more humanitarian, superlative most humanitarian): Concerned with people's welfare, and the alleviation of suffering; humane or compassionate. https://en.wiktionary.org/wiki/humanitarian

Может быть в этом причина? Т.е. юрист кроме всего прочего знал какой-то, предположим, известный гуманитариям способ избавления окружающих от страданий?

Здравствуйте, Ikemefula, Вы писали:

I>Я же тебе примерно это и расписал. Не любые активности планируются, а только относящиеся к конкретному проекту конкретного заказчика. Соответственно, у разработчиков эффективность растёт и business value становится больше. Эффект ясен? Ровно так же и с остальными твоими пунктами.

То есть рефакторинг вообще никак не планируется менеджером и он про него ничего не знает, ты хочешь сказать?

I>Похоже, хамство это один из основных твоих аргументов

Не больше, чем твой и многих других здесь. Даже намного меньше, на самом деле.