|
![]() |
#1 |
Участник
|
Цитата : "Программист - это тот, кто пишет программы. Из-за потасканности термина программисты вынуждены называть себя разработчиками. Крайним случаем терминологической путаницы, которой подвержен невежа-обыватель, надо считать утверждение "программист=хакер". "
Взято от сюда : http://www.iteam.ru/publications/it/.../article_1971/ Интересно написано , хотя немного и на другую тему. |
|
![]() |
#2 |
Участник
|
Еще цитата:
"И еще одно замечание. Редкий программист в наших широтах, да и не только в наших, доживает до сорокалетия. Это как спорт, где возраст - непреодолимое препятствие для эффективной работы. После окончания карьеры программист становится либо начальником других программистов, либо - что случается много чаще - вовсе уходит из цеха. Пройдет еще десяток лет, и отставные программисты станут попадаться среди охранников на автостоянках. Едва ли с этим можно что-то поделать." Обрыдаться ![]()
__________________
любитель портвейна и снов с прокисшей капустой в усах |
|
![]() |
#3 |
Участник
|
К барьеру
Цитата:
Сообщение от eugene egorov
![]() Еще цитата:
"И еще одно замечание. Редкий программист в наших широтах, да и не только в наших, доживает до сорокалетия. Это как спорт, где возраст - непреодолимое препятствие для эффективной работы. После окончания карьеры программист становится либо начальником других программистов, либо - что случается много чаще - вовсе уходит из цеха. Пройдет еще десяток лет, и отставные программисты станут попадаться среди охранников на автостоянках. Едва ли с этим можно что-то поделать." Обрыдаться ![]() Один спортсмен на вопрос о своем спортивном долголетии ответил, что "когда вы по ночам пьянствовали - я спал". Надо думать немного о своем физическом теле и не застревать на достигнутом. А если кто не берет на работу по возрасту - так это его проблемы. |
|
![]() |
#4 |
Участник
|
Цитата:
Сообщение от eugene egorov
![]() Еще цитата:
"И еще одно замечание. Редкий программист в наших широтах, да и не только в наших, доживает до сорокалетия. Это как спорт, где возраст - непреодолимое препятствие для эффективной работы. После окончания карьеры программист становится либо начальником других программистов, либо - что случается много чаще - вовсе уходит из цеха. ...... крайне немного в ИТ-консалтинге разработчиков/программистов старше 40 а по AX/NAV я бы оценил их средний возраст в 26-28 лет .... |
|
![]() |
#5 |
Участник
|
Портрет участника форма за 2007 год показывает, что большинство посетителей являются разработчиками:
Портрет участника 2007: Возраст На возраст, выше указанного Вами приходится столько же, сколько и на указанный Вами диапазон: Портрет участника 2007: Ваша специализация (можно выбрать несколько вариантов) А вот старше 40 лет действительно людей мало, но это объяснимо, не так давно Акса стала широко распространенной у нас. |
|
![]() |
#6 |
Участник
|
![]() Цитата:
Сообщение от Raven Melancholic
![]() Портрет участника форма за 2007 год показывает, что большинство посетителей являются разработчиками:
Портрет участника 2007: Возраст На возраст, выше указанного Вами приходится столько же, сколько и на указанный Вами диапазон: Портрет участника 2007: Ваша специализация (можно выбрать несколько вариантов) А вот старше 40 лет действительно людей мало, но это объяснимо, не так давно Акса стала широко распространенной у нас. ![]() |
|
![]() |
#7 |
Участник
|
![]() Цитата:
![]() |
|
![]() |
#8 |
Участник
|
Цитата:
Сообщение от Raven Melancholic
![]() Портрет участника форма за 2007 год показывает, что большинство посетителей являются разработчиками:
Портрет участника 2007: Возраст На возраст, выше указанного Вами приходится столько же, сколько и на указанный Вами диапазон: Портрет участника 2007: Ваша специализация (можно выбрать несколько вариантов) ... а ведь есть такие компании, в которых примерно такое кол-во сотрудников занимается AX/NAV ... т.е. репрезентативность его обсуждаема .... Цитата:
![]() |
|
![]() |
#9 |
Участник
|
«Пишут» статейки для журналов, «пишут» скрипты длиной в сотню-другую строк или одноразовые утилиты, от которых требуется лишь сэкономить время и нервы на тупом ручном труде, а сколь-нибудь крупные, сложные и/или важные программы создают иначе: изучают предметную область, собирают, формализуют и анализируют исходные требования, создают высокоуровневый проект, разрабатывают архитектуру, создают детализированный проект, конструируют, тестируют, оптимизируют, сопровождают... Возможно, поэтому в английском языке используют именно термин software developer, а не programmer.
Похоже, спор про различие между "программистами" и "разработчиками" (программных продуктов) возникает из-за использования некорректных метафор и аналогий, а также следующих из них некорректных выводов. К слову, вот некоторые соображения по поводу метафор из одной очень хорошей книги: Цитата:
Разумеется, некоторые метаформы лучше других. Хорошими метафорами можно считать те, что отличаются простотой, согласуются с другими релевантными метафорами и объясняют другие экспериментальные данные и наблюдаемые явления.
... Самая примитивная метафора, описывающая разработку ПО, берет начало в выражении «написание кода». Согласно литературной метаформе разработка программы похожа на написание письма: вы садитесь за стол, берете бумагу, перо и пишете письмо с начала до конца. К сожалению, литературная метафора была увековечена в одной из самых популярных книг по разработке ПО - кние Фреда Брукса «Мифический человеко-месяц». Брукс пишет: «планируйте выбросить первый экземпляр программы: вам в любом случае придется это сделать». Перед глазами невольно возникает образ мусорного ведра, полного черновиков. Подобный подход может быть практичным, если вы пишете банальное письмо своей тетушке. Однако, расширение метаформы «написания» ПО вплоть до выбрасывания первого экземпляра программы - не лучший совет в мире разработки ПО, где крупная система по стоимости уже сравнялась с 10-этажным офисным зданием или океанским лайнером. Метафора «построения» ПО полезнее, чем метафора «написания», так как согласуется с идеей аккреции ПО и предоставляет более детальное руководство. Построение ПО предполагает наличие стадий планирования, подготовки и выполнения, тип и степень выраженности которых зависит от конкретного проекта. При изучении этой метафоры вы найдете и другие параллели. Для построения метровой башни требуется твердая рука, ровная поверхность и 10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в 100 раз больше пивных банок. Такой проект тербует совершенно иного планирования и конструирования. Если вы строите простой объект, скажем, собачью конуру, вы можете пойти в хозяйственный магазин, купить доски, гвозди, и к вечеру у Фидо будет новый дом. Если вы забудете про лаз или допустите другую ошибку, ничего страшного: вы можете исправить ее потом или даже начать все сначала. Все, что вы при этом потеряете, - время. Такой свободных подход уместен и в небольших программных проектах. Если вы плохо спроектируете 1000 строк кода, то сможете выполнить рефакторинг или даже начать проект заново, и это не приведет к крупным потерям. Построить дом сложнее, и плохое проектирование при этом приводит к куда более серьезным последствиям. Сначала вы должны решить, какой тип здания вы хотите построить, что аналогично определению проблемы при разработке ПО. Затем вы с архитектором должны разработать и утвердить общий план, что похоже на разработку архитектуры. Далее вы чертите подробные чертежи и нанимаете бригаду строителей - это аналогично детальному проектированию ПО. Вы готовите стройплощадку, закладываете фундамент, создаете каркас дома, обшиваете его, кроете крышу и проводите в дом все коммуникации - это похоже на конструирование ПО. Когда строительство почти завершено, в дело вступают ландшафтные дизайнеры, маляры и декораторы, делающие дом максимально удобным и привлекательным. Это напоминает оптимизацию ПО. Наконец, на протяжении всего строительства вас посещают инспекторы, проверяющие стройплощадку, фундамент, электропроводку и все, что можно проверить. При разработке ПО этому соответствуют обзоры и инспекции проекта. Последний раз редактировалось gl00mie; 01.02.2008 в 12:20. Причина: typo |
|
![]() |
#10 |
Участник
|
Цитата:
Сообщение от gl00mie
![]() «К слову, вот некоторые соображения по поводу метафор из одной очень хорошей книги:
В Совершенном коде воды 95%. Но есть очень интересные вещи. Ради которых стоет её читать. Но мне показалось, что её надо было читать по началам глав. Как начинаются разъяснения нужно переходить на другую. А «Мифический человеко-месяц» это шедевр, мне кажется её надо сделать обязательной для прочтения всем кто имеет дело с ИТ. |
|
![]() |
#11 |
Участник
|
![]() Цитата:
Сообщение от gl00mie
![]() Метафора «построения» ПО полезнее, чем метафора «написания», так как согласуется с идеей аккреции ПО и предоставляет более детальное руководство. Построение ПО предполагает наличие стадий планирования, подготовки и выполнения, тип и степень выраженности которых зависит от конкретного проекта. При изучении этой метафоры вы найдете и другие параллели
В принципе эта метафора предполагает постоянное наличие садовника ![]() |
|
![]() |
#12 |
Участник
|
Цитата:
Цитата:
В любом случае, речь не о том, чтобы найти метафору, полностью описывающую разработку ПО, а скорее о том, чтобы оценить адекватность и полезность тех или иных метафор. В этом плане "написание" ПО, на мой взгляд, куда менее адекватно описывает этот процесс, нежели его "построение". Последний раз редактировалось gl00mie; 01.02.2008 в 13:25. Причина: typo |
|
![]() |
#13 |
Участник
|
Цитата:
Сообщение от gl00mie
![]() Во-первых, не метафора "построения", а скорее "строительная" метафора. Во-вторых, в строительстве речь не всегда идет о разработке и постройке готовых зданий; разрабатываться могут, к примеру, типовые серии домов или секции для таких домов, из которых затем строятся здания тех или иных конфигураций.Метафора «выращивания» ПО подобно растениям в саду совершенно не отражает взаимодействия между различными программными системами и отдельными блоками внутри систем - из поля зрения ускользает этап интеграции разрабатываемого ПО или отдельных его блоков, что особенно важно в тех же ERP-системах. Так что не вижу, чем эта метафора лучше "строительной". Кроме того, растения худо-бедно могут расти и сами, в отличие от программ. А, скажем, ошибки в программах не могут возникать сами собой или только из-за того, что они находятся "рядом" с другими программами. Это опять же идет в разрез с "садово-огородной" метафорой, ведь растения могут быть поражены паразитами "сами по себе", без участия "садовника".
В любом случае, речь не о том, чтобы найти метафору, полностью описывающую разработку ПО, а скорее о том, чтобы оценить адекватность и полезность тех или иных метафор. В этом плане "написание" ПО, на мой взгляд, куда менее адекватно описывает этот процесс, нежели его "построение". В этой части метафорический недостаток очевиден. Для садово-огородного подхода, этот недостаток снимается. Для принципа интеграции (взаимодействия), который как вы считаете ускользает согласно "садово-огородной метафоре" - я нашёл пример: можно провести параллель с прививкой одного растения к другому (вспомните Мичурина) или некоторые правила высаживания одних видов растений с другими. То что растения растут сами по себе, так и ERP-система может жить своей жизнью без программирования за счет пользовательских настроек. Не забываейте про базу данных, которая растёт (можно в некоторой степени говорить что пользователи "выращивают" базу данных ,и со временем по мере роста БД меняется поведение системы) Ошибки, которые возникают из-за конфликта других одновременно запущенных программ - распостранённое явление. А вредители - сразу напрашивается аналогия с компьютерными вирусами. Метафора садоводства выражает различие между органическим и синтетическим. Всё органическое выращивается;синтетические объекты собираются из конструируемых компонентов. Метафоры помогают применить абстрактные понятия в условиях рутиннно-технической деятельности. Согласен что главное адекватно оценить полезность метафоры в том или ином случае. Но когда говорят "написание ПО" я думаю это скорее не метафора а просто устоявшаяся фраза - в действительности ведь это не писательская деятельность а проектная. Последний раз редактировалось тов. Костомолоцкий; 03.02.2008 в 10:27. |
|