R&D срач

[metaclass]

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

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

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

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

PS: Вот еще на тему - периодически в таких обсуждениях предлагают "положить х-ръ, требовать 100 баксов в час и вообще сесть клиентам на голову и свесить ножки". В этом есть некая проблема, как минимум у меня. Ключевой аспект безумной производительности труда - внутренняя мотивация, которая позволяет делать всю эту дурь не выходя из ритма. Если же начинать думать категориями "мне не доплачивают, я слишком много ебошу, нужно работать 40 часов" - мозг резко выключается и не желает работать даже положенных 40 часов, получая моральное разрешение пинать балду.

Comments

[norguhtar.livejournal.com]

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

Здравствуй Java EE! Правда эти игрища до 5-6 версии мягко говоря бульдозер. В 5-6 лучше, но до spring по внятности и простоте недотягивают. Но Spring это отдельная тема которая офигенно ест мозг и часто производит ощущение ебанной магии. Вроде понятно как что там работает, но ощущение магии не пропадает.

[metaclass.livejournal.com]

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

[alexott.livejournal.com]

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

[metaclass.livejournal.com]

Я бы так и делал. Но похоже, тут основной selling point - производительность, и на нее делается основной упор. А ресурсов одновременно пилить две ветки - правильную и производительную, похоже нет.

[alexott.livejournal.com]

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

[jdevelop.livejournal.com]

Java EE тут особо не причем. Это вроде называется системный анализ, или как-то так. В университетах учат даже.

Спринг, при всей своей маркетоидной красоте, тоже не причем в общем )

[metaclass.livejournal.com]

Ага, системный анализ. Я его даже изучал в универе.

[norguhtar.livejournal.com]

Я про модульность, а не про проектирование и анализ :)

[jdevelop.livejournal.com]

ну ладно, тогда интересно почему именно JEE

[norguhtar.livejournal.com]

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

[jdevelop.livejournal.com]

все равно не понимаю

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

конфигурация - это конфигурация собственно приложения

как конфигурация приложения отражается на его модульности?

[norguhtar.livejournal.com]

j2ee предлагает определенные методики для достижения этой модульности, но там пачка вещей автоматически не конфигурируется в этой модульности и приходится писать кучу xml и кода для достижения этого. В случае spring xml надо писать в разы меньше, а кода для конфигурации еще меньше.
Вон товарищ metaclass про тоже пишет ниже.

[metaclass.livejournal.com]

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

[norguhtar.livejournal.com]

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