LINUX.ORG.RU

Напутствие в трудной жизни.

 


9

3

Дисклеймер. Этот пост всесторонне вдохновлен каким-то древним видео в интернете, автора которого я благополучно забыл. Если автор сейчас читает это - респект тебе и увага, бро!

Итак.

Помойму программисты сильно перегибают палку.

Засрали всю джаву мусором.

Хотите вы бин, и что-то в нем хранить тупо, сделайте все поля public! Вместо лесов геттеров-сеттеров.

Боитесь, что такой класс (с пабликами) будет не thread-safe и хомяки не смогут писать с ним хороший многопоточный код? Да побойтесь б-га, хомяки вообще не напишут хорошего многопоточного кода, всё это миф. Дайте среднестатистическому человеку треды и локи, и он напишет код в миллион раз более медленный, чем аналогичный на готовом TransferQueue. Вот и пишите свой продюсер-консумер на TransferQueue, не выпендривайтесь.

ООП, и конкретно механизм наследования, очень плохо подходит для увеличения реюзабельности кода. Глупому заказчику можно втирать рекламу ООП=реюзабельность, но мы тут все грамотные люди, линуксоиды, как минимум с 8 классами образования, мы же все понимаем как оно на самом деле. Трейты/миксины и препроцессор и то с этим лучше справляются иногда.

Но сидят сумрачные гении, и ночами напролет пишут какие-то иерархии классов, чтобы одну строчку копипасты сэкономить. Всё это фигня! В такой надуманной иерархии классов еще сложней разобраться, чем отрефакторить копипасту. И уж точно ее сложнее модифицировать. Мой совет: копипастите смело и открыто! Если коллеги будут придираться, спокойным голосом, глядя на правое ухо поциента, говорите: «вот сам и поправь», 90% что коллега посинеет от страха и сдрыснет в ужасе, в остальные 10% можно утешаться тем, что эту лажу писать пришлось хотя бы не тебе.

Никто не заставляет писать Factory которые производят Factory, которые производят Factory! Хочешь посмотреть, откуда берется объект, а там целый стектрейс на 50 этажей, можно блуждать пока не умрешь от голоду. Хотите сделать объект - ставите new и поехали. Сразу понятно - вот тут делается объект. Фактори нужно изничтожать безбожно (только если это не Spring, Spring надо пожалеть).

И вообще, дизайн паттерны - сплошной хлам. Получается говно вместо результата - давайте нафигачим дизайн паттерн! На каждую проблему есть свой дизайн паттерн! И получается, одна строчка смысла, всё остальное мусор, костыли как они есть. Это стрёмно, господа. Почитаешь какой-нибудь код, и так вымажешься в дизайн-паттернах с ног до головы, что потом по улице стыдно идти, на людей смотреть.

Никаких фреймворков! Ехал фреймворк через фреймворк, и все - говно. Каждый день кто-то еще производит новый фреймворк. Потом набигают ПМы-хипстеры и такие, а что у нас популярно? Ахххаха, гороскоп показывает, что в эту фазу луны популярен Wicket, давайте нафигачим на нем гуй для Международной Космической Станции. Потом где-то там эта чушка не распарсила XML, свалилась в корку обосравшись стектрейсами, и все космонавты сварились. Отлично! Зато фреймворк!

Особенно радуют люди, которые боятся эти фреймворки чинить. Ололо, всё работает через задницу, но трогать не будем. Потому что - потом поддерживать же свой «форк» надо! Лучше нагородим еще костылей вокруг кривого фреймворка! Мотивируется это тем, что «на дальней дистанции» хомякам проще будет писать костыли, чем фиксить фреймворк. Но это ложь, через пару лет развития проекта уже совсем в этих костылях не разобраться. Совет тут такой: не использовать фреймворков, а если использовать - то понимать как они работают, и чистой душой фиксить их, а коммиты стараться засылать в апстрим.

