очень важный (для программистов) пост

[juan_gandhi]

Серьёзно

Upd. Попросил раззамочить.

Ну вы записывайтесь к нему в друзья; умнейший человек, между прочим.

Comments

[ygam.livejournal.com]

You are not authorized to view this protected entry.

[occam-aga.livejournal.com]

подзамоченный только немного :)

[softmaster.livejournal.com]

о важности инкапсуляции в лице protected class members? %)

[skavish.livejournal.com]

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

либо мне так везет либо просто идиотов все же существенно меньше чем принято думать

[just-developer.livejournal.com]

Вот вот...
Думать просто надо, а не java какую-либо обвинять

[yatur.livejournal.com]

Люди сурово игнорируют YAGNI (you ain't gonna need it) и KISS (keep it simple, stupid) принципы. У Кента Бека (или у Мартина Фаулера или у обоих) описаны психологические причины этого. Страх изменений. Любые изменения - это потенциальные баги и глюки. Поэтому, давайте мы сделаем программу максимально гибкой на все случаи жизни, чтобы один раз отладить и потом только конфиги менять.

Разумеется, это недостижимо :( Отсюда и идея agile programming: embrace change. Но как и любые другие психологические привычки, привычку говорить "а вдруг нам понадобится..." трудно изжить.

[tonsky.livejournal.com]

Да, про страх хорошо. И embrace change. Это ж суть agile, но как-то она ускользала от меня. Слушайте, спасибо!

[yatur.livejournal.com]

Пожалуйста. Всегда приятно пообщаться с умным человеком :)

[relyef.livejournal.com]

Чушь там написана. Если бы написавшего звали многосложным индийским именем, я бы хоть понял, откуда у него такие взгляды. Copy-paste - наше все? (последняя фраза - это был сарказм)

[selfmade.livejournal.com]

http://tonsky.livejournal.com/202390.html?thread=656534#t656534

[vit-r.livejournal.com]

Давным давно известный феномен.

Одним нравится находить решение задачи, другим нравится программирование.

[izard.livejournal.com]

Спасибо, действительно хорошо пишет, зафрендил.

[plumqqz.livejournal.com]

"Оказывается, я уже сорок лет говорю прозой!"

[ok-its-the-last.livejournal.com]

Вот-вот. Лошадь ест овес.

[wakes-up.livejournal.com]

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

[gabaidulin.livejournal.com]

Прочел несколько постов и вот что пришло в голову. Многие примеры, которые он приводит, это же классическая SOA архитектура. Она, кстати, вполне себе имеет свою нишу и не только в enterprise, а например в компаниях, у которых много севисов и которая, комбинируя их, может получать новые(Yandex, Rambler, Mail и много других). А то что она несколько многословна, так это цена за гибкость строить "приложения из кубиков". Многие компании в том или ином виде ее используют. Ну java предлагает делать это так.

Получается, что он "Пастернака не читал", потому что ни одного наезда на эту самую SOA я не увидел, а ругалась только имплементация. А как ее сделать по-другому и сильно лучше, используя java, это еще вопрос.

[gabaidulin.livejournal.com]

Тем более, что есть всем(?) известные рецепты, как эту многословность, хотя бы, не писать руками.

[tonsky.livejournal.com]

Еще бы не видеть ее глазами.

[gabaidulin.livejournal.com]

Я имел в виду кодогенерацию.

[tonsky.livejournal.com]

Ну как SOA? Система одна, монолитная. Это считается SOA?

[gabaidulin.livejournal.com]

Я просто увидел в постах очень характерные паттерны. Например, предоставлять клиентам некоторое api через интерфейсы.

SOA вообще декларирует не реализацию, а подход. Чтобы было понятно, приведу пример. Допустим у вас есть задача аутентификации и авторизации юзера.

Самый простой вариант имплементации, это получение от юзера логина и пароля, проверка его через хранилище данных и так далее.

Но иногда некоторые сумасшедшие люди реализуют целый отдельный сервис для этих целей, у которого есть api(с которым и общается программа-клиент), есть несколько реализаций(для разных протоколов). Иногда даже специальнвй протокол, который потом оборачивается в JSON/XML и который потом доставляется через HTTP/SOAP/TCP.

Отсюда и растут все эти AuthImpl и так далее.

Зачем?

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

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

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

Из ваших постов я не понял, недовольны ли вы архитектурой SOA в целом, ее имлементацией или ее неоправданным(по вашему мнению) применением.

[vaggie.livejournal.com]

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

[yakov-sirotkin.livejournal.com]

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

[nikaan.livejournal.com]

я вот такое видел : когда человек писал на все случаи жизни, но при этом ещё не ясно представляет итог. В какой-то момент оказалось, что всё написанное несовместимо с тем, что надо. Пришлось переписывать(мне, и совсем не в объектно ориентированном стиле:)), быстро, и конкретно под этот случай. Потом, правда, проект всё равно закрылся:) но это неважно.

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

[nikaan.livejournal.com]

представлял

[tonsky.livejournal.com]

Точки расширения или роста вроде.

[nikaan.livejournal.com]

тут надо уточнить - речь не об общей архитектуре или о дизайне, а о куске непосредственно работающего кода. Я его себе представляю как канализацию - с трубами и т.д. В этом случае "концы" легко заменяемых деталей обычно узкие. Потому я и точки называю точками сужения. Вроде бы в книжке (не помню кого) "эффективная работа с унаследованным кодом" про это писалось в такой же терминологии - там в контексте того, какие места лучше покрывать тестами (в первую очередь). А откуда пошла быть Ваша терминология?

[tonsky.livejournal.com]

Много же у вас друзей. Спасибо :)

[jdevelop.livejournal.com]

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

поэтому спокойно читать такие псто не могу, это если опус прочитает какой-нить джуниор и начнет грамотно аргументировать "я тут написал стопиццот функций getHui1/getHui2/..../getHui200 с одним разным параметром, потому что кто ж это будет менять!"

или блядь запилить в DAO на сохранение юзера еще и отсылку емылов, варку кофе и прочие внезапные сайдэффекты

а потом заставить написать к этому юниттестов

просто - надо включать моск.