- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
class function TTransfer.getCreditStateOFCreditPoints(creditPoints:Int64):Integer;
begin
Result := 0;
if (creditPoints>=0) AND (creditPoints <200) then
begin
Result := 1;
exit;
end;
if (creditPoints>=200) AND (creditPoints <600) then
begin
Result := 2;
exit;
end;
if (creditPoints>=600) AND (creditPoints <1200) then
begin
Result := 3;
exit;
end;
if (creditPoints>=1200) AND (creditPoints <2000) then
begin
Result := 4;
exit;
end;
if (creditPoints>=2000) AND (creditPoints <3700) then
begin
Result := 5;
exit;
end;
if (creditPoints>=3700) AND (creditPoints <7000) then
begin
Result := 6;
exit;
end;
if (creditPoints>=7000) AND (creditPoints <15000) then
begin
Result := 7;
exit;
end;
if (creditPoints>=15000) AND (creditPoints <25000) then
begin
Result := 8;
exit;
end;
if (creditPoints>=25000) AND (creditPoints < 100000) then
begin
Result := 9;
exit;
end;
if (creditPoints>=100000) then
begin
Result := 10;
exit;
end;
end;
Типа Ы-нтерпрайз код. Где таких делают только.
Follow us!
К сожалению я сплошь-и-рядом вижу ынтерпрайзников которые о таких вещах не задумываются.
А вот где делают тех, кто пишет интерпрайз на поскале??
И что такое "говнофреймворков не тянет"?
Но для серверов зависимость от фреймворков/либ никогда не была проблемой, имхо.
што?;)
И есть к нему разные гуи.
Например вот http://www.eclipse.org/cdt/
Что не так-то?
Вон у CLION какой дебагер отличный:
https://www.jetbrains.com/clion/quickstart/img/debugger.png
Х.з. Спокойно дебажил код на другой машине через gdbserver и QtCreator. Вроде бы есть всё, что надо для счастья. По крайней мере мне хватало.
А готовые фреймворки вроде упомянутого выше Drools это еще мегабайт 300. Лучше написать свое, теплое и ламповое. Как в этом примере)
Потому и было придумано:
http://www.drools.org/landingPage/Limited_Decision_Table_Big.png
http://www.drools.org/landingPage/Guided_Decision_Table_Big.png
Подобные штуки позволяют:
1) бизнес-аналитикам и математикам редактировать данные не влезая в код
2) редактировать данные в удобно формате
3) версионировать их
4) применять данные не перезапуская приложение
как-то так)
Ну плюс еще плшки вроде визуализации
А потом у них вместо BRMS такие вот ифы, вместо OLAP кубов 100500 страничек с SQL запросами, вместо SOAP свой собственный протокол с авторизацией наколенной, итд
Обычно девелоперы пилят на коленке квадратноколесные велосипеды из бойлерплейта, багов и боли, и гордятся тем что у них нет ORM, OLAP, SOA, ESB итд.
ЗЫ: ну и когда главное быстродействие, то применение SOAP как минимум спорно. Уж лучше BSON какой нибудь или свой бинарный протокол.
Разумеется.
Но у большинства энтерпрайз система боттлнек вовсе не коммуникейшенах между системами. И такие конструкции как сквозная авторизация (ws-federation), ws-роутинг да и сама возможность герерировать статически типизированный прокси-класс по контракту -- такие вещи целиком эти проблемы перекрывают)
---
А вот людей, которые сначала вручную отдают друг другу JSON, потом вручную пилят SSO, потом забывают обновить документацию и путаются в параметрах -- такое сплошь-и-рядом
Было написано на Спринге с Хайбернейтом запускалось в Томкате (ну это не столь важно) с жсп страничками и т.п. В репозитории проекта было около 40-50 джаров. Деплоймент был такой стремный, что Томкат не мог с ним совладать, и каждый раз, когда приложение пересобиралось, сервер тоже нужно было рестартить. Весь процесс занимал минут пять.
По хорошему, все приложение можно было уложить в десяток-два ХТМЛ страничек, но поскольку жсп = шаблоны собирающиеся инклудами по кусочкам, этих кусочков там было до сотни примерно.
Но вообеще у каждого свой опыт, конечно. Обычно я встречаю именно что наколенщиков, не желающих понимать что их задачу можно немного генерализировать и она кажется уже решена тысячу раз, причем стабильнее, красивее и с плюшками)
И как свою морду к почте пилили я видел, и как писали тьму одинаковых CRUD запросов потому что "хибернейт говно" и как репорты верстали вручную и каждому репорту писали SQL запрос потому что "кубы это сложно и ненужно" и как делали самописный таск шедулер чтоб эти репорты отправлять ("кварц тяжелый") и как вручную гоняли JSON а потом путались в API и надо было "спросить у разработчика что это поле значит" ("зато не тяжелый soap") и как делали сквозную авторизацию передавая ГЕТом везде какой-то ID (ну, про federation молчу), и как вместо приснопамятного brms делали кучу ифов итд.
Видел даже как свою вики пилили.
Так что по помему опыту именно так и бывает...)
------
ps: самый смак что я видел, это когда ребята выставили нам API, и поверх HTTP придумали свой протокол и реализовывали там приватные ключи: "мы вам передаем N байт, а вы их ксорите с вот этим вот ключом и передаете нам обратно, и так мы знаем что вы это вы". Ну понятное дело что TLS это сложно и не нужно.
Впрочем, не зная задачи это беспредметный разговор конечо:)
все же AOP и DI очень облегчают жизнь, т.к. везде, в каждом проекте, каждый день одно и то же
могу даже рассказать прохладную историю, как нам однажды пришлось декомпильнуть (!) чужой огромный .ear, получив 1M строк кода, и успешно исправить и переписать несколько модулей в нем
Если на Яве писал не школьник, а на ПХП - школьник? - давайте все-таки сравнивать сравнимые вещи.
много сталкивался с жалкими потугами ынтерпрайзно засунуть пхп в мир взрослых людей - ну там, написать хотя бы soap-сервис/клиент (я уж не говорю к шине подключиться)
почему-то постоянно с этим только проблемы и недели отладки взаимодействия систем
насчет школьник-нешкольник, в джаве всё приспособлено для того, чтобы неправильно было бы написать сложнее, чем правильно
встаешь в колею и никуда с нее не сходишь
в пхп же никаких норм, сам язык не может соответствовать одному стилю, и с низким порогом вхождения даже "проффессионалы" с опытом 10 лет за плечами настолько избалованы, что не могут сделать нормальный проект, который будет поддерживаться не ими
Более того, допилить Дженкинс или Селениум до нужного состояния гораздо сложнее, чем тот же Вордпресс.
1) типизирован
2) иметь нормальную архитектуру.
3) Использовать нормальные библиотеки
4) Юзать нормальную стандартную библиотеку
Все четыре пункта для PHP не верны
Типизорованость делает код более часто более сложным (и чем больше типизированости, тем более сложным) в поддержке, так что это скорее минус, чем плюс.
Ява как-то влияет на нормальность библиотек? Чет я не замечал.
В Яве нормальная стандартная библиотека? Та ну, даже большие любители Явы используют всякие Апачи / ЕЕ / Гуяву напильники чтобы работать со стандартной библиотекой.
По сравнению с пыхой? Да.
Разные её куски по-разному. Т.к. писалось в разное время и совершенно разными людьми.
concurrency близок к гениальности. коллекции из util в принципе хороши. старые даты - говно. новые - удобно, итд.
Да это нормально для json'а. Я точно не помню, но возможно спека требует такую запись чтобы избежать всех проблем с кодировками.
Как типизированный язык с внятной стандартной библиотекой.
>> Я чет такой связи не прослеживаю.
Откройте любой опенсурсный PHP проект и узрейте.
>>Типизорованость делает код более часто более сложным
Типизированность помогает отлавливать ошибки на стадии компиляции, помогает при использовании IDE, и как-то даже странно объяснять что белое это белое. Вот, можете еще Романа спросить: http://govnokod.ru/17154#comment256247 :)
>>Ява как-то влияет на нормальность библиотек? Чет я не замечал.
Да. Сравните, например, спринг и Zend. Сравните стандартную библиотеку PHP и явы.
>>В Яве нормальная стандартная библиотека? Та ну, даже большие любители Явы используют всякие Апач
В то время как большие любители PHP обычно пилят свой класс "Array", причем в каждом проекте заново.
Типизорованость языка не имеет ни прямого, ни даже косвенного отношения к архитектуре приложений. Ну не на столько, чтобы это можно было как-то заметить на практике. Наоборот, когда говорят об архитектуре приложения, то стараются уйти от таких деталей как типы и возможности операций над типами и т.п. конкретике, которой не место в архитектуре. Типы добавляются потом, когда уже архитектура понята, и ее нужно как-то воплощать в жизнь.
Опять же, нужно понимать что такое тип. Иначе высказивания об "отлове ошибок во время компиляции" превращается в пустое выражение. Типы, или, вернее, желание их иметь проистекает от желания формально выразить назначение програмы. Т.е. параллельно с программой написать и доказать теорему гарантирующую правильность написаной програмы. Но, тут же напрашиваются вполне резонные вопросы:
1. А что если мы неправильно доказали теорему?
2. А что если мы доказали не ту теорему?
3. А что если программа, относительно которой доказывалась теорема, не смотря на доказательство не соответствует доказаному?
Я никогда не занимался подсчетом и статистикой связаной с ошибками типов относительно усилий потраченых на типизацию. И, естесственно, мне свойственно помнить только плохое - поэтому мне трудно вспомнить, когда бы типы мне сильно облегчили жизнь / поиск ошибок. Я помню только несуразно сложные ситуации, когда нужно было померить два типа путем написания адаптеров со всякими извращенными кастами и динамическими проверками, абсолютно не нужными для доказательства корректности исходной программы.
В Яве есть *статическая* типизация, а в PHP нет (если не считать некоторых кастылей).
Конечно я не говорил что PHP вообще не типизирован. Он типизирован динамически, а ява -- и статически и динамически.
>>Опять же, нужно понимать что такое тип
Можете на досуге ознакомиться с понятием ADT:)
>>. А что если мы неправильно доказали теорему?
Ну вот опять: "если %FOO% не решает всех проблем, то %FOO% не нужен":)
Не используйте вообще никакие средства разработки и никакие современные языки, ведь все они основаны на каких-то контрактах, а контракт может быть описан неверно.
>>Я никогда не занимался подсчетом и статистикой связаной с >>ошибками типов относительно усилий потраченых на
>>типизацию
Достаточно один раз порефакторить большой проект. Метод переименовать, например.
>>Путем написания адаптеров
Да, это действительно минус. К счастью, в современных языках он часто решен заменой наследования на делегирование (kotlin, например).
Да и отсутствие статической типизации ни коим образом не оправдывает кашу со стандартной библиотекой , типами, отсутствием неймспейсов и модульности и arrayем.
Охх) Вам тоже статью про "фрактал плохого дизайна" показать?)
Я как бы провожу досуг за чтением того же Пирса или Милнера... АДТ - это что-то из книг для начинающих изучать Яву, о нем же и на собеседованиях любят спрашивать. Я не пытаюсь сказать, что это что-то бесполезное, очень даже наоборот, просто это указывает более-менее на степень погружения :)
Нет, аргумент не про то, что не решает все проблемы. Аргумент заключается в том, что он создает дополнительные проблемы, решение которых прямо не связано с решением задачи которую нужно решить. И что правильной стратегией является решение, по возможности, только нужных задач.
Да, я рефакторил большие проекты. И при этом связь от меня все так же ускользает. Самый лучший помощник в этом всегда был grep и тесты... если были. А если приглядется, большая часть рефакторинга в больших проектах была связана с бюрократией типов.
В современных языках? О каких языках позвольте спросить идет речь? Если это случайно Ява, то это язык морально устаревший в зародыше...
Да, я читал когда-то статью про ПХП. И я не утверждаю, что это замечательный язык, я говорю, что Ява - даже если в чем-то и лучше, то эта разница на столько не заметна на общем фоне, что не стоит таких категорических утверждений.
Науке-то (в отличии от Вас) это прекрасно известно.
>>АДТ - это что-то из книг для начинающих изучать Яву
Нет, это Abstract Data Types. Это, кстати, тоже науке известно.
>> Если это случайно Ява, то это язык морально устаревший в зародыше...
Вот это аргумент!
Ладно) Вы или троллите или находитесь в какой-то параллельной реальности, не думаю что стоит продолжать беседу:) Оставляю Вас в мире где статической типизации не существует, проекты рефакторят грепом, пользователи VisualStudio не умеют пользоваться компьютером, а ADT " это что-то из книг для начинающих изучать Яву":)
Да почему. Там абсолютно такая же типизация, как в том же жс.
Почему имея такую возможность почти никто этим не занимается и оставляет вывод типов компилятору (в отличие от МЛ и ему подобных?) - наверное традиция / есть более интересные вещи. Как правило люди пишущие на Лиспе задаются вопросом более точной типизации, если нужно добиться лучшей производительности от програмы, в большинстве случаев точные определения типов (такие как, например, численный диапазон) просто не интересны.
Дейкстра жалуется на очень херовое качество языков представленных на "конкурс" Ironman. Ironman - это проект организованый минобороны США (DoD в документе) для того, чтобы решить какой же язык использовать для embedded систем. У Ironman никогда не было победителей, и спецификацию заменили на Steelman, после чего победила Ада. Что интересно в этом документе, что судя по дате, один из языков-претендетнов был С++.
Два интересных момента: Дейсктра говорит о том, что понятие strongly typed имеет больше отношения к жаргону менеджеров по продажам, чем к программированию, кроме этого он жалуется на то, что в целом программирование скатилось и деградировало, и теперь управляется тупыми менеджерами по продажам.
Дело в том, что с научной точки зрения само выражение "статически типизированый" появилось в книке On Understanding Types, Data Abstraction, and Polymorphism за авторством Луки Кардели и Питера Вегнера (можно ознакомиться тут: http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf ). Они предложили определение, которое говорит следующее: языки, где правильность типов может быть установлена статической программой называются статически типизироваными. В этом смысле ни Ява ни С++ не являютыса статически типизироваными, т.как разрешают "опасные" касты. Более того, нет никаких известных не академических языков, которые бы были действительно статически типизированы в этом смысле. Кроме этого есть понятие статической проверки (близкое, но включающее гораздо больше), которое путают со статической типизацией.
Кроме этого есть еще strongly typed, который сюда до кучи примешали. Это говорит о том, что в языке все типы не противоречивы. Опять же, в Яве это не соблюдается, т.как в ней можно создать типы, которые нельзя скомпилировать изза противоречия, которое возникает у компилятора. Более того, интересные системы типов (по силе выразительности такие же или более выразительные как логика первого порядка) в принципе не могут быть эквивалентны strongly typed языкам.
А клиенты на чем?
>> браузерки
Видимо какой-нибудь вебсокет или комета.
Это логика _на_клиенте_ такая?
А как же любимое всеми BDE? :)
Всё намного хуж