Это всё от другой болезни, называется «Архитектура». Ее нужно долго придумывать, и потом всех насиловать. Можно сказать, архитектура передается половым путем, как сифилис и гангрена. Кто-то из великих говорил, что архитектура - это самая стрёмная, самая зачерствевшая и неизменяемая часть кода, то что фиг изменишь. Нормальный код должен легко меняться. Но во все времена были люди, поклоняющиеся говну. И вот тут, обязательно найдутся поклонники архитектуры. Совет тут такой: шлите архитектуру в зад, пишите гибко изменяемый код, так чтобы (если такая возможность потребуется) двумя легкими движениями рефакторинга текстовый процессор превращался в графический редактор и наоборот. Софт - это не паравоз, нельзя взять три семьнадцать колес, паровой бачок, сложить их по чертежу(архитектуре) и получить паровоз. Софт - это непрерывный процесс рефакторинга.

Никаких лесов комментариев! Пишут, значит, целые поэмы там. А кто эти поэмы потом апдейтить будет? Потому что понапихали своих дизайн-паттернов и фреймворков, отформатировали в кривую архитектуру, ничего уже не понятно, что код делает! Надо пояснить суть поэмой! Резюме тут такое: в коде должно быть написано ровно то, что он делает. Если строчки кода расходятся со смыслом, этот код нужно переписать, а не подпирать комментариями.

Самая жуть, это всякие ынтерпрайзные сервера, портлеты, фигеты, шушпанчики. Вот притащил ты себе в проект WebLogic или еще какой-нибудь архитектурно-окаменевший кусок, и что изменилось? Кстати, вы видели чтобы на одном реальном хайлоадном сервере запускалось больше одного приложения? Обычно бывает как раз наоборот - на куче серверов запускается ОДНО приложение! А сколько бед от этой псевдофункциональности по огранизации шаред хостинга! Что ынтерпрайзные сервера лучше делают, чем Jetty запущенная прямо из функции main? Собственно в этом и совет, запускайте джетти откуда-нибудь руками, или из мавена, и не парьте мозг.

Надо писать так, чтобы код отражал СУТЬ. Чтобы деплой отражал СМЫСЛ. Посмотрел на код - и сразу понятно, что там написано. Запустил сервер - и сразу понятно, что и как он обслуживает, где скачать его исходники и пофиксить, если чо.

Если вы последовали перечисленным советам, но вас никто не понимает, скажите что stevejobs с лора разрешил.

В общем, идея понятна, теперь можно приступать к критике :)

Привет.

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 2)

нельзя засрать говно

ТС слаб

/thread

anonymous
()

ООП, и конкретно механизм наследования, очень плохо подходит для уменьшения реюзабельности кода.

Когда Кей придумал термин ООП он не имел в виду плюсы. И, уж тем более, он не имел в виду жабу.

А вообще, судя по твоим рассуждениям,похоже, ты созрел отказа от жабы и перехода на что-то вменяемое.

anonymous
()

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

dycore
()

Стив порвался, гет ин зе AbstractSingletonProxyFactoryBean

TERRANZ ★★★★
()

гангрена не передается половым путем.

по сабжу - с выводом и резюме согласен.

bvn13 ★★★★★
()

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

ООП, и конкретно механизм наследования, очень плохо подходит для уменьшения реюзабельности кода

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

Никто не заставляет писать Factory которые производят Factory, которые производят Factory!

простые объекты так создавать можно, сложные - никак

И вообще, дизайн паттерны - сплошной хлам. Получается говно вместо результата - давайте нафигачим дизайн паттерн!

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

Никаких фреймворков! Ехал фреймворк через фреймворк, и все - говно

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

Это всё от другой болезни, называется «Архитектура».

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

Никаких лесов комментариев! Пишут, значит, целые поэмы там

лорчую

Самая жуть, это всякие ынтерпрайзные сервера, портлеты, фигеты, шушпанчики.

лорчую, сам ушёл от апачей и глассфишей в сторону джеттей

Jetty

лорчую

Надо писать так, чтобы код отражал СУТЬ. Чтобы деплой отражал СМЫСЛ. Посмотрел на код - и сразу понятно, что там написано. Запустил сервер - и сразу понятно, что и как он обслуживает, где скачать его исходники и пофиксить, если чо.

лорчую

TERRANZ ★★★★
()
Последнее исправление: TERRANZ (всего исправлений: 1)

