KISS

[alexinspir]

Keep It Simple, Stupid. - Commandment of Developers.

Столкнулся с ситуацией, когда первоклассный код(100% согласованность со спецификациями и соглашениями), который основан на базе детального проектирования на UML (RUP), с огромными возможностями для расширения был оценен на 3 из 10 балллов. На вопрос "Что не так?" был довольно длинный ответ с кучей критики:
1. рядовые разработчики не способны понять код.
2. жертвование пониманием кода в пользу быстродействия (да, есть такое - пара методов для расширенной (де)сериализации очень туги для понимания, но их задача снижать нагрузку на самые узкие места - выгода очевидна)
3. использование очень сложных фреймворков(это я как понял продолжение 1-го пункта).
4. UML диаграммы слишком детально проработаны, внедрение нового функционала повлечет добавление нового функционала как в диаграммы так и в код(тут я афигел по полной, а разве новый функционал не должен добавляться в uml для оценки влияния на остальной функционал?)

Собственно вопрос - зачем совершенствовать свои знания и умения, если их нельзя применять? Или мне просто не повезло с заказчиком(подрядчиком)?

[Stilet]

Или мне просто не повезло с заказчиком(подрядчиком)?

Однозначно не повезло. Хороший заказчик вообще не должен умничать, навязывая разработчику свой сарафан. Главное ты его ТЗ четко выполнил? Если да то такого заказчика гнать в шею.

рядовые разработчики не способны понять код.

Не знаю над чем посмеялся ты но это меня больше всего пацтол уложило ))))))

[alexinspir]

Сообщение от Stilet

Однозначно не повезло. Хороший заказчик вообще не должен умничать, навязывая разработчику свой сарафан. Главное ты его ТЗ четко выполнил? Если да то такого заказчика гнать в шею.

Проблема вся в том что это заказчик-подрядчик(у него свой заказчик) - как я позже выяснил, он по фрилансерам раскидывает модули(unit'ы).
Совпадение с ТЗ полное(любые библиотеки и фреймворки, которые не влияют на остальные части ПО разрешалось использовать)

Сообщение от Stilet

Не знаю над чем посмеялся ты но это меня больше всего пацтол уложило ))))))

Меня убили на повал 3 и 4 пункты.
С первыми двумя доводилось уже встречаться, удавалось аргументированно доказывать правильность своего выбора.

[Ivan_32]

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

Вас попросили перевести с русского на английский, вы перевели. Заказчик:
- Нет так не пойдет, это на английском, я не понимаю!

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

[Stilet]

использование очень сложных фреймворков

А подробнее тебе не расписали в чем они сложность видят?
О каких фреймворках они вообще говорят?

[alexinspir]

Сообщение от Stilet

А подробнее тебе не расписали в чем они сложность видят?
О каких фреймворках они вообще говорят?

Хотел внедрить Spring по началу - я предложил, мне отказали(для области администрирования проекта) без объяснения причин.
Потом получил разрешение для Hibernate, ну и начал юзать его в полную силу.
Ругались именно на то что использовал не helloword'ный функционал, а довольно сложные механизмы(много внешних связей в таблицах, использование HQL на всю его мощь и тд).

[Stilet]

Ну стало быть тебе только посочувствовать можно )

[Ivan_32]

А если честно, как это все влияет на производительность - весь этот дополнительный парсинг, многоуровнвые классы итд? Или все это явным или не очень, образом заставляет Java-машину оптимизировать компилируемый байт-код ?

[alexinspir]

Сообщение от Ivan_32

А если честно, как это все влияет на производительность - весь этот дополнительный парсинг, многоуровнвые классы итд? Или все это явным или не очень, образом заставляет Java-машину оптимизировать компилируемый байт-код ?

не понял, причем тут парсинг и многоуровневые классы?

Hibernate нужен для того чтобы сделать ПО почти независимым от вендора базы данных(+ запросы он оптимизирует хорошо), плюсом избавится от необходимости писать кучу сложных SQL запросов для добавления/обновления данных.

Spring (MVC модуль) нужен для эффективного отделения графики от логики - чтобы не смешивать все и облегчать поддержку и изменять отображение без необходимости менять логику.

Сериализацию и Десериализацию( java.io.Externalizable ) детально делал для отбрасывания ненужной информации и сжатия нужной - обмен сообщениями будет очень масштабный - сетевой канал может быть нагружен катастрофически.

[russian-stalker]

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