Дело в том, что заказчики, как правило, НЕ являются аналитиками.
А программисты склонны принимать их "требования" в качестве ТЗ.
А все потому, что вначале нужно научиться понимать других людей, а уже потом — программировать или требования писать...
"Скучные" задачи, как правило, монотонны, т.к. требуют повторяющихся действий.
Соответственно, что делают настоящие разработчики в этом случае? Правильно, устраняют дублирование. В том числе дублирование в методе разработки. Это могут быть генераторы кода, конструкторы форм и т.д. — любой способ хорош. Написание одинакового кода — признак недоработки или недостаточной квалификации, чтобы увидеть эту одинаковость и суметь элегантно ее устранить. :-)
Хороший аналитик экономит время разработчика этак раза в три. :-) При этом попутно снижая общий фоновый уровень негатива по поводу сроков. Вопрос, как определить, хороший перед тобой аналитик или не очень...
И если руководство считает, что разработчик должен «делать то, что нужно», а отсутствие интереса — это «личные проблемы», то это просто неадекватный менеджмент, со всеми вытекающими. Самомотивация для достижения нужного уровня концентрации также отнимает время, и от этого никуда не деться.
Лично за собой замечал (ибо регулярный тайм-менеджмент) следующие временные показатели.
При отсутствии интереса к текущей деятельности производительность падает в 3-4 раза (!).
Сравнивал временные затраты по задачам аналогичной сложности.
Соответственно, не стоит думать, что отсутствие интереса не несет прямой финансовый ущерб — ущерб самый что ни на есть прямой, даже не косвенный. И любой нормальный разработчик будет это нивелировать либо за счет личного времени, либо за счет клиента, повышая временные оценки задач.
И наиболее эффективно проблему в данном случае, ИМХО, нужно решать совместно с руководителем (команды, отдела и т.д.), который понимает суть процесса и присущие ему проблемы. Если со стороны руководства не будет понимания проблемы, затраты гарантированно будут выше, а заинтересованность разработчика в проекте — ниже.
Только получим его не на проверке размера, а на обращении к «просроченному» итератору в случае foreach-нотации.
В случае обхода List'а через size() exception'а не будет в случае обращения по индексу (в случае отсутствия конкурентного изменения несколькими потоками), однако рискуем пропустить несколько элементов в случае удаления элементов из коллекции без изменения переменной цикла. Иногда замечается у студентов-нубов, переползающих с C/C++.
Если такой скилл — «гуглить».
Некоторые люди находят таким способом то, что другие найти почему-то не могут.
Потому что чтобы правильно написать поисковый запрос, нужно немного понимать принципы, по которым строится поисковая выборка.
И это скилл также нужно прокачивать, объясняя, почему один запрос лучше другого.
Именно поэтому я не стал переходить с Java на Ruby.
Красиво, быстро…
Но когда нужно что-то понять в этом огромном множестве библиотечного динамического кода…
И никакая IDE тебе не поможет, ибо она, в основном, оперирует статикой, т.к. анализировать динамику очень долго.
IMHO, динамические конструкции хорошо подходят для написания мощных framework'ов, но они чрезвычайно вредны для бизнес-логики практически любой предметной области.
Предметная область и так достаточно сложна, чтобы привносить в нее дополнительные технические сложности.
IMHO, наиболее крутым было бы решение, которое бы имело два режима: framework и business.
Причем режим framework должен быть доступен только при инициализации приложения, а при переходе к business-коду уже ничего не должно меняться в мета-структуре языка.
Тогда этого позволило бы нашим IDE прогнать весь код из framework, построить индексы по всем получившимся mixin'ам и т.д., и в коде основной business-логики после этого уже можно бы было ориентироваться.
Если framework меняется нечасто (хотя и чаще, чем появляются новые версии языков программирования :-) ), то такой подход позволит сочетать в себе плюсы и динамики, и статики.
А еще можно прямо перед релизом, когда все экстренно фиксят баги, залить какой-нибудь особо мощный рефакторинг, включающий самую важную для релиза фичу. :-)
И все будут плакать.
Тут больше проблема не в закрытости исследований, а в цензуре.
А именно в том, для чего осуществляется эта самая цензура.
У меня лично есть подозрение, что результаты исследований таким образом могут попадать при в руки тех, кто будет делать из них деньги. А авторов просто кинут. :-)
Всегда полезно задавать вопрос: «Кому и зачем это нужно?»
А программисты склонны принимать их "требования" в качестве ТЗ.
А все потому, что вначале нужно научиться понимать других людей, а уже потом — программировать или требования писать...
Соответственно, что делают настоящие разработчики в этом случае? Правильно, устраняют дублирование. В том числе дублирование в методе разработки. Это могут быть генераторы кода, конструкторы форм и т.д. — любой способ хорош. Написание одинакового кода — признак недоработки или недостаточной квалификации, чтобы увидеть эту одинаковость и суметь элегантно ее устранить. :-)
При отсутствии интереса к текущей деятельности производительность падает в 3-4 раза (!).
Сравнивал временные затраты по задачам аналогичной сложности.
Соответственно, не стоит думать, что отсутствие интереса не несет прямой финансовый ущерб — ущерб самый что ни на есть прямой, даже не косвенный. И любой нормальный разработчик будет это нивелировать либо за счет личного времени, либо за счет клиента, повышая временные оценки задач.
И наиболее эффективно проблему в данном случае, ИМХО, нужно решать совместно с руководителем (команды, отдела и т.д.), который понимает суть процесса и присущие ему проблемы. Если со стороны руководства не будет понимания проблемы, затраты гарантированно будут выше, а заинтересованность разработчика в проекте — ниже.
Остальные аргументы слабее в данном случае.
Если это какой-нибудь legacy-код разбора XML, то в результате сбора строчки размером в 2 Mb можно потерять несколько драгоценных секунд. :-)
<irony> Ага, для массивов все именно так и происходит. :-) Прощай, скорость. :-) </irony>
Об этом явно написано в JLS (который Вы, скорее всего, еще не открывали :-) ).
В случае обхода List'а через size() exception'а не будет в случае обращения по индексу (в случае отсутствия конкурентного изменения несколькими потоками), однако рискуем пропустить несколько элементов в случае удаления элементов из коллекции без изменения переменной цикла. Иногда замечается у студентов-нубов, переползающих с C/C++.
Если такой скилл — «гуглить».
Некоторые люди находят таким способом то, что другие найти почему-то не могут.
Потому что чтобы правильно написать поисковый запрос, нужно немного понимать принципы, по которым строится поисковая выборка.
И это скилл также нужно прокачивать, объясняя, почему один запрос лучше другого.
Красиво, быстро…
Но когда нужно что-то понять в этом огромном множестве библиотечного динамического кода…
И никакая IDE тебе не поможет, ибо она, в основном, оперирует статикой, т.к. анализировать динамику очень долго.
IMHO, динамические конструкции хорошо подходят для написания мощных framework'ов, но они чрезвычайно вредны для бизнес-логики практически любой предметной области.
Предметная область и так достаточно сложна, чтобы привносить в нее дополнительные технические сложности.
IMHO, наиболее крутым было бы решение, которое бы имело два режима: framework и business.
Причем режим framework должен быть доступен только при инициализации приложения, а при переходе к business-коду уже ничего не должно меняться в мета-структуре языка.
Тогда этого позволило бы нашим IDE прогнать весь код из framework, построить индексы по всем получившимся mixin'ам и т.д., и в коде основной business-логики после этого уже можно бы было ориентироваться.
Если framework меняется нечасто (хотя и чаще, чем появляются новые версии языков программирования :-) ), то такой подход позволит сочетать в себе плюсы и динамики, и статики.
И все будут плакать.
:-)
И потом гден-ть #undef
А именно в том, для чего осуществляется эта самая цензура.
У меня лично есть подозрение, что результаты исследований таким образом могут попадать при в руки тех, кто будет делать из них деньги. А авторов просто кинут. :-)
Всегда полезно задавать вопрос: «Кому и зачем это нужно?»
kill -9.
Полностью согласен.
А отдача от senior'а будет уже через неделю-две в зависимости от сложности проекта.