Хотите вы бин, и что-то в нем хранить тупо, сделайте все поля public! Вместо лесов геттеров-сеттеров.

Ну мудаки так делают. Это не то что там var <>myvalue

anonymous
()

И вообще, дизайн паттерны - сплошной хлам. Получается говно вместо результата - давайте нафигачим дизайн паттерн! На каждую проблему есть свой дизайн паттерн! И получается, одна строчка смысла, всё остальное мусор, костыли как они есть. Это стрёмно, господа. Почитаешь какой-нибудь код, и так вымажешься в дизайн-паттернах с ног до головы, что потом по улице стыдно идти, на людей смотреть.

Ага, это дело. Я вот сам нихуя не знаю, что это такое и живу счастливо.

anonymous
()
Ответ на: комментарий от buddhist

С тем, что у ТС окончательно крыша поехала? Я тоже этого опасался.

anonymous
()
Ответ на: комментарий от bvn13

гангрена не передается половым путем.

так и знал, что по остальным пунктам вопросов не будет :]

stevejobs ★★★★☆
() автор топика

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

handbrake ★★★
()
Ответ на: комментарий от TERRANZ

у нас есть набор паттернов (GoF+что там еще добавилось), и у каждого паттерна есть пред-условия его использования.

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

Пример: нам нужно создать объект. Может ли этот объект стать сложным? Да. Значит, используя архитектурное мышление, мы сразу фигачим туда Factory.

Если используется какой-то из test-first подходов, т.е. человек точно знает, что он делает, он и предусловия впихивания паттернов видит очень четко, ну и впихивает их, конечно.

И вот пока так код пишется, в маленьком локальном месте, всё кажется нормально. А потом получается как в книге «По ту сторону добра и зла. Прелюдия к философии будущего»: Кто сражается с чудовищами, тому следует остерегаться, чтобы самому при этом не стать чудовищем. И если ты долго смотришь в бездну, то бездна тоже смотрит в тебя."

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

stevejobs ★★★★☆
() автор топика

ООП, и конкретно механизм наследования, очень плохо подходит для уменьшения реюзабельности кода.

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

Пятница далеко, а ты уже бухой. С работы выперли за эти выкрутасы?

anonymous
()

Хотите вы бин, и что-то в нем хранить тупо, сделайте все поля public! Вместо лесов геттеров-сеттеров.

Нативных пропертей то не завезли еще, да и куча фреймворков сломается. А вообще согласен. Если заводишь поле и делаешь access-методы, просто чтобы получить/засетить значение, то это нарушение инкапсуляции и вообще эталонный быдлокод. Но дело в том, что джава так заставляет.

ООП, и конкретно механизм наследования, очень плохо подходит для уменьшения реюзабельности кода.

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

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

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

И вообще, дизайн паттерны - сплошной хлам.

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

Насчет фреймворков полностью согласен. Особенно доставляет, когда исходники проекта весят 7 метров и депенденсей на гиг.

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

slyjoeh ★★★
()

Все твои килобайты текста о том что надо писать кратко и по делу, ты сам себе противоречишь.

Deleted
()

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

Не совсем так: архитектура не меняется со временем, а код отражающий архитектуру меняется постоянно. Реализация != архитектура. Архитектура != код. Архитектура это описание [без технических подробностей реализации] идеи как должно работать: если имеется такое действие, то на выходе такой результат.

Когда архитектура содержит технические детали данный документ становится спецификацией.

Книгу забыл, возможно, 97 этюдов для архитекторов программных систем.

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Ответ на: комментарий от slyjoeh

перекинет реквест на другой сервер и корректно допроцессит.

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

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от slyjoeh

Насчет фреймворков полностью согласен. Особенно доставляет, когда исходники проекта весят 7 метров и депенденсей на гиг.

А что тут не так? Лучше, когда исходники проекта весят 70 метров, депенденсей нет и проект пишут в 10 раз дольше?

Legioner ★★★★★
()
Ответ на: комментарий от stevejobs

данные в оперативке лежат

На диске, синхронизируются между серверами при выполнении каких-то не до конца понятных условий. Медленно, зато надежно.

