Еще поною

tonsky — 27.05.2010 Сидит в голове метафора из упоминавшейся уже статьи, и до того хорошо она ложится на текущую нашу ситуацию, что не смог я молчать и сел за клавиатуру. Итак, метафора:

Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly ... imagine that you have a tool [IDE] that lets you manage huge Tetris screens that are hundreds of stories high. In this scenario, stacking the pieces isn't a problem, so there's no need to be able to eliminate pieces. This is the cultural problem: [Java programmers] don't realize they're not actually playing the right game anymore.

Steve Yegge винит во всем Джаву, но я для разнообразия не на Джаву буду жаловаться, а на своих коллег. Это ощущение, что мы давно играем не в ту игру, оно не покидает меня. Джава в этом виновата или компания подобралась такая — не знаю, но, как один из разработчиков, признаю, что в этом есть и моя вина. Только проблемы в этом никто кроме меня, кажется, не видит. (да простят меня коллеги, чьи примеры мне пришлось использовать здесь для иллюстрации. Поверьте, обидеть или оскорбить я никого не хотел).

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

Знаменитая программисткая мечта «если вдруг изменятся требования, я в одном месте поменяю и всё» цветет пышным цветом в самых абсурдных ситуациях. Гипотезы из серии «а вдруг мы захотим поменять отображение всех текстбоксов на страничках» регулярно создают много кропотливой работы по решению несуществующей задачи.

Всерьез (!) предлагалось огородиться от Wicket-а, то бишь написать собственную прослойку м/у нашим кодом и веб-фреймворком на случай, если мы захотим сменить последний. Скромное мое замечание, что вообще-то веб-фреймворки друг от друга отличаются концептуально (иначе кто бы их плодил, одинаковые?) было отметено как неправда.

Эти наши пустопорожние интерфейсы на каждый сервис и каждую даошку, которые понадобятся, только если (внимание!) мы захотим иметь вторую их реализацию, то бишь работающую с другой БД или, прости господи, с xml-ем. Отслужившим в МСС это должно быть знакомо... Я, кстати, на спор предложил, что если такая потребность действительно возникнет (реализовать именно те же самые интерфейсы и именно с другой реализацией), лично сесть и все написать в нерабочее время. Не поверили.

Идея (оказывается, была такая!) сделать scaffolding обернулась в нашем исполнении в печальную историю о том, как все промежуточные классы генерирует и поддерживает программист вручную. И почему-то мне не весело, когда в эту кучу накопированного руками, достойными лучшего применения, кода предлагают встроить какой-нибудь дополнительный механизм, «который все упростит», или, на худой случай, от кого-то огородит. Анекдот называется «что бы такого съесть, чтобы похудеть?»

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

interface EventListener {
  void onEvent(Event e);
}

Нееее... Я даже не понял сначала (правда, из-за того, что Handler событием назывался :). Мысль очень глубокая. У нас это выглядит так:

interface EventListener {
  List<EventHandler> getEventHandlers();
}

и в реализации

return Lists.newArrayList(new EventHandler() {
  void onEvent(Event e) {
  }
});

Т.е. объект не обрабатывает событие сам, а возвращает генератору события экземпляр анонимного класса (список даже, и все это на каждое событие заново создается), генератор этот список разбирает и в нем уже лежат настоящие коллбэки. Там не было никакой особенной задачи. Нужно было обработать ровно одно исключение ровно в одном месте, сразу. Это, кстати, не один человек придумал, они вдвоем посовещались.

Т.е. видно, что люди знают много, а вот применять свои знания не очень понимают как. Может быть, видели примеры, но не обратили внимания на ситуацию, в которой они используются. Аргумент «мы так на предыдущей работе делали, а они к этому решению пять лет шли» в одиночестве, сам по себе он, мягко говоря, странный.

Все это проблема. Не нужно усложнять на ровном месте, применять шаблон там какой-то только потому, что можешь. Шаблоны, как показала практика, нужны в одном случае из ста. И момент, когда какой-то из них понадобится, он так ясно сиять будет, что не ошибешься. (в связи с этим вспоминается случай, еще в МСС, когда мы какую-то штуку придумывали, втроем, и один парень просто подряд перечислял названия известных ему паттернов. Вот, буквально, не преувеличиваю: адаптер там, фабрика. Я еще хотел после этого «давайте сделаем фабрику» запрещенной фразой объявить. Большинство его предложений отметались простым «и дальше что?»).

Я к тому, что ну все-таки, рефлексировать надо. Реальные ограничения искать.



Спросите, если я так недоволен, чего не ищу другую работу? Пока есть возможность все выкинуть (по крайней мере то, что касается веб-интерфейса) и начать сызнова. Посмотрим, получится у меня или я в себе разочаруюсь. Надо только придумать, как правильнее всего огородиться. Язык, например, никому не знакомый выбрать :). Простите за нытье еще раз. Если кто-нибудь дочитал до конца, не повторяйте наших ошибок. Будьте хорошими программистами. Думайте над тем, что вы делаете. Делайте только то, в чем есть необходимость. Простите за мораль. Спокойной ночи. И доброго утра!

Оставить комментарий

Популярные посты:

• Архив