Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 90
>> на мой взгляд, хорошая программа - это прежде всего программа, которой пользуются длительное время.
сколько лет сидят девочки в сбербанке за своими терминальными программами? (этому софту от роду 15+ лет. только сейчас им сменили софт на что-то гуёшно-виндовое)
вы видели софт, на котором бегает поддержка телефонной сети целой страны? а я вот видел... такая мегоацкая жесть... (;
длительный срок использования софта скорее показывает не его крутость, а то, что фирма имеет ОГРОМНОЕ количество "унаследованных ресурсов". смена софта на более внятный потребует сумасшедших денег на переобучение десятка тысяч пользователей, обновления железа и внесения изменений в рабочий процесс чтоб он лучше подходил под новый софт...
так что "длительный срок использования" не есть хороший показатель... он срабатывает только для мелочей (типа qip'а или скажем far'а).
хотя и тут есть элемент "наследства". я знаю человека который до сих пор сидит в icq2003b просто потому, что он неимоверно к ней привык... и скорей всего найдётся ещё несколько тысяч подобных пользователей.
получается icq2003b - хорошая прогамма написанная хорошими программистами? (;
сколько лет сидят девочки в сбербанке за своими терминальными программами? (этому софту от роду 15+ лет. только сейчас им сменили софт на что-то гуёшно-виндовое)
вы видели софт, на котором бегает поддержка телефонной сети целой страны? а я вот видел... такая мегоацкая жесть... (;
длительный срок использования софта скорее показывает не его крутость, а то, что фирма имеет ОГРОМНОЕ количество "унаследованных ресурсов". смена софта на более внятный потребует сумасшедших денег на переобучение десятка тысяч пользователей, обновления железа и внесения изменений в рабочий процесс чтоб он лучше подходил под новый софт...
так что "длительный срок использования" не есть хороший показатель... он срабатывает только для мелочей (типа qip'а или скажем far'а).
хотя и тут есть элемент "наследства". я знаю человека который до сих пор сидит в icq2003b просто потому, что он неимоверно к ней привык... и скорей всего найдётся ещё несколько тысяч подобных пользователей.
получается icq2003b - хорошая прогамма написанная хорошими программистами? (;
>> длительный срок использования софта скорее показывает не его крутость, а то, что фирма имеет ОГРОМНОЕ количество...
эх, не лучшим оброзом мысль оформил - надо было вставить "абстрактного пользователя" - как отдельного человека, так и громадную корпорацию... (теперь стало понятнее? :)
эх, не лучшим оброзом мысль оформил - надо было вставить "абстрактного пользователя" - как отдельного человека, так и громадную корпорацию... (теперь стало понятнее? :)
Для громадной корпорации это вообще неверно ни разу: в 9 случаях из 10 человек, принимающий решение об использовании программы сам ею пользоваться не будет. Соответственно её "хорошесть" отходит на задний план, а на переднем оказываются отношения с фирмой-поставщиком, репутация поставщика, советы знакомых (которые тоже не работают с этой программой), в Росиии - размер откатов. Всё что угодно кроме качества самой программы...
так вот. в свете всего сказанного мной и вами - как можно пользоваться критерием "с этой программой уже Y лет успешно работает X человек"?
если абстрагироваться от "корпоративных стандартов" и "откатов", то опять же не работает сей критерий. получается, что любая программа хороша. у любого софта есть фанаты. даже у самого недружелюбного к пользователю.
если абстрагироваться от "корпоративных стандартов" и "откатов", то опять же не работает сей критерий. получается, что любая программа хороша. у любого софта есть фанаты. даже у самого недружелюбного к пользователю.
Для корпорации пользователем программы является не конкретный человек, а корпорация. И пока корпорацию в лице ее руководства устраивает программа, то ею пользуются сотрудники корпорации. Бизнес-приложения (типа ERP систем), например, никогда не пишутся для рядовых "пользователей". И их желания, строго говоря, интересуют разработчиков в последнюю очередь.
Этот подход работает только если человек волен сам выбирать чем им пользоваться. Если у вас "корпоративный стандарт" - это Visual Studio или Idea, то Emacs остаётся не у дел - независимо от его плохости или хорошести. Если есть выбор - будет пользователи Emacs'а (у нас на фирме есть). Ну и привычка, конечно, большое дело...
сколько лет сидят девочки в сбербанке за своими терминальными программами? (этому софту от роду 15+ лет. только сейчас им сменили софт на что-то гуёшно-виндовое)
Я вот сильно не уверен, что "гуешно-виндовое" лучше терминальной программы, только потому что оно "гуешно-виндовое". Сама же по себе "виндовость" не добавляет к программе никакой дополнительной ценности.
получается icq2003b - хорошая программа написанная хорошими программистами?
не вижу причин не считать icq2003b хорошей программой.
я не к тому, что "Ура! у них геёвый софт теперь!", а к тому, что просто произошла подвижка. что устали от старого софта и решили его сменить. (или просто хороший откат на распил попался... :)
вы совершенно в праве считать icq2003b хорошей программой. более того - вы даже будете правы!
а я так сказать не могу.
...
это всё субъективно... и даже когда вы оцениваете код программы, её внутренний скелет, красоту алгоритмов и всего такого - опять же оценка субъективна...
вы совершенно в праве считать icq2003b хорошей программой. более того - вы даже будете правы!
а я так сказать не могу.
...
это всё субъективно... и даже когда вы оцениваете код программы, её внутренний скелет, красоту алгоритмов и всего такого - опять же оценка субъективна...
Ну, не нужно же смотреть на все глазами программиста! Для того чтобы оценить программу, СОВСЕМ не обязательно "оценивать код программы, ее внутренний скелет, красоту алгоритмов и всего такого" - это всё ВООБЩЕ не имеет никакого значения для пользователя программы, для которого собственно программы и пишутся!
Повторюсь, если программой пользуются длительное время и не находят достаточных оснований для замены - то программу смело можно считать хорошей
Повторюсь, если программой пользуются длительное время и не находят достаточных оснований для замены - то программу смело можно считать хорошей
(покосившись на статистику использования броузеров) видимо я уже сильно испорченный человек и у меня своё понятие о "хорошей программе" и "хороших программистах". (%
Ещё раз: в ОЧЕНЬ большом числе случаев на выбор программы влияют внешние факторы. Те, кто с ней работают могут плеваться, писать кипятком и вообще быть страшно недовольны, но будут пользоваться тем, что есть. Если исходить из ваших критериев, то копейка - не просто классный автомобиль, а вообще супер-пупер-гипер (посетите Кубу и убедитесь).
Да, копейка классный автомобиль (для своего времени уж точно), и то, что видимо на Кубе она популярна, если верить вашим словам, только подтверждает этот факт.
И для того чтобы сделать вывод о том, хорошая программа или нет нужно рассматривать также разные факторы, а не только и даже не столько её техническую безупречность.
И для того чтобы сделать вывод о том, хорошая программа или нет нужно рассматривать также разные факторы, а не только и даже не столько её техническую безупречность.
Извините, но считать что копейка лучше Тойоты - бред. На Кубе она популярна по той простой причине что выбора нет. Зарубежные авто туда не ввозят. С качеством это не связано никаким образом. Та же история с "многолетним использованием программ".
Техническая безупречность - не единственный критерий качества, но уж лучше оценивать техничествую безупречность, чем популярность. Популярность вообще больше от отдела маркетинга зависит, чем от программистов...
Техническая безупречность - не единственный критерий качества, но уж лучше оценивать техничествую безупречность, чем популярность. Популярность вообще больше от отдела маркетинга зависит, чем от программистов...
Покажите, где я утверждал, что копейка лучше Тойоты?
Утверждения "копейка хорошая машина" и "тойота хорошая машина" никак не противоречат друг другу. Существует много хороших программ, также существует много хороших машин. Каждая из них имеет право называться хорошей.
Кстати, а какую из моделей тойоты вы имели ввиду? :))
Утверждения "копейка хорошая машина" и "тойота хорошая машина" никак не противоречат друг другу. Существует много хороших программ, также существует много хороших машин. Каждая из них имеет право называться хорошей.
Кстати, а какую из моделей тойоты вы имели ввиду? :))
Конечно не видите. Вы дали определение хорошей программы и ICQ2003b под него подподает. Но сомнение вызывает именно ваше определение независимо от того хороша icq2003b или нет.
Да, QWERTY-эффекты, издержки переключения...
А скажите, уважаемый, на кой оператору гуй?
У него есть формочка с которой он работает в идеале даже не глядя на экран. Смотрит на экран только для проверки данных. Да терминал "это некрасиво". НО ФУНКЦИОНАЛЬНО!
Вам форточки или ехать?
Так что пример довольно неудачен я думаю.
Если возникнет потребность идентификации заказчика мо "морде лица" и отпечаткам пальцев - тогда гуй оператору потребуется. или когда надо будет чек печатать красивыми буковками.
Типичному клерку в большинстве случаев это лишнее.
Я видел как работают люди на гуевых интерфейсах. В большинстве случаев они просто забывают о наличии клавиши ТАБ бля перехода между полями, хотя замечательно ею пользовались в текстовой форме на терминале!
В итоге ввод информации превращается из оперативной работы в примерно такое:
1.Ткнуть мышом в поле.
2.Бросьть мышь и вколотить текст.
3.перейти к п1
Интерфейс пользователя должен быть ФУНКЦИОНАЛЬНЫМ.
Если надо набивать формочки - на экране должны быть формочки и никаких рюшечек.
У него есть формочка с которой он работает в идеале даже не глядя на экран. Смотрит на экран только для проверки данных. Да терминал "это некрасиво". НО ФУНКЦИОНАЛЬНО!
Вам форточки или ехать?
Так что пример довольно неудачен я думаю.
Если возникнет потребность идентификации заказчика мо "морде лица" и отпечаткам пальцев - тогда гуй оператору потребуется. или когда надо будет чек печатать красивыми буковками.
Типичному клерку в большинстве случаев это лишнее.
Я видел как работают люди на гуевых интерфейсах. В большинстве случаев они просто забывают о наличии клавиши ТАБ бля перехода между полями, хотя замечательно ею пользовались в текстовой форме на терминале!
В итоге ввод информации превращается из оперативной работы в примерно такое:
1.Ткнуть мышом в поле.
2.Бросьть мышь и вколотить текст.
3.перейти к п1
Интерфейс пользователя должен быть ФУНКЦИОНАЛЬНЫМ.
Если надо набивать формочки - на экране должны быть формочки и никаких рюшечек.
Все верно, только это можно свести к экономике. Если на рынке конкуренция то хорошая живет дольше плохой. А если монополия то правило не работает.
И как автор статьи представляет появление замены Windows если бы она была "плохой" программой.
И как автор статьи представляет появление замены Windows если бы она была "плохой" программой.
icq2003b - тоже на ней сидел, потом перешел на qip только потому что меньше жрет ресурсов
Какой бы windows не была хорошей ОС, в майкрософте, как и в прочих крупных компаниях, хороших программистов достаточно мало и основную часть кода пишут специалисты среднего уровня, знающие технологию, но не способные на неочевидную, но очень удачную, реализацию. Поэтому windows так много ругают. Поэтому же и многие сборки линокса ругают не менее рьяно.
Хороших программистов никогда не будет много. Но еще реже хорошие программисты пишут хорошие программы, потому что лишь своими силами более или менее крупный проект хороший программист не поднимет.
Ну и высокая концентрация хороших программистов дорогого стоит. Не от жадности производителей апплы стоят того, что стоят.
Хороших программистов никогда не будет много. Но еще реже хорошие программисты пишут хорошие программы, потому что лишь своими силами более или менее крупный проект хороший программист не поднимет.
Ну и высокая концентрация хороших программистов дорогого стоит. Не от жадности производителей апплы стоят того, что стоят.
А почему вы считаете, что "специалист среднего уровня" не может быть хорошим программистом?
Хороших программистов никогда не будет много.- согласен с вами полностью. :)
"Специалист среднего уровня" — это среднее арифметическое между плохими и хорошими программистами. Поэтому он может быть грамотным программистом, но не хорошим. Это взаимоисключающие понятия +).
Вообще общая масса программистов знают технологию, синтаксис и грамматику языка и, исходя из таких энциклопедических знаний, создают архитектуру, логику и исполнение программы. Хороший же программист во многом исходит из моментов идеологических, из сути самого языка, синтаксис и прочие моменты для него лишь инструмент реализации механизмов.
Вообще общая масса программистов знают технологию, синтаксис и грамматику языка и, исходя из таких энциклопедических знаний, создают архитектуру, логику и исполнение программы. Хороший же программист во многом исходит из моментов идеологических, из сути самого языка, синтаксис и прочие моменты для него лишь инструмент реализации механизмов.
Язык - вообще понятие вторичное. Когда мне люди отказываются решать на собеседовании задачки с указателями на C ибо они "20 лет на фортране программировали, а C знают очень плохо" я с лёгкостью неимоверной переформулирую задачу на FORTRAN - и, обычно, хорошие программисты не знающие C/C++ вообще с ней справляются, плохие (даже вроде что-то знающие) - не справляются...
Бесспорно, что склад ума, предрасположенный к подобной деятельности, много важнее знаний в какой-то конкретной области программирования. Новый язык или новую спецификацию он выучит в три счета.
А что за задачка ? :)
Вы знаете, смотря какие языки сравнивать, та же студия от М(например C#) не располагает к знанию низкоуровневого программирования, т.к. большую часть обработки берет на себя. Совсем недавно видел человека который с большим трудом вспоминал C++ после шарпа, при том, что программист раньше знал и C++ и в то же время с легкостью разобрался в коде на Java. Более менее легко переходить на программы одного уровня. мне например уже будет сложно что-то писать на ASM, хотя я его тоже изучал, т.к. в работе использую ООП.
На сколько я знаю, очень часто программисты пишут то, что написано в ТЗ и что требует заказчик/руководство/... . А в таком случае даже хороший программист может написать ужасную программу с точки зрения пользователей. Будь ее код и структура хоть идеалом красоты программиста.
Человек, который требует ТЗ - уже не "хороший программист". В лучшем случае хороший кодер...
Хороший программист, в частности, должен вовремя заметить что в описании задачи написана чушь и обратиться к заказчику с вопросами.
Хороший программист, в частности, должен вовремя заметить что в описании задачи написана чушь и обратиться к заказчику с вопросами.
Ну это скорее задача бизнес-аналитика, а не программиста. Максимум до кого должно дохидить ТЗ - это до архитектора, и то эту будет означать, что аналитика надо уволить :)
Зачем устраивать "испорченный телефон" ? Никогда этого не понимал... Помню как-то мы делали одну работку с госслужбой (причём не российской), так там не было возможности ничего понять пока руководители наверху не поняли что сроки выходят (два месяца из трёх отведённых на разработку системы вышли), форматы не согласованы, инструкций нет и "пахнет жареным". Ибо каждый вопрос проходил от нас к нашему начальству (с нами никто из представителей заказчика разговаривать не хотел), потом к их начальству (ну как же - начальство ж не должно разговаривать с кем попало), потом с разными аналитиками и архитекторами по цепочке и наконец доходил до другой конторы, которая выполняла другую часть задачи. Где-то порядка 10 звений в цепочке было.
После того, как началась паника нам наконец-таки дали координаты разработчиков другого компонента и мы за неделю всё переписали с нуля (ибо, как выяснилось, то что поступало к нам в качестве ТЗ вообще мало походило на то, что было реально нужно) и ещё неделю ушло на тестирование. Проблема две:
1. многие несуразности в ТЗ способен заметить только человек, который реально пишет код...
2. каждое звено в цепочке - это дополнительное искажение сигнала...
К сожалению обычный человек не способен общаться более, чем с 10-15 коллегами (и при этом что-то ещё делать), так что большие задачи требуют и аналитиков и архитекторов - это неизбежное зло.
После того, как началась паника нам наконец-таки дали координаты разработчиков другого компонента и мы за неделю всё переписали с нуля (ибо, как выяснилось, то что поступало к нам в качестве ТЗ вообще мало походило на то, что было реально нужно) и ещё неделю ушло на тестирование. Проблема две:
1. многие несуразности в ТЗ способен заметить только человек, который реально пишет код...
2. каждое звено в цепочке - это дополнительное искажение сигнала...
К сожалению обычный человек не способен общаться более, чем с 10-15 коллегами (и при этом что-то ещё делать), так что большие задачи требуют и аналитиков и архитекторов - это неизбежное зло.
Хм. Надеюсь хотябы 4 звена той цепочки были уволены? Потому как если ссылаться на какой-нибудь CMMI, то их наличие желательно, а уж если они затрудняют процесс разработки, то надо и их гнать и HR отдел драть.
многие несуразности в ТЗ способен заметить только человек, который реально пишет код...
примерно это я и имел ввиду, когда одной из особенностью хорошего программиста назвал "способность критически оценить полученное задание на непротиворечивость". Причем ваша формулировка мне даже больше нравиться.
так что большие задачи требуют и аналитиков и архитекторов - это неизбежное зло.Но почему же зло то? Просто в создании программ, как и в других областях, где применяется "промышленный" подход существует разделение труда.
ТЗ нужно даже для очень маленького проекта, где есть заказчик и исполнитель. Потому что иначе заказчик будет иметь возможность изменять задачу, переформулировать, добавлять новую функциональность в процессе написания программы, аргументируя простым "это же и так понятно!"
ТЗ нужно всегда (если вы посмотрите на Хабр то обнаружите что я же об этом и говорил в других топиках). Но хороший программист должен уметь его написать и доработать в случае необходимости. Вот и всё.
Да, написать ТЗ для себя. Иногда при разработке творческая мысль бъет таким напором, что уже завтра можно всё забыть и начать сначала. Иногда информация добывается по крупицам и очень важно ничего не забыть. В общем ТЗ нужно если сложность программы превышает то, что можно объяснить за 15 минут. Иначе можно что-то забыть или чем-то чрезмерно увлечься.
Разумеется ТЗ пишется в первую очередь для себя. После того как оно готово и его прочитает заказчик и согласится с ним - можно начинать кодирование. Дело просто в том, что многие детали, которые важны для программиста не-программист опустит - а они в ТЗ должны быть. Кто кроме программиста может сделать из "мыслей на тему" (которые обычно порождает заказчик) полноценное ТЗ ?
>На мой взгляд, хорошая программа - это прежде всего программа, которой >пользуются длительное время.
наверное, хорошая программа - это та, которая вызывает только положительные эмоции у человека и желание пользоваться снова и снова.
наверное, хорошая программа - это та, которая вызывает только положительные эмоции у человека и желание пользоваться снова и снова.
Почитал статью по ссылке...мда...
У человека странное представление о программисте. То что он описал это скорее кодер.
Проргаммист как-раз таки и должен знать тонкости бизнесс-процессов, что нужно пользователям и т.д.
Возможно тут трудность кроется в том, что в России прижилось одно название професии - программист, в то время как на западе она (профессия) делится на разные ветви - coder, developer, etc. Так же они разделяются на Junior, Senior, Lead, etc.
У человека странное представление о программисте. То что он описал это скорее кодер.
Проргаммист как-раз таки и должен знать тонкости бизнесс-процессов, что нужно пользователям и т.д.
Возможно тут трудность кроется в том, что в России прижилось одно название професии - программист, в то время как на западе она (профессия) делится на разные ветви - coder, developer, etc. Так же они разделяются на Junior, Senior, Lead, etc.
> - четкое выполнение всех требований указанных спецификациях на разработку
> - минимальный процент не выполненных требований
по-моему, два противоречащих друг другу тезиса :)
> - минимальный процент не выполненных требований
по-моему, два противоречащих друг другу тезиса :)
> А как только программиста перестает "переть" от процесса отладки ... он перестает быть хорошим программистом.
никакого программиста не прет процесс отладки, а хорошего тем более.
задача хорошего программиста сделать этот процесс минимальным :)
никакого программиста не прет процесс отладки, а хорошего тем более.
задача хорошего программиста сделать этот процесс минимальным :)
А мне как раз нравится, когда чего-то не выходит, неправильно работает, паришься, круги по комнате режешь, яблоки грызёшь - и вдруг о-па! Оно, оно, попалось, заработало как надо!
Вот ради ощущения инсайта (и собственной невъебической гениальности) иногда можно потратить время, честное слово%)
Вот ради ощущения инсайта (и собственной невъебической гениальности) иногда можно потратить время, честное слово%)
Отладка неизбежная часть процесса разработки ПО. Если вы ненавидите отладку - вы не программист. Ну или может быть вы и программист, но вы ошиблись с выбором профессии - это факт.
Очень странная статья, и очень странные тут тезисы - сыгубо умозрительные, и ни разу не достоверные. Расуждения топорные, и я даже не говорю, о том, что можно представить теоретическую ситуацию, где они совершенно не работаю, тут вполне досточно практики.
- Первая причина, по которой пользоваться могут плохой плохой программой, и не искать замен, это - отсутствие альтернатив. Из серии, и "мыши кололись, плакали, но грызли".
- Вторая - отсутствие психологической потребности "искать". Пример такой программы - IE (в доминатном кол-ве случаев).
- Третья, вытекающая из второй, понятие "хорошо"/"плохо"... я даже не говорю, что они субъективны, они иногда просто не могут иметь место быть, так как они, как оценочные категории, подразумевают сравнительную базу, которой может не быть. Если некоторое время назад (а у кого-то и сейчас), у большинства пользователей просто не и мысли о том, что существует другая "программа" нежели [_плохая_]Windows, то сравнительной базы не было. Глюки могли нравится, могли нет, но если комп вис, то виновата "коробка под столом", а не ОС с монолитным NT-ядром семейства Windows. Это должное, но пользовались.
- Совершенна очевидна ситуация, когда в наш маркетинговый век пользуются не тем, что хорошо (политика, которую возобновляет Google - ИМХО), а тем, что "знают". То есть, платят не за программу. а за хороший маркетинг. Есть, разумеется, и обратные ситуации, но как опровергающий фактор - вполне.
- 'При его этом владение теми или иными технологиями всегда уйдет на второй план' - смешно. Это сущностный аспект. Иначе программит не будет программистом. Сущность не может быть вторична. Есть необходимые признаки и достаточные (классика). Так вот, чтобы программиста назвать программистом, "знание технологий" - необходимый, но не достаточный. Достаточные - те, которые вы назвали ниже (и, и то - можно спорить). Но именно они - вторичны. Кстати, если развивать эту мысль, то, думаю, яно будет кто тут хороший программист, а кто плохой - мифический "профессионал" или "не выходящий из бадуна гений"...
- "а не выходящий из бадуна гений, программирующий сферического коня в вакууме" - а тут вообще странно. А почему Вы решили, что именно гений - плох, а профессионал - хорош? Критерий признанности обществом потреблядства?
Рузюме: можно выпустить стенограмму спора в 15-и томах о том, хорошие программисты пишут плохие программы или хорошие, и его можно развивать дальше только потому, что категории "хорошо\плохо" - не имеют твердой почвы. Субъективны. И опираясь на них, нельзя сделать аподиктичных (имеющих объективное значение) выводов. Это будет пустая болтовня. Хотя бы потому, что для разных target-group продуктов так же существуют свои понимания хорошо\плохо. Где-то и гений с бодуна будет полезней штата профессионалов.
Я бы сказал так: "Хорошие программисты, пишут разные программы, потому что на первый план выходит маркетинговая стратегия, и рычночное приемущество, которые обуславливаются умением проектировать удобные интерфейсы, привлекать инвестиции и подвигать к пользователям программы."
- Первая причина, по которой пользоваться могут плохой плохой программой, и не искать замен, это - отсутствие альтернатив. Из серии, и "мыши кололись, плакали, но грызли".
- Вторая - отсутствие психологической потребности "искать". Пример такой программы - IE (в доминатном кол-ве случаев).
- Третья, вытекающая из второй, понятие "хорошо"/"плохо"... я даже не говорю, что они субъективны, они иногда просто не могут иметь место быть, так как они, как оценочные категории, подразумевают сравнительную базу, которой может не быть. Если некоторое время назад (а у кого-то и сейчас), у большинства пользователей просто не и мысли о том, что существует другая "программа" нежели [_плохая_]Windows, то сравнительной базы не было. Глюки могли нравится, могли нет, но если комп вис, то виновата "коробка под столом", а не ОС с монолитным NT-ядром семейства Windows. Это должное, но пользовались.
- Совершенна очевидна ситуация, когда в наш маркетинговый век пользуются не тем, что хорошо (политика, которую возобновляет Google - ИМХО), а тем, что "знают". То есть, платят не за программу. а за хороший маркетинг. Есть, разумеется, и обратные ситуации, но как опровергающий фактор - вполне.
- 'При его этом владение теми или иными технологиями всегда уйдет на второй план' - смешно. Это сущностный аспект. Иначе программит не будет программистом. Сущность не может быть вторична. Есть необходимые признаки и достаточные (классика). Так вот, чтобы программиста назвать программистом, "знание технологий" - необходимый, но не достаточный. Достаточные - те, которые вы назвали ниже (и, и то - можно спорить). Но именно они - вторичны. Кстати, если развивать эту мысль, то, думаю, яно будет кто тут хороший программист, а кто плохой - мифический "профессионал" или "не выходящий из бадуна гений"...
- "а не выходящий из бадуна гений, программирующий сферического коня в вакууме" - а тут вообще странно. А почему Вы решили, что именно гений - плох, а профессионал - хорош? Критерий признанности обществом потреблядства?
Рузюме: можно выпустить стенограмму спора в 15-и томах о том, хорошие программисты пишут плохие программы или хорошие, и его можно развивать дальше только потому, что категории "хорошо\плохо" - не имеют твердой почвы. Субъективны. И опираясь на них, нельзя сделать аподиктичных (имеющих объективное значение) выводов. Это будет пустая болтовня. Хотя бы потому, что для разных target-group продуктов так же существуют свои понимания хорошо\плохо. Где-то и гений с бодуна будет полезней штата профессионалов.
Я бы сказал так: "Хорошие программисты, пишут разные программы, потому что на первый план выходит маркетинговая стратегия, и рычночное приемущество, которые обуславливаются умением проектировать удобные интерфейсы, привлекать инвестиции и подвигать к пользователям программы."
Первая причина, по которой пользоваться могут плохой плохой программой, и не искать замен, это - отсутствие альтернатив. Из серии, и "мыши кололись, плакали, но грызли".
Это что же это за такие чудо программы, которым нет альтернатив?
Вторая - отсутствие психологической потребности "искать". Пример такой программы - IE (в доминатном кол-ве случаев).
Во-первых ie - хорошая программа. (и давайте без холиваров), а во-вторых отсутствие психологической потребности искать замену, есть подтверждение "хорошести" программы.
'При его этом владение теми или иными технологиями всегда уйдет на второй план' - смешно. Это сущностный аспект. Иначе программист не будет программистом. Сущность не может быть вторична.
Быть может я не совсем верно выразился. Я имел ввиду вот что: даже если специалист отлично владеет самыми современными технологиями, методиками и т.п., но при этом допускает в своей работе много "брака" (багов, невыполненных требований, медленно въезжает в суть задачи и т.п.) то на высокое звание хорошего программиста он не тянет. И наоборот, если, допустим, другой специалист знает одну технологию, но с применением этой технологии делает все четко и в срок, то он вполне может называться хорошим программистом.
Где-то и гений с бодуна будет полезней штата профессионалов.
Согласен на все 100%. Только вот ведь в чем разница: найти гения, да еще уговорить его работать на вас - вероятность около нуля. А найти профессионала, т.е. действительно хорошего программиста (именно того, кого я описывал) задача реальная. Поэтому случаи с гениями от программирования давайте оставим в сторонке, на массовый рынок ПО они не влияют.
Были где-то на хабре топик про программы, написанные пользователями.
И пусть они были тыщу раз криво и некрасиво написаны, ущербны с точки зрения "хорошего программиста" - они лучше тех, что предоставляли пользователю эти самые "хорошие программисты".
Хотя если нет попытки на широкий охват и есть прямая связь между прогерам А, который пишет лично для юзера Б, а юзер Ц пишет для себя сам - то перевес уже на стороне программиста, конечно.
И пусть они были тыщу раз криво и некрасиво написаны, ущербны с точки зрения "хорошего программиста" - они лучше тех, что предоставляли пользователю эти самые "хорошие программисты".
Хотя если нет попытки на широкий охват и есть прямая связь между прогерам А, который пишет лично для юзера Б, а юзер Ц пишет для себя сам - то перевес уже на стороне программиста, конечно.
Все же предельно просто. Хороший программист GUI не должен заниматься, для этого есть дизайнеры интерфейсов и юзабилисты.
Зато он должен быть отличным алгоритмистом.
Зато он должен быть отличным алгоритмистом.
Все эти статьи и даже книги про программистов, которые, вот беда, не могут заменить голову-усилия-знания не желающих учиться и работать пользователей, при перефразировке названия или содержания которых на другую специальность получается "Почему хороший юрист не сделает вас сексуальным гигантом", все они несмешное дерьмо. И по качеству и по количеству.
Автор кстати не учел то, что хороший программист должен писать легко поддерживаемый хорошо структурированный код, на модификацию и дополнение которого уйдет как можно меньше времени
Мне кажется тут всё просто.
Что такое хорошая программа? - Хорошая программа для каждого своя.
1. Для пользователя.
Программа нужна, чтобы решать задачи. При этом, программа должный быть для него удобной. Тоесть при затрате минимальных усилий, (инсталяция настройка и т.п.) пользователь должен получить результат ради которого он ставил программу.
2. Для юзабилиста, интерфейс программы должен олицетворять его понимания удобного интерфейса.
3. Для дизайнера, программа должна его эстетически радовать.
4. Для программиста, программа должна быть легко модифицируемая, легко расширяемая, и легка для понимания (как всё работает)
5. Для менеджера, программа должна быть удобна, чтобы её впаривать.
6. Для тестера, программа должна быть легко тестируемая.
Тоесть не всё так просто. И тезис, что хорошие программисты пишут хорошие программы не верен.
Скорей всего, хороший программист тот, у которого получается хорошие программы. А не тот, который всё знает, всё умеет, очень крут.
Что такое хорошая программа? - Хорошая программа для каждого своя.
1. Для пользователя.
Программа нужна, чтобы решать задачи. При этом, программа должный быть для него удобной. Тоесть при затрате минимальных усилий, (инсталяция настройка и т.п.) пользователь должен получить результат ради которого он ставил программу.
2. Для юзабилиста, интерфейс программы должен олицетворять его понимания удобного интерфейса.
3. Для дизайнера, программа должна его эстетически радовать.
4. Для программиста, программа должна быть легко модифицируемая, легко расширяемая, и легка для понимания (как всё работает)
5. Для менеджера, программа должна быть удобна, чтобы её впаривать.
6. Для тестера, программа должна быть легко тестируемая.
Тоесть не всё так просто. И тезис, что хорошие программисты пишут хорошие программы не верен.
Скорей всего, хороший программист тот, у которого получается хорошие программы. А не тот, который всё знает, всё умеет, очень крут.
Вам плюсик.
Для меня, как для программиста, программа должна быть простой, гибкой, написанной с использованием новых технологий/фишек, весь код должен быть хорошо комментированным, а новый разработчик должен понимать «что к чему» за полчасика.
Как для пользователя, хорошая программа — та которая быстро работает и помогает справляется с поставленными задачами, не лишним будет удобный интерфейс и наличие расширений (да да, я считаю, что засовывать в браузер проигрыватель мп3 не очень правильно, но в виде расширения очень даже не плохо).
Для меня, как для программиста, программа должна быть простой, гибкой, написанной с использованием новых технологий/фишек, весь код должен быть хорошо комментированным, а новый разработчик должен понимать «что к чему» за полчасика.
Как для пользователя, хорошая программа — та которая быстро работает и помогает справляется с поставленными задачами, не лишним будет удобный интерфейс и наличие расширений (да да, я считаю, что засовывать в браузер проигрыватель мп3 не очень правильно, но в виде расширения очень даже не плохо).
Важен только первый пункт.
Остальное вторично.
Остальное вторично.
это почему? наоборот - важен только 5 пункт - ведь он связан с деньгами. Прдеставьте себе программу, которая хорошо впаривается, и хоть и не нравится пользователям, но при этом продолжает хорошо впариваться. В этом случае менеджер заработает много денег и может даже повысит зарплату программисту. Разве это плохо?
В приведенной Вами статье, подменяются понятия. Человек мыслит на своем уровне восприятия технологий разработки ПО и делает попытку обобщения. Его статья описывает конторки где программист выполняет все роли в процессе разработки. Ну и конечно реклама книг.
Мне кажется понятие "хорошая программа" изначально противоричиво, например: для кого-то главный критерий управляемость с консоли, для кого-то скорость, для кого-то поддержка шкурок и других рюшечек...
Так что на всех не угадаеш. А в современном мире маркетинга если провести хорошую компанию с целью утверждения что это прога самая лучшая и заменый ее нет, то пользователи поверят и будут пользоватся, что бы не писали и не делал програмисты.
А вообще, хорошие проги получаются том же методом, как выигрывают лотерею. Почему я сделал кнопки, такими а другими незнаю, но народу понравилось.
Поэтому необязательно быть хорошим или плохим програмистом, надо угадать или быть удачливым, чтобы о твоей программе заговорили!
Так что на всех не угадаеш. А в современном мире маркетинга если провести хорошую компанию с целью утверждения что это прога самая лучшая и заменый ее нет, то пользователи поверят и будут пользоватся, что бы не писали и не делал програмисты.
А вообще, хорошие проги получаются том же методом, как выигрывают лотерею. Почему я сделал кнопки, такими а другими незнаю, но народу понравилось.
Поэтому необязательно быть хорошим или плохим програмистом, надо угадать или быть удачливым, чтобы о твоей программе заговорили!
Мне кажется понятие "хорошая программа" изначально противоричиво, например: для кого-то главный критерий управляемость с консоли, для кого-то скорость, для кого-то поддержка шкурок и других рюшечек...
А "интегральным", если так можно выразиться, показателем от всех этих критериев и является собственно мой критерий, т.е. используется ли программа длительное время значительным количеством людей. ("Значительное" количество разумеется для каждого типа программ свое)
Насколько далёк от истины пост критикуемый, настолько же далёк и этот. Например:
"Но, если программой пользуются, то в следующих версиях программы существенных недостатков, как правило, становится меньше. В этом смысле замечательный пример хорошей программы ОС Windows. :)"
ОС Windows делает не один программист, а команда из кучи программистов и аналитиков, что никак не противоречит критикуемому посту
"Именно поэтому хороший программист никогда не сделает в одиночку хорошую программу для пользователя."
Но в поддержку того что "хорошие программисты пишут хорошие программы", могу сказать что хорошую программу х-вый программист не напишет, не осилит просто напросто))
"Но, если программой пользуются, то в следующих версиях программы существенных недостатков, как правило, становится меньше. В этом смысле замечательный пример хорошей программы ОС Windows. :)"
ОС Windows делает не один программист, а команда из кучи программистов и аналитиков, что никак не противоречит критикуемому посту
"Именно поэтому хороший программист никогда не сделает в одиночку хорошую программу для пользователя."
Но в поддержку того что "хорошие программисты пишут хорошие программы", могу сказать что хорошую программу х-вый программист не напишет, не осилит просто напросто))
IMHO, типичный спор между теоретиками и практиками. Точнее, не спор, а флейм.
Кстати, в статье, из которой родилась эта статья, там в конце какой-то спам. Это настораживает.
Кстати, в статье, из которой родилась эта статья, там в конце какой-то спам. Это настораживает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему хорошие программисты пишут хорошие программы.