slyjoeh ★★★
()
Ответ на: комментарий от gh0stwizard

Ну вот гляди, фигачишь ты значит код, и тут залетает Галочка из бухгалтерии, наэлектризованные волосы дыбом, и кричит: спасите, помогите, НИЧЕГО НЕ РАБОТАЕТ. И под «ничего не работает» подразумевается, что на форме «поиск клиента» нету возможности искать по телефону клиента. Ну пошел, запилил ей тут же такое поле за 5 минут. Назавтра еще что-нибудь запилил, и еще что-нибудь, и еще.

А при этом у тебя на столе лежит толстая «СПЕЦИФИКАЦИЯ», фичи из которой еще даже до середины не допилена. Т.е. нужно синхронизировать СПЕЦИФИКАЦИЮ с тем, что реально происходит в системе. Нужно уметь врать в обе стороны (этих фич пока нет, но мы их обязательно сделаем... эти фичи мы сделали хотя нету в спеке, потому что... этих фич не запланировано в спеке, но обязательно запланируем...). Итп. Пока что не видел НИ ОДНОГО человека, у которого бы это получилось сколько-нибудь хорошо. В результате СПЕЦИФИКАЦИЯ получается толстенным фантастическим документом, описывающим параллельную вселенную. Когда в СПЕЦИФИКАЦИИ больше пары сотен страниц, ее перестают читать даже ведущие разработчики, уже на первой сотне становится понятно, что ты читаешь bullshit.

Из этого делаю следующий вывод: лучшая спецификация - это сама система. Применительно к языкам, «язык программирования» - это то, что умеет собирать мой компилятор.

Лучше всего для специфицирования использовать ТЕСТЫ, написанные на языке программирования. Создание нового теста можно считать внесением нового требования в спеку, тз, anything.

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от anonymous

А вообще, судя по твоим рассуждениям,похоже, ты созрел отказа от жабы и перехода на что-то вменяемое.

Тяжелые наркотики?

Virtuos86 ★★★★★
()
Ответ на: комментарий от Legioner

А что тут не так? Лучше, когда исходники проекта весят 70 метров, депенденсей нет и проект пишут в 10 раз дольше?

Лучше, когда для парсинга даты не выбирают кучу фреймворков, которые потянут весь maven central (утрирую).

slyjoeh ★★★
()
Ответ на: комментарий от slyjoeh

Синхронизируются на диске? То есть вот этот мой запрос к Ораклу, который вытянул из базы 5 гигбайт записей, скинуть на диск и потом разослать по всему кластеру, и так перегруженному, после чего он веерно захлебнется?

И я правильно понимаю, что предполагается сразу всем рассылать этот дисковый дамп? То есть, производительность кластера начинает равняться производительности самого слабого сервера в нем? Опачки, приехали!

stevejobs ★★★★☆
() автор топика
Ответ на: комментарий от dycore

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

Все говорят: «Кино для дураков, кино для дураков». А мне нравится!

Virtuos86 ★★★★★
()

Однажды я решил написать КОД. А что главное в любом коде? Даже дети знают - главное это СУТЬ. Вот эту-то пресловутую СУТЬ, значит, мне и нужно максимально скрыть, решил я как самый настоящий программист.

А что в первую очередь помогает раскрыть суть кода? Архитектура, решил я. Это самое главное. Она же непосредственно привязана к модели предметной области и за ней следует и изменяется. Поэтому сделал архитектуру максимально неудобной для изменений, неясной, не связанной с предметной областью вообще. Признаться, поначалу я вообще хотел от неё отказаться, но потом подумал, что плохая архитектура хуже чем её полное отсутствие.

Дальше, решил я, нужно что-то делать с ООП, а конкретно с наследованием. И действительно, его применение может сделать суть кода более понятной. Стало быть, оно второй мой враг. Преисполненный решимости, я начал наследовать все от всего, делая иерархии классов глубиной все больше. И труды мои были вознаграждены - наследование больше не отражало схожесть поведения, а больше проходило на кашу. Сначала я хотел вообще от него отказаться, но потом понял, что мой код с плохим наследованием скрывает суть гораздо лучше. Я был доволен... Но недолго.

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

