Ускорение в 40 раз - достаточно большая цифра, это сравнение с начальным состоянием?то есть взяли базу и загрузку с дефолтными настройками и запустили процесс. Подход имеет право на жизнь - эволюционная оптимизация только по мере необходимости против достаточно затратного подхода предусмотреть все заранее для всех сценариев, которые могут и не реализоваться.
Отличное исследование, да, вынуждены иногда копаться . вместо разработки бизнес логики на прикладном языке СУБД копаться в языке C(хотя это больше работа ДБА все таки). Тут уж пора из прикладного разработчика переходить в разработчика СУБД:-)
"...испытывая стыд перед коллегами за то, что совершили такую элементарную оплошность..." как говорится "шит хэппенс". В зрелых командах никто стыд не испытывает и никого не стыдят , а делают выводы на ретро:-)
Есть знакомый, отказался от оффера +30% к доходу на текущем месте, потому что предполагалось, что могут быть ночные звонки, а на текущем месте такого нет .Конечно респект работодателю, что явно осветили это момент при обсуждении условий , но спокойный сон - дорогое удовольствие, премия должна быть больше
Если контора частная, то усложняторы - исключительно головная боль владельцев. Если контора даёт приемлемый положительный денежный поток, то владельцы в детали не углубляются, а играют в гольф. А кого усложняторы не устраивают, основывайте свой бизнес и нанимайте кого хотите :-)
Ну это как бы другая специализация, другой бизнес, производство средств производства. Большая доля программирования в РФ- это прикладное программирование. Не будет же Сбер писать свой компилятор, а Тинькофф свой и и.д.
А я наоборот, всегда совмещаю рефакторинг соответствующего модуля с выполнением бизнес-задач: новая фича всё равно проходит полный цикл тестирования, в том числе ручное и пользовательское, заодно и рефакторинг проверяется. Риск поймать функциональный регресс из за рефакторинга в этом случае ниже.
Ускорение в 40 раз - достаточно большая цифра, это сравнение с начальным состоянием?то есть взяли базу и загрузку с дефолтными настройками и запустили процесс. Подход имеет право на жизнь - эволюционная оптимизация только по мере необходимости против достаточно затратного подхода предусмотреть все заранее для всех сценариев, которые могут и не реализоваться.
Отличное исследование, да, вынуждены иногда копаться . вместо разработки бизнес логики на прикладном языке СУБД копаться в языке C(хотя это больше работа ДБА все таки). Тут уж пора из прикладного разработчика переходить в разработчика СУБД:-)
"...испытывая стыд перед коллегами за то, что совершили такую элементарную оплошность..." как говорится "шит хэппенс". В зрелых командах никто стыд не испытывает и никого не стыдят , а делают выводы на ретро:-)
Есть знакомый, отказался от оффера +30% к доходу на текущем месте, потому что предполагалось, что могут быть ночные звонки, а на текущем месте такого нет .Конечно респект работодателю, что явно осветили это момент при обсуждении условий , но спокойный сон - дорогое удовольствие, премия должна быть больше
Если контора частная, то усложняторы - исключительно головная боль владельцев. Если контора даёт приемлемый положительный денежный поток, то владельцы в детали не углубляются, а играют в гольф. А кого усложняторы не устраивают, основывайте свой бизнес и нанимайте кого хотите :-)
В компенсационный пакет надо ещё добавить it ипотеку :-))). , а есть и такие айтишники
https://auto.ru/mag/article/kitayskiy-programmist-3-goda-nochuyut-v-elektromobile-radi-ekonomii-na-arende/?utm_referrer=https%3A%2F%2Fwww.google.com%2F
Отличные статья и диалог, только пафоса можно чуть убавить:-)
Ну это как бы другая специализация, другой бизнес, производство средств производства. Большая доля программирования в РФ- это прикладное программирование. Не будет же Сбер писать свой компилятор, а Тинькофф свой и и.д.
А компенсирующая транзакция же тоже может сбойнуть, значит на нее надо компенсирующую транзакцию следующего уровня:-)
А я наоборот, всегда совмещаю рефакторинг соответствующего модуля с выполнением бизнес-задач: новая фича всё равно проходит полный цикл тестирования, в том числе ручное и пользовательское, заодно и рефакторинг проверяется. Риск поймать функциональный регресс из за рефакторинга в этом случае ниже.