Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
Я вообще удивляюсь такому разделению, это все равно как в автомобильной отрасли механик презирал бы водителеля и наоборот. в принципе, в той сфере тоже такое имеет место быть, вспомним стеб про "прокладки между рулем и сиденьем" = водитель, но с другой стороны "тот не водитель, кто под машиной не лежал", и в нашей стране это особо актуально. Малореально быть механиком и не быть водителем (я лично ни одного автослесаря не знаю не умеющего водить машину), точно так же малореально быть водителем и совсем ничего не знать об устройстве двигателя — хотя бы принципиальную схему, для чего нужен стартер, для чего генератор, а для чего двигатель, все мы представляем, и хотя бы воду залить в бачок омывателя один фиг каждому ездоку придется.
Так к чему это я ? Что профессии эти взаимосвязаны, и профессиональные водилы чаще всего сами ремонтируют свои тачки (за искл. крупного ремонта).
Так почему же столь непонятное разделение на "программистов простеньких сайтов на пхп" и великих гуру, для которых гуй — это западло.
По-моему, без какой-никакой серверной логики не состряпаешь даже "простенькую страничку", если она не статична.
может быть я отстал от жизни и не работал в таких конторах, но я даже не представляю реально, как можно серверную логику разрабатывать вообще без учета ГУЯ и наоборот. Во всех местах, где я работал, приходилось от начала и до конца всю разработку осуществлять самому — и странички рисовать, и логику веб-сервера писать, и контролы, и запросы — хранимые процедуры на сервере БД (ах да простите, большинство здесь это тоже называют "простенькими селектами", пусть они иногда на 80 строчек получались .
И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку. В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
Я не претендую на абсолютную правильность такого подхода и даже не затеваю спор, что важнее — логика или ГУЙ — просто мне, никогда не видевшему другого, интересно узнать — как конкретно может осуществляться это отделение зерен от плевел — то бишь логики от ГУИ... приведите примеры, если кому не лень
29.08.05 20:41: Перенесено модератором из 'О работе' — IT
E>может быть я отстал от жизни и не работал в таких конторах, но я даже не представляю реально, как можно серверную логику разрабатывать вообще без учета ГУЯ и наоборот.
E>И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку. В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
E>Я не претендую на абсолютную правильность такого подхода и даже не затеваю спор, что важнее — логика или ГУЙ — просто мне, никогда не видевшему другого, интересно узнать — как конкретно может осуществляться это отделение зерен от плевел — то бишь логики от ГУИ... приведите примеры, если кому не лень
многоуровневая структура это вам видимо пустой звук?
Потому, что многими считается, что разработка GUI это примитивная работа.
С моей точки зрения — это работа весьма сложная — зачастую гораздо более сложная, чем разработка серверного кода.
Кроме того, за подобным отношением многие скрывают банальное неумение разрабатывать этот самый GUI. Легко выглядить профессионалом в глазах заказчика, когда ты делаешь то, в чём он не разбирается. И очень сложно — когда рисуешь формы и экраны, смысл которых ему хорошо виден
E>может быть я отстал от жизни и не работал в таких конторах, но я даже не представляю реально, как можно серверную логику разрабатывать вообще без учета ГУЯ и наоборот.
СУБД. Нет там гуя и быть не может (ибо нафиг не нужен). Серверу вообще побарабану, есть где-то гуй, али нет его.
А не любят его — потому-что это скучно. Локализацией заниматься — тоже занятие малоприятное.
Народ все больше творчество любит, относится к професии как к призванию.
P>многоуровневая структура это вам видимо пустой звук?
вот именно что звук — ибо как ПОЛНОСТЬЮ изолировать все уровни, я реально плохо представляю...
Дело в том, что реализация каждого уровня абстракции всегда порождает нагромождение интерфейсов их взаимодействия — и что это целесообразно в большинстве реальных проектов — я сильно сомневаюсь. Как собственно и показывает практика.
Здравствуйте, egaron, Вы писали:
P>>многоуровневая структура это вам видимо пустой звук?
E>вот именно что звук — ибо как ПОЛНОСТЬЮ изолировать все уровни, я реально плохо представляю...
E>Дело в том, что реализация каждого уровня абстракции всегда порождает нагромождение интерфейсов их взаимодействия — и что это целесообразно в большинстве реальных проектов — я сильно сомневаюсь. Как собственно и показывает практика.
для функционирования и кодирования это действительно минус, но он более чем окупается при одновременной работе нескольких человек над разными уровнямии,при поддержке проекта и дальнейших апдейтах. Естественно что если проект на одного и дальнейшей поддержки не планируется, то делать многоуровневость и абстрагировать уровни=зря тратить время.
g_i>СУБД. Нет там гуя и быть не может (ибо нафиг не нужен). Серверу вообще побарабану, есть где-то гуй, али нет его.
Это безусловно так, если в рамках одного проекта, если логику БД разрабатывают абсолютно изолировано от остальных частей приложения.
Но тогда усложняется взаимодействие в команде — в случае полного цикла разработки я взял да написал запрос к БД или процедурку, если она мне понадобилась, а в случае изолированного должен точно и формализованно изложить программисту БД, что должно быть на вх. и что на выходе. что безусловно приводит к дополнительному уровню абстракции. В некоторых проектах это безусловно целесообразно и используется, тут все индивидуально для каждого конкретного случая.
Другое дело — кидайте в меня камнями и помидорами, но я все равно не понимаю, как можно отделить рисование от обработки этого самого рисования !
Здравствуйте, g_i, Вы писали:
g_i>А не любят его — потому-что это скучно. Локализацией заниматься — тоже занятие малоприятное. g_i>Народ все больше творчество любит, относится к професии как к призванию.
Не согласен с Вами. Очень многое зависит от уровня сложности разрабатываемой системы.
GUI позволяет проявить максимум творчества в реализации системы.
Тут и достаточно сложные вопросы проектирования(взять хотя бы стандартные паттерны проектирования — многие из них заточены под UI), также интересные вопросы связаны с реализацией Custom Control'ов.
Не важно какую часть системы Вы разрабатываете — UI или ядро системы. Обе эти задачи достаточно сложны и интересны.
E>Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
1. Профессионалы от остальных отличаются прежде всего умеренностью суждений и уважением собеседника.
2. Зачастую под программистами гуя подразумевают людей которые только и способны что кнопки на форме расставлять. Виной тому обилие псевдопрограммистов которые подвигав эти самые кнопки на формах в дельфи/vb6 считают себя гуру.
3. Проектирование GUI с учетом требований по usability весьма непростая работа, специалистов по которой у нас в стране крайне мало, они неплохо оплачиваются, и на то что их обзывают программистами гуя только улыбаются в ответ (имхо).
Помимо этого:
1. как раз таки хорошо разделять GUI и логику. См. например классический паттерн MVC.
2. server-side программисты как правило не умеют проектировать GUI. К слову большинство desktop разработчиков — тоже. Для этих целей как я уже говорил должен быть или специальный человек или этот навык должен отдельно тренироваться чтением соответствующих книжек и форумов.
3. Программировать для некоторых GUI "западло", потому что сама по себе задача раскидать контролы по форме тривиальна и поэтому неинтересна. Впрочем в лексиконе профессионала слово "западло" не должно встречаться. К таким задачам следует относится следующим образом: Если менеджер хочет стрелять из пушки по воробьям — это его право.
Здравствуйте, egaron, Вы писали:
... E>И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку.
Зато, скажем, облегчит перевод на другой гуй. Взаимодействие с пользователем нужно отделять от логики — ибо пользователем может быть не только живой юзер, а скажем другая система (например, генерации отчетов).
> В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
Это практикуется в основном в небольших по численности проектах, ввиду недостатка узких специалистов .
В этом есть преимущество — в том, что человек представляет проект в целом — в этом-же и недостаток: сложную систему в одиночку трудно поднять. К тому-же быть специалистом во всем — не просто. К тому-же, есть шанс получить в рамках одной системы разный по стилю гуй.
E>Я не претендую на абсолютную правильность такого подхода и даже не затеваю спор, что важнее — логика или ГУЙ — просто мне, никогда не видевшему другого, интересно узнать — как конкретно может осуществляться это отделение зерен от плевел — то бишь логики от ГУИ... приведите примеры, если кому не лень
Это ты лучше приведи пример, как гуй может жестко зацепить логику. Наверное, для специальных систем, оптимизируемых под какую-то программно-аппаратную платформу (включая АРМ пользователя) это логично.
Даже если гуй где-то завязывается на логику — эту логику надо как-то отделять.
Здравствуйте, egaron, Вы писали:
.. E>Другое дело — кидайте в меня камнями и помидорами, но я все равно не понимаю, как можно отделить рисование от обработки этого самого рисования !
Ивенты от презентационного слоя преобразуются в ивенты и сущности логической модели, обрабатываются, результат возвращается контроллеру приложения который дергает гуй. Чаще всего это происходит на клиенте.
Сервер про гуй не знает.
Здравствуйте, Rand1, Вы писали:
.. R>Не согласен с Вами. Очень многое зависит от уровня сложности разрабатываемой системы. R>GUI позволяет проявить максимум творчества в реализации системы. R>Тут и достаточно сложные вопросы проектирования(взять хотя бы стандартные паттерны проектирования — многие из них заточены под UI), также интересные вопросы связаны с реализацией Custom Control'ов. R>Не важно какую часть системы Вы разрабатываете — UI или ядро системы. Обе эти задачи достаточно сложны и интересны.
Согласен. Но большинству разработчиков гуй все-же неинтересен. Тут нужны некоторые навыки дизайнера что-ли (а еще лучше — задатки, потому-как у нас этому практически не учат). Так-что статистически гуй все-же не любят, народ все больше рвется абстракциями повелевать.
Здравствуйте, egaron, Вы писали:
E>И честно говоря, я плохо представляю себе, как можно начисто отделить взаимодействие с пользователем (то есть ГУЙ) и серверную логику — по-моему (сужу по реальным проектам) это только усложнит разработку. В фирмах , где я работал, даже при разработке в команде одному человеку давали задание на реализацию какой-либо функциональности и , как правило, предполагался полный цикл реализации — и дизайн, и серверная логика, и логика БД.
Усложнение разработки — не аргумент. Главное — чтобы пользователю было просто. К сожалению, мы очень часто встречамся с программами, интерфейс которых написан по принципу "Для того, чтобы понять интерфейс, надо понять, как программа устроена". А пользователю надо понимать не то, как программа устроена, а то, как она облегчит выполнение его каждодневных рутинных задач.
Есть отличная фраза: "Идеальный GUI — это одна кнопка во весь экран, на которой написано "Сделать за меня мою работу"." Более яркой иллюстрации принципа отделения GUI от логики не придумать.
Теперь по сути. GUI писать сложно. Порой очень сложно. А красивый и в то же самое время функциональный и удобный GUI — еще сложнее. К сожалению, устойчивое мнение о том, что GUI — это "простенькое клепание страничек, достойное ПТУшников", складывается именно потому, что делать это хорошо (и проектировать, и реализовывать) умеют очень и очень немногие. Интерфейс подавляющего большинства программ не выдерживает никакой критики. Отсюда и выводы, что "такое можно сделать на коленке за один день".
Повышайте уровень производимого вами GUI до такой степени, чтобы им можно было гордиться, тогда не будет мучительно больно...
Здравствуйте, g_i, Вы писали:
g_i>Это ты лучше приведи пример, как гуй может жестко зацепить логику. Наверное, для специальных систем, оптимизируемых под какую-то программно-аппаратную платформу (включая АРМ пользователя) это логично. g_i>Даже если гуй где-то завязывается на логику — эту логику надо как-то отделять.
Та запросто ... Презренный гуёвщик "накидал простеньких кнопок на формочку". А обработчики к ним кто писать будет — вот тебе и логика ? Я никогда не видел специалистов, которые бы только "кидали кнопки на форму", не имея понятия о связи с их обработкой.
Или та же страничка .aspx Во всех ее контролах — неразрывная связь с серверной разработкой .... Если изолировать а клепании приложений на ASP.Net серверную логику то что получится ? Рисует тот же дизайнер DataGrid (по начальным условиям не имея представлении о его функционировании). И что он нарисует ? Только HeaderText колонок ? и то он должэен предусмотреть, будет это BoundColumn, TemplateColumn и связь с данными, которые он будет туда биндить ....
А затем приходит программер и дописывает в эти колонки имена столбцов, которые будут биндиться из базы, и саму процедуру ? так что ли ? смешно....
А классический ASP или пхп? когда там между тэгами <% %> — сервер, а остальное — чистый хтмл и переплетаются они буквально по несколько раз за строчку ? Да запутаются просто-напросто дизайнер и программер, отдельно это написавши. А клиентский скрипт ?
в общем , никак не представляю себе дизайнера, ВООБЩЕ НИКАК не связанного с программированием. Разве что картинки или иконки нарисовать .... Отделение логики БД от логики приложения все же представить много проще....
Здравствуйте, dingo, Вы писали:
D>Теперь по сути. GUI писать сложно. Порой очень сложно. А красивый и в то же самое время функциональный и удобный GUI — еще сложнее. К сожалению, устойчивое мнение о том, что GUI — это "простенькое клепание страничек, достойное ПТУшников", складывается именно потому, что делать это хорошо (и проектировать, и реализовывать) умеют очень и очень немногие. Интерфейс подавляющего большинства программ не выдерживает никакой критики. Отсюда и выводы, что "такое можно сделать на коленке за один день".
В крупных конторах, есть такая должность как дизайнер GUI. Теперь представьте что он не программист, а художник. Мне пришлось в одном проекте воплощать в жизнь полёт фантазии такого художника (точнее часть полёта). Так вот, я вам вот что скажу, после этого очень уважаю людей которые кодят интерфейс, такого количества проблем я ни в одном проекте не видел и решать их было очень интересно, хотя и трудно.
PS Многие скажут: "Какие проблемы раскидал контролы и свободен!". Но поскольку разум дизайнера не затуманен знаниями библиотек и внешним видом контролов , мне пришлось все контролы кастомными делать да ещё и динамически меняющими свое поведение в ответ на реакции юзера. Я считаю, что программер GUI уважаемая и весьма сложная работа в проекте(нормальном проекте).
Здравствуйте, egaron, Вы писали:
.. E>Та запросто ... Презренный гуёвщик "накидал простеньких кнопок на формочку". А обработчики к ним кто писать будет — вот тебе и логика ?
Это не серверная логика. Это клиентская логика.
E>Или та же страничка .aspx Во всех ее контролах — неразрывная связь с серверной разработкой .... Если изолировать а клепании приложений на ASP.Net серверную логику то что получится ?
"неразрывная связь" — ключевая фраза. Клиент "потребляет" серверную логику, не связанную вообще-то с гуем.
E>А классический ASP или пхп? когда там между тэгами <% %> — сервер, а остальное — чистый хтмл и переплетаются они буквально по несколько раз за строчку ? Да запутаются просто-напросто дизайнер и программер, отдельно это написавши. А клиентский скрипт ?
Не запутаются, если будут следовать четко обозначенному контракту.
E>в общем , никак не представляю себе дизайнера, ВООБЩЕ НИКАК не связанного с программированием. Разве что картинки или иконки нарисовать ....
Я тоже не представляю.
>Отделение логики БД от логики приложения все же представить много проще....
GUI входит в логику клиентской части чаще всего все-таки.
Здравствуйте, g_i, Вы писали:
g_i>Согласен. Но большинству разработчиков гуй все-же неинтересен. Тут нужны некоторые навыки дизайнера что-ли (а еще лучше — задатки, потому-как у нас этому практически не учат). Так-что статистически гуй все-же не любят, народ все больше рвется абстракциями повелевать.
Я лет 6 занимаюсь в основном gui, не сказал бы, что там нет абстракций и всего остального, ну может бизнес-логики нет .
из последних приколов, понадобилось нашим манагерам, не стандартно отображать данные, наваяли: почти дерево
Здравствуйте, egaron, Вы писали:
E>Читаю я в постах презрительное мнение о программистах ГУЯ и не совсем понимаю — ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ? Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное.
Есть ГУЙ, а есть Гуйня. Просто потому что куча программистов которые научились в RAD средствах кнопки на формы ставить и показывать в Grid-е содержимое БД, называют свою Гуйню ГУЕм это слово тоже приобрело негативную окраску. Хотя хороший ГУЙ сделать это сложная работа, а придумать еще сложнее(последним впрочем больше стоит заниматься дизайнерам и usability expert-ам)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, merlin.fs, Вы писали:
MF>Я лет 6 занимаюсь в основном gui, не сказал бы, что там нет абстракций и всего остального
С этим я не спорю. Я в общем-то о том, что:
1. гуй — все-таки не серверная часть и бизнес-логика на него не должна быть завязана
Это по вопросу "ужели во всех фирмах программирование ГУЯ начисто отделено от серверного программирования ?"
2. гуем не так интересно заниматься — поэтому его чаще и ругают (ибо заниматься им часто заставляют)
Это по вопросу "Как только ни обзовут нашего брата — и "простенькое клепание страничек, достойное ПТУшников", и вообще ГУЙ — слово ругательное."
Вообще, зря я в этот тред полез. Крик души — штука монологическая.
.
.
