дотнет-срач
Jan. 27th, 2010 09:22 am.NET и Co - это не мейнстрим, это помойка для однодневных приложений
Сразу скажу, я на дотнете пишу уже года 4 и он меня задолбал весьма серьезно. Но тем не менее, альтернативы в моем случае (опердень с GUI, разрабатываемая в условиях адских ограничений по времени и ресурсам) тупо нет.
Основная причина, конечно, в том, что у меня на нем уже сделано 2/3 любого проекта типа "бд->аппсервер->gui-клиент", на любой другой платформе это все придется делать с нуля.
Но, кроме этого, в других платформах и языках, по-моему, такие задачи вообще не рассматриваются, как класс. Т.е. если GUI - то сделанный вручную, зашит в ресурсы, формы делаются по принципу "один студент-одна неделя-одна форма". А то и вообще GUI никто не рассматривает, потому что язык предназначен для веб- и прочих серверов. Очевидно же, что если основная целевая аудитория - веб-разработчики, то для серьезного GUI это использовать будет невозможно - даже если есть биндинги к GUI-тулкитам, они будут баговые и недоделанные и придется все время тратить на их допиливание. (Хотя, по правде сказать, в дотнете все точно так же - гуй там приходится допиливать постоянно).
Подумал я использовать жабу, для аппсервера. На словах все выглядит красиво - Hibernate, Spring итд итп. На практике, мне придется неделю сидеть только настраивать eclipse, jdk, jetty или томкаты, ant и мавены какие, разбираться как это все интегрировать, как сделать инфраструктуру для разработки. А потом опять с нуля делать все, что у меня уже сделано на ASP.NET (конфигурируемая миддлварь для произвольных баз данных, выставляющая CRUD операции в виде restful сервиса)
zabivator там по ссылку пропагандирует линукс, емаксы, билд из командной строки, итд. Я серьезно не понимаю, как можно в таком стиле быстро разрабатывать проекты. Т.е., я даже согласен признать, что я тупой, что у меня мозг сломан 15 годами быдлоразработки на дельфи, но я не понимаю, как проект НАЧАТЬ.
Когда приходишь уже на готовое - более менее понятно, скачал исходники, configure/make/install и понеслась. Я понимаю, что это закрывает 99% современного IT, когда народ приходит на проекты, которые делаются 10 до того, и будут делаться 10 лет после, получает инструкции "как включиться в работу", все им настраивается/деплоится с образом специально назначенными гуру-админами и все.
Но у меня обычно все не так. Стандартная ситуация "нужно с нуля сделать совершенно новый проект, нужно выбрать для него платформу так, чтобы не сойти с ума, чтобы по максимуму повторно использовать прошлые наработки, итд".
И обычно это выглядит примерно так: 20-50-100 сущностей предметной области, в лучшем случае их можно оформить в виде независимых редакторов, в худшем - они связаны в сложный адский workflow который нужно контролировать, чтобы юзера в дебри не убрели, разработчиков - 1-2 человека, времени - 2 месяца, причем каждый день будут регулярно отвлекать по мелочам, старым проектам и прочей хрени минимум 2-3 раза. Но зато почти нет оверхеда на коммуникацию, на сбор требований (требования уже известны, т.к. я предметку знаю лучше всех спецов клиетов вместе взятых). Тестирование софта обычно требуется по минимуму, т.к. изначально правильная архитектура не допускает множество тупых багов, а вот с документированием - абзац. Т.е. либо документирование, либо сделать проект вовремя.
Сразу скажу, я на дотнете пишу уже года 4 и он меня задолбал весьма серьезно. Но тем не менее, альтернативы в моем случае (опердень с GUI, разрабатываемая в условиях адских ограничений по времени и ресурсам) тупо нет.
Основная причина, конечно, в том, что у меня на нем уже сделано 2/3 любого проекта типа "бд->аппсервер->gui-клиент", на любой другой платформе это все придется делать с нуля.
Но, кроме этого, в других платформах и языках, по-моему, такие задачи вообще не рассматриваются, как класс. Т.е. если GUI - то сделанный вручную, зашит в ресурсы, формы делаются по принципу "один студент-одна неделя-одна форма". А то и вообще GUI никто не рассматривает, потому что язык предназначен для веб- и прочих серверов. Очевидно же, что если основная целевая аудитория - веб-разработчики, то для серьезного GUI это использовать будет невозможно - даже если есть биндинги к GUI-тулкитам, они будут баговые и недоделанные и придется все время тратить на их допиливание. (Хотя, по правде сказать, в дотнете все точно так же - гуй там приходится допиливать постоянно).
Подумал я использовать жабу, для аппсервера. На словах все выглядит красиво - Hibernate, Spring итд итп. На практике, мне придется неделю сидеть только настраивать eclipse, jdk, jetty или томкаты, ant и мавены какие, разбираться как это все интегрировать, как сделать инфраструктуру для разработки. А потом опять с нуля делать все, что у меня уже сделано на ASP.NET (конфигурируемая миддлварь для произвольных баз данных, выставляющая CRUD операции в виде restful сервиса)
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
Когда приходишь уже на готовое - более менее понятно, скачал исходники, configure/make/install и понеслась. Я понимаю, что это закрывает 99% современного IT, когда народ приходит на проекты, которые делаются 10 до того, и будут делаться 10 лет после, получает инструкции "как включиться в работу", все им настраивается/деплоится с образом специально назначенными гуру-админами и все.
Но у меня обычно все не так. Стандартная ситуация "нужно с нуля сделать совершенно новый проект, нужно выбрать для него платформу так, чтобы не сойти с ума, чтобы по максимуму повторно использовать прошлые наработки, итд".
И обычно это выглядит примерно так: 20-50-100 сущностей предметной области, в лучшем случае их можно оформить в виде независимых редакторов, в худшем - они связаны в сложный адский workflow который нужно контролировать, чтобы юзера в дебри не убрели, разработчиков - 1-2 человека, времени - 2 месяца, причем каждый день будут регулярно отвлекать по мелочам, старым проектам и прочей хрени минимум 2-3 раза. Но зато почти нет оверхеда на коммуникацию, на сбор требований (требования уже известны, т.к. я предметку знаю лучше всех спецов клиетов вместе взятых). Тестирование софта обычно требуется по минимуму, т.к. изначально правильная архитектура не допускает множество тупых багов, а вот с документированием - абзац. Т.е. либо документирование, либо сделать проект вовремя.