![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
(no subject)
Прочитал про "младшего брата" слова RTFM, STFW. Забавно. Кстати, чудесный текст.
Мне сказали, что корпоративные информсистемы на .NET пока что не особо успешны, и это из-за отсутствия хорошего аппсервера. Интересно, почему так? И зачем обязательно сервер приложений?
Не боясь показать чайниковую сущность, спрошу: почему вообще важен аппсервер? Скажем так: это же фреймворк. Если не делать inversion of control, а добиться тех же функций от библиотеки, скажем, персистенции от Hibernate-а-не-EJB, IPC от CORBA-а-не-SOAP, и так далее - то серверный процесс будет сам себе application server, вернее, сервером бизнес логики.
Пошёл учиться, учиться и учиться, как завещал Ленин. И делать STFW.
Мне сказали, что корпоративные информсистемы на .NET пока что не особо успешны, и это из-за отсутствия хорошего аппсервера. Интересно, почему так? И зачем обязательно сервер приложений?
Не боясь показать чайниковую сущность, спрошу: почему вообще важен аппсервер? Скажем так: это же фреймворк. Если не делать inversion of control, а добиться тех же функций от библиотеки, скажем, персистенции от Hibernate-а-не-EJB, IPC от CORBA-а-не-SOAP, и так далее - то серверный процесс будет сам себе application server, вернее, сервером бизнес логики.
Пошёл учиться, учиться и учиться, как завещал Ленин. И делать STFW.
no subject
> А ещё мне кажется, что в этой ветке ты обсуждаешь вопрос вкуса.
Я говорю о том что даже без учёта психологических факторов, факторов наличия\отсудствия инструментария и т.д., успешность проэкта зависит, очень сильно зависит от выбранной парадигмы. А поэтому я не могу сказать что "я уже знаю достаточно парадигм, что-бы использовать любую для любого проэкта".
no subject
Именно поэтому часто выбор средств разработки определяется имеющимися в наличии разработчиками.
Вообще успех проекта зависит в конечном итоге от квалификации исполнителей и управленцев. А "неправильная платформа/парадигма" - это из серии анекдота про плохого танцора.
no subject
no subject
no subject
no subject
no subject
А почему тогда в своё время когда мы все были процедурными ООП приобрело такую популярность? Несмотря даже на то что ООП программистов и инструментов было мало. Просто реклама?
no subject
no subject
Я не был процедурным :) Я родился с предустановленным Turbo Pascal 5.5
ООП было модным. ООП было новаторским. Оно было очередной серебряной пулей, и и заказкики, и разработчики стремились побыстрее пощупать его в действии. Движение сопротивления объектно-ориентированному подходу выдвигало как раз мой аргумент из первого абзаца.
Многие команды шли по второму пути, отодвигали сроки сдачи, но получали возможность опробовать новое средство на практике. Многие разработчики инструментов разрабатывали ОО-инструментарий, надеясь завоевать рынок.
Иначе говоря, сейчас мы видим море литературы и исследований по ОО-методологии. А тогда все были ньюбами, включая скажем Страуструпа - он в ранних изданиях книг по изобретенному им С++ писал всякую чушь. И мы можем объективно заявить что, зная теперь все преимущества и недостатки ОО и структурного подхода, мы не наступим на старые грабли и сделаем хорошо при любом подходе.
По поводу ажиотажа - вспомните, скажем, ажиотаж вокруг UML и моделирования. Вспомните ажиотаж вокруг Java. Подумайте о сегодняшнем ажиотаже вокруг виртуальных языковых машин, "безопасных языков" и generic programming.
Серебряной пули нет - перечитайте Брукса с Йордоном.
no subject
no subject
no subject
Если оторвать проект от низменных желаний заказчика, руководства, от команды которая его будет делать, от квалификации администраторов, которые будут устанавливать систему, от квалификации и привычек архитекторов, менеджеров и кодеров, ну и так далее - то я согласен с тем, что существует некие оптимальные парадигма, платформа, язык и так далее.
Но в реальности разница настолько мала, что в 90% проектов её перевешивают какие-либо внешние причины, и проект делается на том что придется.
Я не говорю про архитектуру - архитектуру можно проектировать используя хоть все парадигмы сразу. Но после того как построена Design Model - реализовывать ее можно совершенно на любом языке в любом стиле (ОО, структурный или функциональный).
В этом смысле конечный язык в который будет транслироваться дизайн остается на выбор разработчиков и руководства, и они выбирают язык исходя из собственных предпочтений и субъективных суждений.
Иначе говоря, я утверждаю, что концепция парадигмы не применима к абстрактному графу высокоуровневой архитектуры. А низкоуровневая архитектура (реализация высокоуровневой) может быть реализована в терминах функций, классов или модулей с примерно равными трудозатратами в каждом случае. Трудозатраты на воплощение дизайна определяются навыками разработчиков и степенью знакомства их с технологией, а вовсе не выбором низкоуровневого подхода.
+1
no subject
Я бы еще добавил что в очень многих случаях(которые я наблюдал) выбор правильной метафоры проекта гораздо важнее выбора "платформа/парадигма".