Ответ на сообщение Re: Программист. пользователя hohlenok
Попробую пояснить свою мысль:
1. Что отрасль представляла из себя ранее? Ответ:
Были "киты", "монстры", "мамонты" или как мы, будучи студентами их называли ещё "могикане"... это они делали всякие мелочи "на коленках", практически в одиночку или на пару и в цифре... ну типа там С... Линукс... Юникс... mumps... собственно всё то, что лежит в основе качественного и добротного современного ПО.
Также были и пионеры разного рода "групповух" типа IBM с их высочайшим пилотажем в виде "хирургических бригад" и "второй системы"... результатом которых тоже стали "звездные изделия" типа ОС-360 и т.д.
По большей части оно практически неизменно работает и по сей день.
Потом появились "новоиспеченные программисты"... типа нашего поколения..., которые уже росли на С, Паскаль, АДА или чем функциональном ... это нас так называли те могикане... ежели вчё. Тогда тоже от старичков можно было услышать про деградацию исскуства программирования... но тогда оно ещё оставалось исскуством, а программисты - художниками.
Имено там родились все "фичи" процедурного, структурного, модульного, объектного, функционального программирования. Способы композиции и декомпозиции = оптимизации... теории проектирования больших проектов "сверху вниз" и "снизу вверх" и их комбинации... и т.д.
Собственно нафига оно столько? А это результат стремления к простому правилу: изменение данных по возможности должно делаться В ОДНОМ МЕСТЕ проекта. Тогда расширяемость проекта - макисальна, а сопровождение - минимально. Правка одного места - ИСКЛЮЧАЕТ появление повторных багов.
Поэтому программист - тот кто УПРАВЛЯЕТ программой.
2. Что представляет ИТ-отрасль сейчас (можете поправить, если неправ):
Поточная роторно-конвеерная линия, где каждый участник исполняет ровно одну примитивную операцию:
а) менеджер проекта - общается с заказчиком, результат = постановка задачи. Собственно программирование ему знать в общем-то даже вредно. Ему достаточно грамотно понять "пожелания", т.е. быть в теме Заказчика, и результат. Как программист === обезъяна с гранатой.
б) архитектор проекта - по имеющейся постановке задачи рисует ТЗ на разработку. По сравнению с остальными участниками - он "гуру". Должен знать тонкости и особенности выбираемых инструментов и способов реализации, проводить ту самую композицию и декомпозицию поставленной задачи на отдельные фрагменты-модули, определять наборы входных/выходных данных и требования по тестированию... но! как ни странно, это всё к детальному знанию самих инструментов, программирования (как раньше) и, тем более навыков работы с ними не имеет почти никакого отношения! Он больше программист чем остальные, но тоже может им не быть совсем...
в) типа "программист", а по сути оператор станка - это те, кто кодит конкретную реализацию конкретной части проекта... он должен обладать высоким навыком кодирования и типовых алгоритмов... его задача "проста как три рубля": есть ТЗ шаг влево/вправо - расстрел на месте. Собственно программирования он знать вовсе не обязан. Тока конкретный инструментарий и иметь опыт применения... Это как раз для него придуманы "шаблоны проектирования". Не умеешь соображать - и не надо пробовать. Умные дяди для тебя сделали шаблон, а архитектор тебе его выбрал!
г) верстальщик (веб) или создатель интерфейсов (не знаю как их там зовут верно) - должен знать всё о "юзабилити" и тех инструментах, которыми пользуется: css, или чего ишо... activeX или чего ещё...
д) дизайнер... думаю понятно... желательно совмещать с предыдущим ротором этого конвеера...
е) тестировщик - может даже уметь кодить в рамках создания юнит-тестов... на крайняк, достаточно жать кнопки в тестовой версии и вопрошать "а чего оно?"... по сути = контроллер ОТК. этого конвеера. Зарплата может быстро расти по мере снижения качества кодеров... контроллер он и есть контроллер. Правильно отсаживать в отдельное помещение... можно в отдельную страну.
ж) ...
Поскольку людям свойственно ошибаться, прятать свои ошибки за спину соседа и лениться, то косяки просачиваются в продакшн пропорционально количеству ошибок и слабости системы надзора за всем этим колхозом "восемь лет без урожая"...
Что имеем в результате? А в результате имеем плохо проектированные проекты, слабые ТЗ, по которым абы как сварганен код, причем каждым - свой... зато:
а) отрасль обеспечивает занятость низкоквалифицированной рабочей силы, которая сама себя именует "офисный планктон", что само по себе даже забавно.
б) продукт выходит в массы, пусть и сырой но в заданный срок, а главное НЕЗАВИСИМО от работающего персонала и его квалификации. В конкурентной среде это достаточно важный показатель...
в) постоянный рост требований к железу. Производители железок радостно хлопают в ладоши.
г)единственно возможный метод создания проектов: декомпозиция. Каждый кодер реализует свой метод получения элемента коллекции. Потому что осознать "смежную" часть проекта и в лом, и не платють, и некогда... а по сути сам конвеер это - запрещает... сломаться могет!
д) тяжелое, дорогое сопровождение проекта и постоянный баг-фиксинг. Потому что правка ошибки в одном случае никак не исключает её повторение у соседа... копи-паст - рулит.
Как следствие, ПРОЕКТ управляет колхозом.
Вот. Эту тенденцию я и называю деградацией. Рано или поздно, но прогноз очевиден: реально сложные задачи таким колхозом, пардон методом решаться не могут... все равно, что пытаться запустить в космос поделку конвеерной линии автоваза... горшки - не летают.
Чем всё это кончится? Да ничем. Общество потеряет интерес к этим поделкам и отрасль помрет как ранее помирало всё сдохшее само-собой...
1. Что отрасль представляла из себя ранее? Ответ:
Были "киты", "монстры", "мамонты" или как мы, будучи студентами их называли ещё "могикане"... это они делали всякие мелочи "на коленках", практически в одиночку или на пару и в цифре... ну типа там С... Линукс... Юникс... mumps... собственно всё то, что лежит в основе качественного и добротного современного ПО.
Также были и пионеры разного рода "групповух" типа IBM с их высочайшим пилотажем в виде "хирургических бригад" и "второй системы"... результатом которых тоже стали "звездные изделия" типа ОС-360 и т.д.
По большей части оно практически неизменно работает и по сей день.
Потом появились "новоиспеченные программисты"... типа нашего поколения..., которые уже росли на С, Паскаль, АДА или чем функциональном ... это нас так называли те могикане... ежели вчё. Тогда тоже от старичков можно было услышать про деградацию исскуства программирования... но тогда оно ещё оставалось исскуством, а программисты - художниками.
Имено там родились все "фичи" процедурного, структурного, модульного, объектного, функционального программирования. Способы композиции и декомпозиции = оптимизации... теории проектирования больших проектов "сверху вниз" и "снизу вверх" и их комбинации... и т.д.
Собственно нафига оно столько? А это результат стремления к простому правилу: изменение данных по возможности должно делаться В ОДНОМ МЕСТЕ проекта. Тогда расширяемость проекта - макисальна, а сопровождение - минимально. Правка одного места - ИСКЛЮЧАЕТ появление повторных багов.
Поэтому программист - тот кто УПРАВЛЯЕТ программой.
2. Что представляет ИТ-отрасль сейчас (можете поправить, если неправ):
Поточная роторно-конвеерная линия, где каждый участник исполняет ровно одну примитивную операцию:
а) менеджер проекта - общается с заказчиком, результат = постановка задачи. Собственно программирование ему знать в общем-то даже вредно. Ему достаточно грамотно понять "пожелания", т.е. быть в теме Заказчика, и результат. Как программист === обезъяна с гранатой.
б) архитектор проекта - по имеющейся постановке задачи рисует ТЗ на разработку. По сравнению с остальными участниками - он "гуру". Должен знать тонкости и особенности выбираемых инструментов и способов реализации, проводить ту самую композицию и декомпозицию поставленной задачи на отдельные фрагменты-модули, определять наборы входных/выходных данных и требования по тестированию... но! как ни странно, это всё к детальному знанию самих инструментов, программирования (как раньше) и, тем более навыков работы с ними не имеет почти никакого отношения! Он больше программист чем остальные, но тоже может им не быть совсем...
в) типа "программист", а по сути оператор станка - это те, кто кодит конкретную реализацию конкретной части проекта... он должен обладать высоким навыком кодирования и типовых алгоритмов... его задача "проста как три рубля": есть ТЗ шаг влево/вправо - расстрел на месте. Собственно программирования он знать вовсе не обязан. Тока конкретный инструментарий и иметь опыт применения... Это как раз для него придуманы "шаблоны проектирования". Не умеешь соображать - и не надо пробовать. Умные дяди для тебя сделали шаблон, а архитектор тебе его выбрал!
г) верстальщик (веб) или создатель интерфейсов (не знаю как их там зовут верно) - должен знать всё о "юзабилити" и тех инструментах, которыми пользуется: css, или чего ишо... activeX или чего ещё...
д) дизайнер... думаю понятно... желательно совмещать с предыдущим ротором этого конвеера...
е) тестировщик - может даже уметь кодить в рамках создания юнит-тестов... на крайняк, достаточно жать кнопки в тестовой версии и вопрошать "а чего оно?"... по сути = контроллер ОТК. этого конвеера. Зарплата может быстро расти по мере снижения качества кодеров... контроллер он и есть контроллер. Правильно отсаживать в отдельное помещение... можно в отдельную страну.
ж) ...
Поскольку людям свойственно ошибаться, прятать свои ошибки за спину соседа и лениться, то косяки просачиваются в продакшн пропорционально количеству ошибок и слабости системы надзора за всем этим колхозом "восемь лет без урожая"...
Что имеем в результате? А в результате имеем плохо проектированные проекты, слабые ТЗ, по которым абы как сварганен код, причем каждым - свой... зато:
а) отрасль обеспечивает занятость низкоквалифицированной рабочей силы, которая сама себя именует "офисный планктон", что само по себе даже забавно.
б) продукт выходит в массы, пусть и сырой но в заданный срок, а главное НЕЗАВИСИМО от работающего персонала и его квалификации. В конкурентной среде это достаточно важный показатель...
в) постоянный рост требований к железу. Производители железок радостно хлопают в ладоши.
г)единственно возможный метод создания проектов: декомпозиция. Каждый кодер реализует свой метод получения элемента коллекции. Потому что осознать "смежную" часть проекта и в лом, и не платють, и некогда... а по сути сам конвеер это - запрещает... сломаться могет!
д) тяжелое, дорогое сопровождение проекта и постоянный баг-фиксинг. Потому что правка ошибки в одном случае никак не исключает её повторение у соседа... копи-паст - рулит.
Как следствие, ПРОЕКТ управляет колхозом.
Вот. Эту тенденцию я и называю деградацией. Рано или поздно, но прогноз очевиден: реально сложные задачи таким колхозом, пардон методом решаться не могут... все равно, что пытаться запустить в космос поделку конвеерной линии автоваза... горшки - не летают.
Чем всё это кончится? Да ничем. Общество потеряет интерес к этим поделкам и отрасль помрет как ранее помирало всё сдохшее само-собой...
"Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)
