Здравствуйте, Дарней, Вы писали: Д>А если "программист" не пишет код, то это или архитектор, или ПМ. Опять же, совершенно другая профессия. Это только у нас принято валить всех в одну кучу. Если работает с компьютером — значит, программист.
И, по моему скромному опыту, это хорошо. Я насмотрелся в развитой стране на веб-дизайнеров, падающих в обморок от HTML-разметки, программистов, не понимающих разницу между gif и jpeg... Это ж то же самое, что художник по синему цвету. Нормальный разработчик должен быть достаточно разносторонним.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. КДВ>2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.
Вот от такого подхода и возникают чудовищные приложения. Потому что первую часть либо пропускают вовсе, за отсутствием таланта, либо делает человек уже с таким талантом, что хоть стой хоть падай.
В проектировании UI основную роль играют не пикселы, а процесс взаимодействия. Для создания качественного UI достаточно обладать здравым смыслом и основами знаний по когнитивной психологии. Никакого таланта не надо. Талант нужен для того, чтобы создавать художественные произведения — к примеру, внятный сплэш для визарда ни один программист не изобразит (если он случайно не художник). А вот от UI для приложения художников лучше держать подальше — они имеют очень слабое представление о восприятии динамических структур. Кроме того, художнику очень сложно объяснить суть процесса взаимодействия пользователя с системой, поэтому он связан той структурой UI, которую ему подсунули для раскрашивания. А никакое раскрашивание не спасет UI, в котором нужно звонить абоненту при помощи бросания его иконки на иконку телефона, расположенную на другой закладке.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Дарней, Вы писали:
Д>молодец, возьми с полки пирожок А теперь еще посмотри в энциклопедии, с какого века ведет своё происхождение понятие "алгоритм"
Да, я молодец. Спасибо, я знаю
С какого века... хм... Я помню когда наш преподаватель в институте сказал: "Нужно изучать программирование с самых основ"... после чего я застал моего соседа по общаге увлеченно читающего книгу с названием на обложке "Основы мироздания"... И он был чертовски прав!
А другой преподаватель однажды сказал другое:
"Я не буду учть вас программировать на IBM PC (тогда это было новое и модное)... или на С++ (тогда это тоже было ново и модно для нас)... я попробую научить вас программировать... а что и на чем, станок с ЧПУ, супер-кпьютер, процесс или коллектив — для вас уже не будет иметь значение..."
Здравствуйте, Sinclair, Вы писали:
КДВ>>Фигня. Программирование ГУЯ делится на две части. 1-я художественная. Тут нужен талант. КДВ>>2-я — воплотить. Чисто ремесленная задача. И то, что этим обычно занимается один человек ничего не меняет. Причем большую часть времени именно приходится двигать на пиксел кнопки. Тупо.
S>Вот от такого подхода и возникают чудовищные приложения. Потому что первую часть либо пропускают вовсе, за отсутствием таланта, либо делает человек уже с таким талантом, что хоть стой хоть падай. S>В проектировании UI основную роль играют не пикселы, а процесс взаимодействия. Для создания качественного UI достаточно обладать здравым смыслом и основами знаний по когнитивной психологии. Никакого таланта не надо. Талант нужен для того, чтобы создавать художественные произведения — к примеру, внятный сплэш для визарда ни один программист не изобразит (если он случайно не художник). А вот от UI для приложения художников лучше держать подальше — они имеют очень слабое представление о восприятии динамических структур. Кроме того, художнику очень сложно объяснить суть процесса взаимодействия пользователя с системой, поэтому он связан той структурой UI, которую ему подсунули для раскрашивания. А никакое раскрашивание не спасет UI, в котором нужно звонить абоненту при помощи бросания его иконки на иконку телефона, расположенную на другой закладке.
Наверное мы говорим про разные вещи. Есть ведь разные проекты. Есть и бизнес-приложения, где форм многие сотни (100), есть и что-то вроде РСДН-хоме, где форм конечно количество, а времени для разработки очень много (сколько лет уже эту штуку полируют?). И есть еще много разных сегментов рынка. Ты про какой? Я лично про бизнес-приклады говорил. И я за свои слова отвечаю. Чесс слово. Наверное мы просто не все договариваем, поэтому и не понимаем друг друга.
Кстати, про художников. Мой очень хороший знакомый занимался одно время тем, что писал на Вижуал Васике написанием софта для обучения (металлургический комбинат). Причем не надо придираться к средству, разработчкик он прекрасный. Ну так про художников. Там одна тетка была, которая рисовала. Только рисовала. На фотошопе. Другая — программист на вспоможении, и он — всю анимацию анимировал. Так вот, без художника получалось просто на порядок хуже. Я сам видел, что ТАК не художник не сделает.
Тот же ГУЙ в микрософт-офисе кто проектирует? Программисты? Или ГУЙ винды? Так что в этом ты по-моему не прав.
Здравствуйте, Oyster, Вы писали:
O>Жаль, что нет хороших инструментов рефакторинга для C++. Тогда, я думаю, ты бы оценил ту на самом деле небольшую помощь, которую они оказывают простому программисту. А со временем, возможно, не смог бы и жить без рефакторинга, как и все мы, закабалённые решарпером
O>Ведь неужели тебе никогда не приходилось выделять метод? Или переименовывать переменную? Или, скажем, менять название класса? Пусть эти операции составляют 1% твоей работы — почему бы не автоматизировать этот процент и не освободить свой мозг и свои руки для более благородных дел?
С этим то никто и не спорит.
Просто "хороших инструментов рефакторинга для C++" нет далеко не случайно.
В C# для авторефакторинга пришлось специально кое в чем ограничить язык. Стоило оно того или нет — уже вопрос.
Сам понимаешь, если речь действительно об 1% и если этот выигрышь единственный — однозначно нет.
Другое дело, что на мой взгляд авторефакторинг не единственный выигрышь, однако кричат-то именно о нем, что смешно.
Здравствуйте, EXO, Вы писали:
EXO>С этим то никто и не спорит. EXO>Просто "хороших инструментов рефакторинга для C++" нет далеко не случайно. EXO>В C# для авторефакторинга пришлось специально кое в чем ограничить язык. Стоило оно того или нет — уже вопрос.
Вот тут не соглашусь с утверждением — не вижу, откуда оно следует. Да и не чувствую я ущербности языка C#. Они боролись за строгую типизацию — это да — но хорошая поддержка рефакторинга вряд ли была приоритетом №1.
EXO>Сам понимаешь, если речь действительно об 1% и если этот выигрышь единственный — однозначно нет.
Да не ограничивали C# ради рефакторинга!
EXO>Другое дело, что на мой взгляд авторефакторинг не единственный выигрышь, однако кричат-то именно о нем, что смешно.
Никто именно о нём не кричит. Просто именно у этого топика именно такая тема.
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>Не придирайся к фразе.
КДВ>Ясно сказано, что кодирования часть процесса разработки (программирования). Если брать только кодирование, то да, можно ожидать существенной экономии времени. Но кодирование занимает небольшой процент времени от разработки в целом. Так что если ты ускоришь кодирование в 2 раза, то это не значит, что ты сможешь ускорить разработку в целом хотя бы на 10%. Вот так вот.
Но если я ускорю разработку хотя бы на 5% и совершенно бесплатно для меня как для конечного пользователя IDE — то почему бы и нет?
КДВ>А это уже НИОКР. Кстати. Интереснейшее занятие.
Тут не понял. Это некий синоним слова "флейм", надо полагать?
Здравствуйте, Sinclair, Вы писали:
S>И, по моему скромному опыту, это хорошо. Я насмотрелся в развитой стране на веб-дизайнеров, падающих в обморок от HTML-разметки, программистов, не понимающих разницу между gif и jpeg... Это ж то же самое, что художник по синему цвету. Нормальный разработчик должен быть достаточно разносторонним.
специализация все равно должна быть. Потому что если за какую-то часть задачи отвечают "все" — это значит, что за нее не отвечает никто. И окажется потом, что предположения одного проектировщика не совпадают с предположениями другого, и программа в целом ковыляет на костылях вместо того, чтобы бегать.
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>Тот же ГУЙ в микрософт-офисе кто проектирует? Программисты? Или ГУЙ винды? Так что в этом ты по-моему не прав.
Его проектируют специалисты по юзабилити, но никак не художники. Кстати, эти специалисты всегда находятся как минимум в тесном контакте с разработчиками и продакт-менеджерами, т.к. при разработке UI приходится учитывать особенности работы и реализации приложения. Например, кое-какие задумки юзабилистов просто нереально заимплементить с точки зрения производительности приложения, а другие из них могут идти вразрез с use cases, разработаными product management department-ом (разработанными не на голом месте, а как результат тесного общения с заказчиком).
Здравствуйте, Дарней, Вы писали:
Д>мне конечно дико жаль. Но когда меня вдруг начинают априори называть низкоквалифицированным работником, то я от этого слегка зверею.
По-моему ты конкретно преувеличиваешь. Тут Влада нет пока, все корректно. Хотя, уходим в сторону. А про "кодер — программист" я сказал в другой ветке.
Здравствуйте, Кузнецов Денис Викторович, Вы писали:
КДВ>Это очень примитивный взгляд на программирование. Да, действительно, если у нас есть 10 программистов, то для того, чтобы архитектура изделия не разъехалась нужен кто-то, кто будет координировать. Ты знаешь, тут недавно сравнили понятие "программист" с понятием "врач". Ты наверняка читал. Так оно и есть. И есть микропроектирование. Это твои слова. А это подразумевает уже гораздо более широкую область знаний, чем кодирование.
а я и не говорил, что "только пишет код". Я сказал "бОльшую часть времени пишет код"
А если человек бОльшую часть времени код не пишет, а (к примеру) руководит другими, то это явно уже другая профессия
Здравствуйте, Oyster, Вы писали:
O>Но если я ускорю разработку хотя бы на 5% и совершенно бесплатно для меня как для конечного пользователя IDE — то почему бы и нет?
Тут скорее психология. Уж больно приятно, когда среда умная (умнее, чем предыдушие). Но это на мой взгляд. Да, кстати, сам пользуюсь, балдею, но отдаю себе отчет, что реально пользы помимо моих эмоций немного.
КДВ>>А это уже НИОКР. Кстати. Интереснейшее занятие.
O>Тут не понял. Это некий синоним слова "флейм", надо полагать?
Здравствуйте, Oyster, Вы писали:
O>Ещё не надо путать разработку UI с рисованием иконок. Вторым занимаются таки художники, а вот первым — товарищи, описанные мной в предыдущем посте.
А я не про иконки. Я просто рассказал о том, что видел сам своими глазами. Да, действительно, художник должен работать в тесном контакте с программистами, спецами по юзабельности и т.д. и т.п. Но все-таки. Без художника никуда. Точнее результат будет не тот. Красоты не будет. Правда не везде она нужна, но это уже другая тема.
Здравствуйте, Дарней, Вы писали:
КДВ>>Это очень примитивный взгляд на программирование. Да, действительно, если у нас есть 10 программистов, то для того, чтобы архитектура изделия не разъехалась нужен кто-то, кто будет координировать. Ты знаешь, тут недавно сравнили понятие "программист" с понятием "врач". Ты наверняка читал. Так оно и есть. И есть микропроектирование. Это твои слова. А это подразумевает уже гораздо более широкую область знаний, чем кодирование.
Д>а я и не говорил, что "только пишет код". Я сказал "бОльшую часть времени пишет код" Д>А если человек бОльшую часть времени код не пишет, а (к примеру) руководит другими, то это явно уже другая профессия
А где ты видал, чтобы большую часть времени писали код? То есть непосредственно шмякали на кнопки на клаве????? Может быть ты хотел сказать, что писать код, это значит и продумывать его структуру, и на бумажке что-то рисовать и... многое другое? Я все-таки не про руководство писал, а про разработку непосредственно (т.е. программирование).
Здравствуйте, denis_krg, Вы писали:
O>>Но если я ускорю разработку хотя бы на 5% и совершенно бесплатно для меня как для конечного пользователя IDE — то почему бы и нет?
_>Тут скорее психология. Уж больно приятно, когда среда умная (умнее, чем предыдушие). Но это на мой взгляд. Да, кстати, сам пользуюсь, балдею, но отдаю себе отчет, что реально пользы помимо моих эмоций немного.
А я без рефакторинга уже как без рук. Если пересаживаюсь на студию без решарпера — становится неудобно. Так что реальная польза есть. Имхо.
КДВ>>>А это уже НИОКР. Кстати. Интереснейшее занятие.
O>>Тут не понял. Это некий синоним слова "флейм", надо полагать?
_>Шутник. Погугли ))))
Здравствуйте, Oyster, Вы писали: O>Вот тут не соглашусь с утверждением — не вижу, откуда оно следует. Да и не чувствую я ущербности языка C#. Они боролись за строгую типизацию — это да — но хорошая поддержка рефакторинга вряд ли была приоритетом №1.
Я тоже не считаю, что это было певым приоритетом. И смоти ниже на слова: "если этот выигрышь единственный".
А ради авторефакторинга (по заявлениям самого микософт) было убрано разделение на cpp и h файлы, например.
EXO>>Сам понимаешь, если речь действительно об 1% и если этот выигрышь единственный — однозначно нет. EXO>>Другое дело, что на мой взгляд авторефакторинг не единственный выигрышь, однако кричат-то именно о нем, что смешно.
O>Никто именно о нём не кричит. Просто именно у этого топика именно такая тема.
ну тогда нет возражений.
По моему никто не спорит, что наличие авторефакторинга лучше, чем его отсутсвие. Разногласия лишь в том, на сколько это существенно.
Здравствуйте, denis_krg, Вы писали:
_>А я не про иконки. Я просто рассказал о том, что видел сам своими глазами. Да, действительно, художник должен работать в тесном контакте с программистами, спецами по юзабельности и т.д. и т.п. Но все-таки. Без художника никуда. Точнее результат будет не тот. Красоты не будет. Правда не везде она нужна, но это уже другая тема.
А я о том, что без юзабилити-специалиста никуда. Без него художник нарисует что-то красивое, но жутко неудобное и никому не нужное. Потому что эталонный художник умеет только рисовать (зато делает это хорошо), а логика организации UI ему как правило чужда.
PS: Да, бывают лица, которые совмещают в себе и талант художника, и талант юзабилити-специалиста. Но пока что я видел только юридические лица такого типа
1.1.4 stable rev. 510
А теперь еще посмотри в энциклопедии, с какого века ведет своё происхождение понятие "алгоритм"