Особенно я нашёл полезным паттерн фабрика и похожие. И впрямь - когда у меня была сложная логика создания объектов, способная вызвать исключения, обращающаяся к базе, требующая работы десятков объектов, я использовал new, в остальных случаях делал фабрику. Чтоб ещё сильнее всех запутать, фабрики у меня порождали фабрики. Всегда. Нужно было обладать сообразительность, чтоб найти фабрику, породившую объект. Здорово. Без фабрик, с одними new, было бы не то, подумал я и потер руки.

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

Контейнер я взял давно уже не поддерживаемый. Это не сильно скрывает суть, но зато потом будет интереснее. Заточить код только под него не составило труда.

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

Устав от проделанной работы я закоммитил код с тщательно скрытой сутью в основную ветку и отправился спать.

anonymous
()
Ответ на: комментарий от anonymous

...пошел спать, в надежде завтра ещё поработать на СМЫСЛОМ деплоя. Уж больно он явный остался.

anonymous
()
Ответ на: комментарий от stevejobs

В целом все верно, но: 1) Не нравится/не нужно - просто не используй, юзай джетти из мейна, никаких проблем 2) Не обязательно по всему кластеру, можно только на наименее нагруженные серваки 3) Да, значительно проседает производительность, но не настолько что аж п-ц. 4) Если девелопер в код вытягивает из базы 5 гигов данных, возможно, он тогда был не в лучшем расположении духа.

slyjoeh ★★★
()
Ответ на: комментарий от stevejobs

Когда в СПЕЦИФИКАЦИИ больше пары сотен страниц, ее перестают читать даже ведущие разработчики, уже на первой сотне становится понятно, что ты читаешь bullshit.

Ммм. Помнишь книгу о человекомесяц? Вот у них были спеки из нескольких десятков толстых-толстых книг. И ничего, справлялись. Наоборот, там это всех мотивировало: т.к. было четко и ясно куда стремиться, а что выбросить в мусорную корзину.

Может тут еще играет менталитет, т.к. я заметил, что запад (и восточная азия) стремится минимизировать времязатраты на разработку кода, в то время как другие пытаются минимизировать время на разработку спецификаций. К слову, спецификацию писать проще, потому что она похожа на книгу о фэнтези: выдумываешь, выдумываешь и выдумываешь. А код просто так не выдумаешь, ибо тут у нас ограничения по CPU, тут по ОЗУ, тут еще сетевой стек кривой и не наш, а тут файловая система не обновлена и т.п. Масса ограничений, масса вопросов, которые надо решать. Но все эти технические вопросы быстро решаются, когда есть опыт.

Из этого делаю следующий вывод: лучшая спецификация - это сама система. Применительно к языкам, «язык программирования» - это то, что умеет собирать мой компилятор.

Назови ЯП у которых есть спеки и у которых нет (ответ). Вот автор Erlang призновался (книга с интервью разработчиков ЯП), что ему трудно было написать спецификацию к языку. И что в итоге? В итоге, C это mainstream-язык, потому что есть стандарт.

Кстати, в US, в отличие от СНГ, просто так писать код на ЯП без стандартов в ряде случаев нельзя: для гос. структур, для военных нужд и т.д. Скажешь бюрократия? Нет, все логично, потому что когда наступит момент выяснения ответа на вопрос «кто виноват» спецификация ответит на 95% этого вопроса. Ответ будет скорей всего: разработчик. Не потому что плохо пишет код, или у него синдром архитектуры, а потому что он проглядел спецификацию.

Лучше всего для специфицирования использовать ТЕСТЫ, написанные на языке программирования. Создание нового теста можно считать внесением нового требования в спеку, тз, anything.

От спецификации вреда никогда не будет, если за спецификацией следить и исправлять.

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)
Ответ на: комментарий от anonymous

А как ты хотел? Не всё ж таксистам о программировании рассуждать.

anonymous
()
Ответ на: комментарий от Hertz

Приглашаем программистов в хороший проект без пагубных зависимостей™.

Deleted
()

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

Ничего удивительного. Просто джава - она такая. И ничего другого из неё не вылепишь. А от RM не спрятаться, не скрыться.

blexey ★★★★★
()
Ответ на: комментарий от gh0stwizard

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

тут можно начать беседу о качестве. НО. Есть такой отличный пример, Oracle. Когда-то была отличная качественная база данных, Ingres. Потом с ней начал конкурировать Oracle Database. Оракловцы не сильно заморачивались над суперкачеством, а просто фигачили и фигачили всё новые и новые фичи. История всех рассудит. И где теперь Ingres? Сейчас Oracle всех нагнул.

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

для гос. структур, для военных нужд

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

момент выяснения ответа на вопрос «кто виноват»

имхо, это ущербная логика. Софт - это не паравоз. В паравозе можно рассчитывать, что багов почти не будет. В софте баги будут всегда, и много. Если пользоваться бинарной паравозной логикой «работает/неработает», то софт вообще никогда не работает. Для фиксинга багов существует команда поддержки, которая фиксит баги начиная с первой альфы и заканчивая смертью проекта. Баг - это не повод искать виноватого, это повод завести тикет в багтрекере.

для военных нужд

есть специальные сферы, в которых такой подход не действует: медицина, космонавтика, война... Можно просто не связываться с этими сферами, для них есть специальные люди, всякие С++ники замороченные на стопроцентной отказоустойчивости.

И что в итоге? В итоге, C это mainstream-язык,

а кто говорил, что Эрланг очень хотел быть мэйнстримом? Помойму всё как раз наоборот обстоит. Его в 1998 году только опенсорснули, а появился он в 1986 году (я в этом году родился :-). И даже сейчас наверняка свои патчи в «опенсорсный» эрланг ты сможешь послать только прямиком в Спортлото, в самом Эриксоне их даже читать не станут.

stevejobs ★★★★☆
() автор топика

Надо писать так, чтобы код отражал СУТЬ. Чтобы деплой отражал СМЫСЛ. Посмотрел на код - и сразу понятно, что там написано

Кто-то сказал Python?

И вопрос не по теме: а что сейчас считается «курсом молодого бойца» по Java?

alpha ★★★★★
()
Ответ на: комментарий от stevejobs

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

Ну ты сравнил. Вот тут вопрос по делу: ты архитектуру в лес советуешь послать потому что увидел проект, который делало 1.5 человека? Тогда твой совет, скорее к месту, чем нет. Да, в одиночку поддерживать спеку, фигачить код для системы, параллельно еще решать текущие вопросы, очень сложно. Плюс тебе выставляют срок (или ты сам наобещал заранее), что задачу на 1000 человеко-часов ты решишь за 2-3 недели. Анрил по всем пунктам. Решение одно: писать код, день и ночь писать код. Архитектуру спланировать? Нафиг! Первое, у тебя нет времени на размышления. Второе, тебе столько не платят: вопрос не в точной сумме ЗП, а именно по соотношению к человеко-часам; т.к. если делать все граммотно, то эти человеко-часы делятся между 5-100 людьми и у всех своя конкретная ЗП, а заказчик, т.е. твой работадатель, лично отсегивает суммы с 6 нулями из бумажек с зеленым цветом.

у тебя есть какие-то идеи, как можно поддерживать актуальные спеки так, чтобы это не ударило по скорости разработки?

Да, есть. Идея не моя, несвежая, простая как два пальца: спеки и код должны писать разные люди. Если спеки и код пишет один и тот же человек, то он должен это делать разные промежутки времени: месяц писать хорошо, честно, усидчево спеку, потом три месяца писать код. Снова переключится на спеку, чтобы в ней исправить недочеты, выявленные в ходе работы над кодом. Фантастика? Да, я знаю :-)

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)

Ты молодец! Вся суть Java разработки!

trex6 ★★★★★
()

Вот это попаболь! Не часто такое увидишь...

I-Love-Microsoft ★★★★★
()

узнал автора по длине поста.

crowbar
()
Ответ на: комментарий от Virtuos86

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

dycore
()

Нет абзаца про maven, непорядок.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.