Команды разработчиков ПО часто принимают решения о программной архитектуре или технологическом стеке, основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты. Я называю эту тенденцию «Hype Driven Development (HDD)», считаю ее вредной и выступаю за более профессиональный подход. Давайте посмотрим, как обстоят дела, и что мы можем противопоставить.
Новые технологии — новые надежды
Вы встречались с подобным? Команда выбирает новейшие, самые «горячие» технологии для использования в проекте. Кто-то из них читает пост в блоге, тренд в Твиттере или только что пришел с конференции, на которой говорили великие вещи. И вот уже команда использует эту блестящую технологию (или новую парадигму программной архитектуры), но вместо обещанной большой скорости работы и высокого качества продукта, они получают неприятности. Темп работы замедляется, пропадает мотивация, возникают сложности с выпуском рабочей версии. Некоторые команды застревают на этапе устранения багов вместо того, чтобы добавлять новые функции. Им требуется «еще пара дней, чтобы все подчистить».
Поддержка публикации — компания Edison, которая разрабатывает SDK для слежения за географическими объектами и систему оперативного учета сети магазинов «Мебель для дома».
Hype Driven Development
Источники подобного хайпа могут быть разными:
- Reddit driven development? — заявление известного блоггера или опубликованный материал на таких сайтах, как reddit, hackernews, blogs twitter, Facebook, GitHub и пр.;
- Conference driven development — воодушевление после посещения конференции, что на самом деле палка о двух концах: использование новейших, последних библиотек/интерфейсов/технологий без опыта обращения с ними может быть дорогой в ад;
- Loudest guy driven decisions? — громкая болтовня какого-нибудь парня, который просто не может не говорить о новинке, которая, в конце концов, убедит коллектив в необходимости ее использования;
- Gem/lib/plugin driven development — в рамках сообщества Ruby On Rails появляется новый gem, который вы скачивает для устранения проблемы, хотя написание пары строчек кода самим с такой же легкостью решило бы проблему. Но нет, мы лучше добавим библиотеку, плагин, gem и т.п. …;
- Stack Overflow driven development? — также стоит упомянуть злоупотребление бездумным копированием программистами решений с ресурса Stackoverflow (или вообще из интернета).
HDD — приговор, которые выносят себе программисты
Проблема в том, что в состоянии аффекта принимаются плохие решения. И последствия могут преследовать команду разработчиков месяцами и даже годами. В худшем случае они приведут к Тотальной редакции. Которая почти никогда не удается.
Корень зла — средства массовой информации, в которых идея распространяется быстрее, чем ее успевают проверить, быстрее, чем люди успевают понять ее достоинства и недостатки.
Анатомия хайпа
У большинства хайпов схожая структура:
Шаг 1: Реальная проблема и решение
В какой-нибудь компании сталкиваются с проблемой. Ответственная за решение команда определяет, что устранить проблему в рамках текущей архитектуры или технологических процессов невозможно. Компания создает новый фреймворк, библиотеку или парадигму и вскоре с проблемой покончено.
Шаг 2: Объявление, суета и ключевые слова
Команда с волнением ждем случая показать свою работу всему миру, и вот они уже пишут в блогах и выступают на конференциях. Зачастую решенная проблема была нетривиальной, поэтому они испытывают гордость, описывая найденное ими нетривиальное решение. Публика с восхищением узнает о новой технологии. Однако восхищение аудитории не подразумевает, что все ее члены до конца понимают, в чем именно была проблема или не вникают в детали решения.
Ведь все же это была нестандартная задача с нестандартным решением. И для разъяснения нужно чуть более чем твит, пара строчек в чате или даже пост в блоге. В современных средствах массовой информации суть сообщения может легко стать нечеткой и размытой по мере ее распространения.
Шаг 3: Помешательство начинается
Вскоре после того, как новость прошла по блогам и конференциям, разработчики по всему миру начинают знакомиться с новой технологией. И некоторые из них из-за размытости информации принимают поспешное решение использовать описанную технологию, даже если она и не способна решить ни одну из их текущих проблем. Но они в нее верят.
Шаг 4: Разочарование
Несмотря на отчаянные усилия, технология не облегчает людям жизнь, а, наоборот, доставляет много дополнительных забот — огромное количество переписанного кода и потраченного на изучение времени. Работа команда замедляется, управление крайне недовольно. Люди чувствуют себя обманутыми.
Шаг 5: Реализация!
Наконец-то, команда разработчиков, размышляя о прошлом, осознает назначение технологии и в каких случаях она будет наиболее пригодна. Они становятся мудрее… до очередной подобной шумихи.
Примеры хайпа:
Пример 1: React.js
- Шаг 1: В Фейсбуке проблема — приложение виснет при большом объеме информации.
- Шаг 2: Фейсбук объявляет о новой парадигме, используя модные слова: функциональный, виртуальный DOM, компоненты.
- Шаг 3: Мания. Фейсбук создал внешний интерфейс будущего! Давай быстрей писать комментарии!
- Шаг 4: Подождите, тут много работы, и не предвидится быстрой отдачи от инвестиций!
- Шаг 5: Решение было найдено для продвинутых одностраничных приложений с большим количеством уведомлений в реальном времени, и не обязательно будет подходить для более простых приложений.
Пример 2: TDD мертв из-за DHH
- Шаг 1: Девид Хайнмейер Хенсон (David Heinemeier Hansson (DHH), создатель фреймворка Ruby on Rails) объявляет, что сложно совмещать разработку через тестирование (Test-Driven Development, TDD) с Rails, т.к. последний не обладает архитектурой для поддержки правильного объектно-ориентированного программирования. И делает прагматичный выбор — не писать тесты наперед.
- Шаг 2: Истерия начинается с поста Хенсона в блоге и выступления на конференции. Теги: TDD МЕРТВ.
- Шаг 3: Давайте пропустим тесты! Наш гуру так сказал. Мы все равно их не писали. Теперь и делать вид не будем. Наконец-то, долой лицемерие.
- Шаг 4: Подождите! Сейчас работает еще меньше вещей, чем раньше. Мы сделали корявый код.
- Шаг 5: «TDD не мертв или жив. TDD — это уступки, включающие риск изменения программного интерфейса приложения, навыков исполнителя и существующего дизайна» — Кент Бек (Kent Beck).
Пример 3: Микро-сервисы
- Шаг 1: Сложно оценить масштабируемость большого монолитного приложения. На определенном этапе мы можем разбить его на несколько сервисов. Так будет легче определить их соотношение запросы\сек.
- Шаг 2: Ключевые слова хайпа: масштабируемость, слабая связанность, монолит.
- Шаг 3: Давайте перепишем все и разобьем на сервисы! У нас «спагетти-код», т.к. у нас монолитная архитектура! Нам нужно все расписать по микро-сервисам!
- Шаг 4: Черт! Теперь так медленно развивается приложение, так сложно установить и так много времени тратится на поиск ошибок среди разнообразных систем!
- Шаг 5: Микро-сервисы требуют высоких навыков, как в разработке, так и в области информационно-технологического обслуживания, и при правильном инвестировании могут в итоге стать более масштабируемыми. Но прежде чем вы достигнете определенного предела, это будут избыточные вложения средств. Микро-сервисы извлекаются, а не пишутся. Вы должны быть вот такой высоты, чтобы использовать микро-сервисы.
Пример 4: NoSQL
- Шаг 1: У базы данных SQL проблемы с большим количеством загрузок и не структурированными данными. Команды по всему миру начинают разрабатывать новые поколения баз данных.
- Шаг 2: Ключевые слова хайпа: масштабируемость, BigData, высокая производительность.
- Шаг 3: Наша база данных слишком медленна и не достаточно объемна! Нам нужно NoSQL!
- Шаг 4: Нам надо объединять таблицы? Так не пойдет. Простые операции SQL превращаются в сложности. Разработка идет медленно и наши ключевые проблемы не решены.
- Шаг 5: Инструменты NoSQL предназначены для решения специфических проблем (огромные объемы данных, не структурируемые данные, большое количество загрузок). SQL на самом деле отличный инструмент и справляется с большим количеством загрузок и большим объемом данных, если им умело пользоваться. Подходящих ситуаций для NoSQL не так уж много на 2016 год.
Пример 5: Elixir и Phoenix (или любая другая ваша любимая пара язык/интерфейс)
- Шаг 1: Сетевые фреймворки, такие как Ruby On Rail, на самом деле не предназначены для высоко производительных приложений, распределенных приложений или веб-сокетов.
- Шаг 2: Ключевые слова хайпа: масштабируемость, высокая производительность, распределенный, отказоустойчивый.
- Шаг 3: О боже, наше приложение медленное и наш чат не масштабируемый!
- Шаг 4: Ух ты, изучение функционального программирования или распределенного подхода не так уж и просто. Мы сейчас двигаемся очень медленно.
- Шаг 5: Elixir и Phoenix хорошо себя зарекомендовали, но нужно немало усилий для того, чтобы освоиться с ними. Это окупится в долгосрочной перспективе, если вам требуется приложение с выдающейся производительностью.
Список примеров бесконечен
В нашем густонаселенном кружке компьютерных разработчиков очень много областей, где хайп — привычное дело. В мире JavaScript каждый день появляются новые фреймворки: Node.js (ключевые слова: событийно-ориентированное программирование), реактивное программирование, Meteor.js (ключевые слова: разделяемые состояния), front-end MVC, React.js. Сами приведите пример. В области разработки программного обеспечения появляются новые архитектуры: проектно-ориентированная разработка (Domain Driven Development), Hexagon, DCI. Какая шумиха вам больше пришлась по душе?
Добросовестная практика
Если мы не можем полагаться на интернет и мнения других людей, как в таком случае принимать умные решения? Вот вам несколько дельных советов.
Тестируйте и исследуйте, прежде чем принимать решение
- Исследуйте вашу технологию сами, а не читайте про нее в блогах. Уделите день или два прототипу новой технологии, прежде чем делать окончательный выбор. Пусть команда проанализирует все «за» и «против». Или используйте только пару конкурентоспособных технологий, а остальные пусть тестируются вашими программистами.
- Проведите хакатон, это отличный способ настроить вашу команду на осторожность при внедрении новых технологий. Пусть в течение одного или двух дней они поработают с новыми на сегодняшний день технологиями и отберут наиболее обещающие. Их решения будут более взвешенными, т.к. будут основаны на их собственном опыте.
Когда же?
- В принципе, когда отдача от вложений значительна. Большинство технологий созданы для решения конкретных задач. У вас есть эта проблема? Сэкономит ли это решение вам время? Использование технологии окупит работу по ее внедрению и связанные с этим трудности? Что если работа в итоге станет медленней в два раза? Или в четыре? Оно все еще того стоит?
- Отличным командам программистов больше позволено — некоторые команды просто быстрее других начинают приносить выгоду. Им становится скучно работать с тем, что получается легко. Эти команды могут чаще представлять новые технологии. Это не оправдание не использовать хакатоны и серьезно не анализировать новые предложения. С другой стороны, если у команды проблемы с выполнением работы — будьте осторожны с новыми технологиями.
Нанимайте правильных людей:
- Серьезная техническая подготовка — ваш друг. Люди, которые знакомы с различными парадигмами, понимают теорию программирования (например, алгоритмы, параллельные вычисления) и отличаются хорошей инженерной культурой, менее подвержены хайпу.
- Опыт — шумиху любит молодежь. С годами люди, которые видели много разных новых решений и много раз сталкивались с трудностями, более трезво выбирают технологии.
Перевод: Сергей Даньшин
Комментарии (111)
poxu
02.12.2016 08:07-17И вот, очередной перевод. Берём первый попавшийся отрывок.
Оригинал:
watch carefully what happens after people are back from conference. People get inspired. And that’s a two-edged sword. Starting to use newest hottest lib/framework/architecture paradigm without enough research might be a highway to hell.
Перевод из статьи:
воодушевление после посещения конференции, что на самом деле палка о двух концах: использование новейших, последних библиотек/интерфейсов/технологий без опыта обращения с ними может быть дорогой в ад
Как на самом деле переводится отрывок:
посмотрите внимательно, что происходит, после того, как люди возвращаются с конференции. Люди воодушевлены. А это обоюдоострый меч. Использование новейших, наиболее привлекательных библиотек/фреймворков/архитектур без предварительного изучения может быть дорогой в ад
Хочется задать автору вопрос — зачем вы порете отсебятину, вместо того, чтобы заниматься переводом?
quantum
02.12.2016 08:29+20У топикстартера перевод лучше, чем у вас. Переводить слово в слово — не всегда хорошая идея
cultura
02.12.2016 08:39+14Присоединяюсь.
Перевод топикстартера — лучше.poxu
02.12.2016 08:42-9Вас не смущает, что в оригинале нет слова интерфейс? Что в оригинале нет слова технология?
atomlib
02.12.2016 09:20+10Рекомендую почитать учебник Комиссарова «Теория перевода» и вообще ознакомиться с дисциплиной. В частности вам нужно посмотреть в сторону понятия переводческой эквивалентности. По Комиссарову у вас пятый, ну от силы четвёртый уровень эквивалентности. У автора перевода — где-то второй, если я всё правильно понимаю.
poxu
02.12.2016 09:26-6В частности вам нужно посмотреть в сторону понятия переводческой эквивалентности.
Вы написали комментарий в ответ на мой вопрос, не смущает ли кого-нибудь, что в оригинале нету слова интерфейс и слова технология. Там, где у пеерводчика интерфейс в оригинале — фреймворк. Там где у переводчика технология — в оригинале — архитектура.
Мне вот очень любопытно, как слово интерфейс может быть на втором уровне эквивалентности слову framework, а слово фреймворк — на пятом уровне эквивалентности слову framework.
atomlib
02.12.2016 09:39+5Перевод — это не уравнение с одним решением. Его можно выполнить по-разному. Какой-то будет точнее следовать оригиналу и выглядеть как подстрочник, какой-то будет более вольно трактовать процесс превращения ИЯ в ПЯ. Перевод — процесс такой себе творческий. На выходе у двух человек обычно получаются разные вещи.
При этом одному читателю может понравиться один вариант, кому-то — другой. Начинаются споры и обвинения в «неправильности», хотя на деле всё это очень субъективно. Примерно такое наблюдается в каком-нибудь комьюнити фансаба азиатской анимации.
Что касается конкретно этих двух слов — в профиле автора есть замечательная кнопочка, по которой можно отправить личное сообщение. Если бы вы хотели, чтобы слова были исправлены, вы бы написали ему. Но вам, видимо, хотелось попесочить косточки постоянно переводящему статьи пользователю, поэтому вы начали писать комментарий со слов: «И вот, очередной перевод. Берём первый попавшийся отрывок…»poxu
02.12.2016 09:51-5Перевод — то не уравнение с одним решением. Его можно выполнить по-разному. Какой-то будет точнее следовать оригиналу и выглядеть как подстрочник
Быть ближе к оригиналу и выглядеть, как подстрочник — разные вещи. Но вы только что сказали, что у нас с авторорм разные уровни эквивалентности. Интуитивно подозреваю, что пятый уровень хуже, чем второй. И решение автора перевода — по вашему мнению лучше.
Вы не могли бы добавить побольше конкретики? В других коментариях есть замечаение про фразеологизм. Оно понятное и ценное. У вас есть замечания такого характера?
Что касается конкретно этих двух слов — в профиле автора есть замечательная кнопочка, по которой можно отправить личное сообщение. Если бы вы хотели, чтобы слова были исправлены, вы бы написали ему. Но вам, видимо, хотелось попесочить косточки постоянно переводящему статьи пользователю
Переводы пользователя пестрят грубыми ошибками. Какие-то исправляются, какие-то нет. Я думаю, если писать по поводу ошибок перевода непостредственно в коментарии — переводы станут лучше. И вы знаете — действительно помогает. Раньше у переводчика были переводы, меняющие смысл фразы на противоположный — теперь такого не встречаю.
atomlib
02.12.2016 09:56+2Пожалуйста, сообщайте автору об ошибках в тексте в личные сообщения, а не начинайте выяснять отношения в комментариях.
poxu
02.12.2016 10:02-1Я правильно понимаю, что вы только что попросили не обсуждать в коментариях к переводу качество перевода?
atomlib
02.12.2016 10:04+1Вам обсуждать или улучшать качество поста? Улучшать — сообщать о недочётах автору, обсуждать — начинать писать комментарий «смотрите, этот пользователь опять делает ошибки, давайте гнобить его».
poxu
02.12.2016 10:30-5Если замечания по переводу ценные, то перевод улучшится независимо от того, куда эти замечания отсылать.
И, конечно, вы заблуждаетесь. Обсуждать — это писать комментарий — смотрите вот тут у автора косяк. Или смотрите — вот тут автор перевёл особенно хорошо. Всё точно так же, как в технических статьях.
flancer
02.12.2016 10:57+3Коллега poxu, вы сбиваете фокус внимания со вкуса вина на цвет бутылки, в которую его разлили. Вам есть что сказать за само вино?
poxu
02.12.2016 11:31-5Я правильно понимаю, что вы считаете, что не нужно обсуждать качество перевода в коментариях к переводу?
flancer
02.12.2016 12:23+3Правильно :) Мне, по-большому счету, все равно, кто расставил эти буквы в слова в таком порядке, меня, по-большому счету, интересует прежде всего информация, которая передается при помощи этих слов. Это https://habrahabr.ru/, а не http://yapishu.net/
cultura
02.12.2016 12:40+4Я правильно понимаю, что вы считаете, что не нужно обсуждать качество перевода в коментариях к переводу?
Ну обсудили уже.
С вами большинство не согласны.
Предложенные вами идиомы — более корявы, чем у автора перевода.poxu
02.12.2016 13:06-4Предложенные вами идиомы — более корявы, чем у автора перевода.
Идиома в отрывке вообще одна. Остальное — замена слов из оригинала на те, которых в оригинале нет.
Jef239
02.12.2016 23:47+1Бывает интересней. Переведите в гугле some like it hot. Вы просто не поверите, как это переводится на русский.
P.S. Если не знать откуда там джаз и девушки — то вообще мистика
poxu
02.12.2016 08:41-10У топикстартера перевод лучше, чем у вас
Ну да, ну да. Например в оригинале обоюдоострый меч, а у него палка о двух концах. Или в оригинале фреймворк/архитектура, а у него интерфейс/технология. В оригинале — предварительное изучение или исследование, у него — опыт обращения.
Уверен это сильно улучшило перевод.
Переводить слово в слово — не всегда хорошая идея
Наверное, можно заменить фразеологизмы, которые отсутствуют в языке, на который мы переводим, на те, которые там есть. Но у переводчика тут просто переписывание текста так, как ему больше нравится, иногда с правками, искажающими смысл.
Когда переводишь — надо переводить. И, если автор написал — посмотрите внимательно, что происходит когда — то надо переводить то, что написал автор, а не то, что тебе хотелось бы видеть на этом месте.
cultura
02.12.2016 08:42+15Например в оригинале обоюдоострый меч, а у него палка о двух концах.
Идиомы в разных языках — они разные.
Французы бы сказали скорее про «две стороны одном медали», к примеру.
«Обоюдоостный меч» — практически не употребляется в русском языке и совершенно непонятно, приходится вдумываться.
В то же время «палка о двух концах» — понятно сразу.poxu
02.12.2016 08:43-3Вы, наверное, хотите сказать, что в русском языке нет идиомы обоюдоострый меч? И что русские две стороны одной медали не говорят?
cultura
02.12.2016 08:45+16Я хочу сказать, что самая нормальная идиома — палка о двух концах.
Обоюдоостный меч — это малоупотребимая калька с английского.poxu
02.12.2016 08:58-6Тем не менее фразеологизм в русском языке есть и, пусть редко, но используется. Но допустим, вариант с палкой о двух концах лучше. Вы действительно считаете, что присутствие хорошо перенесённого в культурный контекст фразеологизма компенсирует остальные дефекты перевода?
cultura
02.12.2016 09:00+5Насчет других частей перевода — я ничего не сказал, но конкретно этот ваш пример:
Оригинал:
watch carefully what happens after people are back from conference. People get inspired. And that’s a two-edged sword. Starting to use newest hottest lib/framework/architecture paradigm without enough research might be a highway to hell.
Перевод из статьи:
воодушевление после посещения конференции, что на самом деле палка о двух концах: использование новейших, последних библиотек/интерфейсов/технологий без опыта обращения с ними может быть дорогой в ад
Ваш перевод:
посмотрите внимательно, что происходит, после того, как люди возвращаются с конференции. Люди воодушевлены. А это обоюдоострый меч. Использование новейших, наиболее привлекательных библиотек/фреймворков/архитектур без предварительного изучения может быть дорогой в ад
Ваш пример режет русскоязычный слух.poxu
02.12.2016 09:13-10Мой русскоязычный слух — не режет. Но допустим у вас слух лучше.
Повторю вопрос, который уже задавал. Вас не смущает, что в оригинале нет слова интерфейс? Что в оригинале нет слова технология? Не смущает вас, что в оригинале предлагают примотреться к людям, которые вернулись с конференции, а в переводе этого нет вообще?
phillennium
02.12.2016 13:33+3Перечисление через слэш lib/framework/architecture как бы намекает нам, что значение ни одного из этих слов не является для текста принципиально важным само по себе, они использованы лишь как примеры, иллюстрирующие общую мысль. От того, что один пример изменили на другой, эта мысль не изменилась и осталась настолько же понятной.
poxu
02.12.2016 13:35-3И потому, что мысль от этого не изменится, слово фреймворк надо заменить на слово интерфейс?
phillennium
02.12.2016 13:41+3Не то что бы «надо» — просто в таком случае ваши крики «всё неправильно» выглядят совершенно несоразмерными произошедшему, это как если бы вы из-за пары опечаток накатали длинный пылающий комментарий с отсылками к Розенталю.
poxu
02.12.2016 13:53-5Мне не нравятся ничем не мотивированные правки авторского текста. Но я бы не стал делать отдельный коментарий, если бы автор ограничивался ими.
В публикациях данного автора систематически встречаются грубые ошибки в переводе. Грубые. Если при первом взгляде на перевод нашлась немотивированная замена одного слова на другое — наверняка если посмотреть внимательнее — найдётся что-то совсем плохое.
И действительно.
Оригинал:
people who know different paradigms, understand theory of programming (e.g. algorithms, concurrency)
Перевод:
Люди, которые знакомы с различными парадигмами, понимают теорию программирования (например, алгоритмы, взаимосовместимость)
Это явный пример перевода промптом. Мало того, что автор выкладывает перевод, сделанный кем-то другим, так он ещё и не проверяет его перед публикацией.
Но, как я вижу, кроме меня, такое мелочи никого не интересуют.
phillennium
02.12.2016 14:07+2Это не «явный пример перевода промтом», потому что как раз промт никогда не перевёл бы concurrency как «взаимосовместимость».
А кроме того, промт не заменил бы одну идиому на другую — это как раз осмысленная человеческая работа.
Я допускаю, что у автора встречаются реальные ошибки — но ваш исходный комментарий выглядит как мальчик, кричащий «Волки!» при их отсутствии, так что вы сами поставили себя в ситуацию, когда, кроме вас, это уже никого не интересует.poxu
02.12.2016 14:20-7Это не «явный пример перевода промтом», потому что как раз промт никогда не перевёл бы concurrency как «взаимосовместимость».
Действительно. Промпт перевёл concurrency как паралеллизм. Чувствуется, что вы лучше меня с ним знакомы.
Мне нужно было сказать, не пример перевода промптом, а пример случая, когда переводчик понятия не имеет о чём текст, который он переводит.
poxu
02.12.2016 16:24-2Вот тут мой коментарий заминусовали.
А переводчик тем временем поправил перевод. Раньше он переводил concurrency как взаимосовместимость.
Теперь он поправил перевод и concurrency переведено как параллельные вычисления. Кто-то еще верит, что переводчик понимает что написано в тексте, который он переводит?
P. S.
Да, примерно так concurrency перевёл Промпт :).
NSA
06.12.2016 11:52Мой русскоязычный слух — не режет.
Судя по количеству допускаемых вами грамматических ошибок, ваш слух это действительно не должно резать.poxu
06.12.2016 13:24А вы делаете различие между грамматическими ошибками и опечатками?
dimm_ddr
06.12.2016 17:46-2Опечатки во многом — следствие пренебрежения к языку. Когда есть хотя бы немного времени на проверку, да еще и есть легкий способ исправления, оставление опечаток в тексте говорит либо о незнании правил (и тогда это именно ошибки), либо о безразличии к языку и собеседнику. Из безразличия к языку следует собственно «не режет слух».
Если же у вас совсем-совсем нет времени на проверку, то что вы здесь делаете, комментируя?poxu
07.12.2016 08:36+3Опечатка это разновидность ошибки, которая получается, когда думаешь, что жмёшь на одну клавишу, а на самом деле жмёшь на другую. Их количество зависит не от уровня владения языком, а от уровня владения клавиатурой. Таким образом тот факт, что человек делает опечатки — не свидетельствует о пренебрежении к языку.
Исправлять опечатки мешает одна особенность человеческого мозга. Люди, которые много читают, зачастую определяют слово не по совокупности букв, а по первой букве, последней букве и контексту. Для того, чтобы найти опечатку — надо намеренно бороться с этой особенностью, что далеко не так легко, как кажется на первый взгляд. О незнании правил тут речи не идёт. Если попросить человека, который сделал опечатку произнести слово по буквам — он сделает это правильно. О неуважении к языку тот факт, что человек не исправляет опечатки, не свидетельствует по той же причине.
cultura
02.12.2016 08:58+8Про меч в русском языке есть другая известная фраза:
«кто с мечом к нам придет, тот от меча и погибнет».
Но она про другое.
Обоюдостным меч — это, скорее, следствие таких вот переводчиков как вы, которые считают, что языки отличаются только звучанием и нужно переводить дословно.
А язык — это часть культуры, часть мышления.
Простой лобовой первод — всегда некорректен. Даже простое приветствие «хау ду ю ду» нельзя переводить в лоб.
Я согласен, что языки сближаются. Кальки идиом переходят из языка в язык…
Но когда вы начинаете бежать впереди паровоза — ваш перевод может быть трудно понять человеку, которые не знает английский.poxu
02.12.2016 09:07-3Обоюдостным меч — это, скорее, следствие таких вот переводчиков как вы, которые считают, что языки отличаются только звучанием и нужно переводить дословно.
Фразеологизм обоюдоострый меч пришёл в русский язык не из английского языка, а, в лучшем случае, из Библии.
Я согласен, что языки сближаются. Кальки идиом переходят из языка в язык…
Давно уже пришёл. Настолько давно, что успел немного устареть.
Но когда вы начинаете бежать впереди паровоза — ваш перевод может быть трудно понять человеку, которые не знает английский.
Мда
aso
02.12.2016 11:56Фразеологизм обоюдоострый меч пришёл в русский язык не из английского языка, а, в лучшем случае, из Библии.
В русском языке он практически не встречается — во всяком случае, в похожей семантике.
DenimTornado
02.12.2016 12:45+1А вот значение выражения обоюдоострый меч совпадает ли с нашей палкой о двух концах? Вот задумался чисто логически, меч с обоих сторон — острый. Типа, что так, что так — плохо. В нашем случае разные концы палки, внезапно, разные. Тут по идее даже смысл не подходит.
VolCh
02.12.2016 16:16+3Это один из общепринятых вариантов перевода, причём в обе стороны. И не так, и так плохо, а пока одной стороной делаешь хорошо, то об вторую сам порезаться можешь.
batyrmastyr
02.12.2016 13:53+2В вашем варианте всех смущает жутчайшее косноязычие, его невозможно читать независимо от правильности перевода слов framework и architecture paradigm.
И, если уж на то пошло, то не фреймворк, а каркас.
superyateam
02.12.2016 08:29+3Как будто про свою фирму прочитал: React.js, микросервисы на AWS лямбдах, Node.js.
Разработка постепенно превращается в ад, но у начальства все хорошо
Devgru
02.12.2016 10:29+4Разработка может превращаться в ад на любых технологиях вообще. Всё решают процессы.
shuron
02.12.2016 13:45-1Процессы… смотря что вы в это вкладываете… Невозможно формализировать все (в моем определеии формализация -часть процессориентированноси)
Возможны вы имеете ввиду обговоренности и общее понимание того что и как и зачем и почему без излишней формализации процесса… Тогда согласен…mayorovp
02.12.2016 14:01+1В данном случае речь идет не о формальный процессах, которых может и вовсе не быть — а о процессах AS IS, как есть.
Отслеживаются ли где-нибудь выявленные баги? В какой форме они доносятся до исполнителей — email, какой-нибудь im-клиент, телефон — или программист узнает о баге в тот момент когда в нему врывается орущий начальник? :)
Как взаимодействуют те, кто разрабатывают взаимодействующие сервисы? Договариваются сами, или есть ответственный за протокол взаимодействия?
Как выделяется время на инфраструктурную часть? "Пока логи не сделаем — за сервис не беремся" — или по остаточному принципу, "ты главное баги закрой — а логи будешь чинить если время в конце спринта останется?"
shuron
02.12.2016 14:46-1Отслеживаются ли где-нибудь выявленные баги? В какой форме они доносятся до исполнителей — email, какой-нибудь im-клиент, телефон — или программист узнает о баге в тот момент когда в нему врывается орущий начальник? :)
Я это для меня норма. тут мы на одной волне.
Я имел ввиду перерегуляцию которая мне встречалась (не СНГ).
Например наш процесс выглядит так, что перед тем как добавить 3 столбца в ДБ ты должен обговорить это с Тем-то и с тем-то…
Процесс заказа виртуальных машин, рамки фреймворков, рамки, языков програмирования…
Процесс получения прав на сервисы и АПИ, процесс аргументации за новую идею…
Devgru
02.12.2016 15:24+1Я не про формализацию. Даже когда мы не думаем о процессе он всё равно есть.
Мой опыт подсказывает, что сделать разработку можно сделать менее адовой за счёт изменения процесса. Порефлексировать, откуда берётся ад и соответствующим образом поменять разработку. Можно формальным изменением процесса, можно другими способами.
cultura
02.12.2016 08:29+9Вы встречались с подобным? Команда выбирает новейшие, самые «горячие» технологии для использования в проекте. Кто-то из них читает пост в блоге, тренд в Твиттере или только что пришел с конференции, на которой говорили великие вещи. И вот уже команда использует эту блестящую технологию (или новую парадигму программной архитектуры), но вместо обещанной большой скорости работы и высокого качества продукта, они получают неприятности.
Я чаще с обратным сталкивался.
Новая технология уже в мейнстрим входит, а люди все еще считают, что мол «это очередная игрушка, которых каждый год выпускается вагон и маленькая тележка — мы будем сидеть на проверенных технологиях 1990-х годов (даже не очень-то и утрирую)»m1ld
02.12.2016 09:10+2Как показывает личный опыт, постоянно переписывая код на новую технологию – ничего в итоге до конца не будет сделано.
Также новые библиотеки страдают своей неполноценностью, например: все они чаще всего строятся ради синтаксического сахара и мнимого обещания, что теперь то вы все сможете создавать крутые штуки в одну строчку, вместо старого языка в котором – это занимало 10 строчек.
А что в итоге? Новая мега-супер-пупер штука как и все предыдущие до нее обладают одними и теми же проблемами:
а) Ее тесты не покрывают добрую половину сценариев использования.
б) Имеет ограниченный набор инструментов для расширения собственных же инструментов.
в) Функционально чаще всего ограничена минимальным набором функций, которые смогли сделать к релизу версии №5 (хотя на самом деле, публичный релиз первый).
г) Добавление новых функций идет по двум сценариям: 1 — я бог, а вы ничто, я сказал этого здесь не будет. 2 — под давлением общественности набрасывается уйма новых функций, без опять же должного тестирования, и теперь тесты покрывают только 25% всех кейсов.
д) Не получив должного инвестирования, библиотека накрывается медным тазом и саппортится либо вялым комьюнити, либо платными консультантами.
Список можно долго продолжать.cultura
02.12.2016 10:47Кто сказал, что постоянно переписывать?
Вы что — одним проектом по 10 лет занимаетесь?
Вряд ли даже хотя бы 3 года.
А начать очередной новый проект на новой технологии — достаточно безвредно.
А что в итоге? Новая мега-супер-пупер штука как и все предыдущие до нее обладают одними и теми же проблемами:
а) Ее тесты не покрывают добрую половину сценариев использования.
б) Имеет ограниченный набор инструментов для расширения собственных же инструментов.
в) Функционально чаще всего ограничена минимальным набором функций, которые смогли сделать к релизу версии №5 (хотя на самом деле, публичный релиз первый).
г) Добавление новых функций идет по двум сценариям: 1 — я бог, а вы ничто, я сказал этого здесь не будет. 2 — под давлением общественности набрасывается уйма новых функций, без опять же должного тестирования, и теперь тесты покрывают только 25% всех кейсов.
д) Не получив должного инвестирования, библиотека накрывается медным тазом и саппортится либо вялым комьюнити, либо платными консультантами.
Вас никто не заставляет использовать небольшие полухобби-проекты в качестве базы для своих разработок.
Полно хорошо финансируемых новых разработок.
Скажем над Kubernetes трудятся разработчики из десятков крупных фирм (на зарплату, замечу).
svboobnov
02.12.2016 12:20Разработчики авионики и сталелитейных контроллеров смотрят на вас с недоумением (О_о).
И к ним присоединяется Кристиан Гислер, а также разработчики OpenOffice / Libre Office. Все они тянут свои продукты по многу лет.
Vladimir37
02.12.2016 10:51+2Бывает и такое, но не стоит впадать в крайности. Очень распространена ситуация, когда технология давно уже стала мейнстримом и используется во многих местах, но в разных конторах до сих пор используют древние и неудобные аналоги. До сих пор масса сайтов работают под PHP 3.0, а в некоторых банках ещё остаётся COBOL. Они также не поддерживаются, в них не добавляются новые функции, а тестов нет вообще. Зато не «модная хипстерская игрушка». Разве это нормально?
И что более печально, таких случаев с мёртвыми технологиями гораздо больше, чем случаев ненужного использования молодых инструментов, но говорят почему-то только про второй случай.cultura
02.12.2016 11:12в некоторых банках ещё остаётся COBOL. Они также не поддерживаются, в них не добавляются новые функции, а тестов нет вообще. Зато не «модная хипстерская игрушка». Разве это нормально?
Кобол используется только в крупнейших банках, которые начали автоматизироваться еще полвека назад, когда это было страшно дорого и недоступно для большинства.
Так что уж что-что, а компетентных специалистов такие банки могут себе позволить.
И уж кто-кто, а банки умеет считать деньги.
Если какие-то используется Кобол, то они так оценили стоимость работ и стоимость своих рисков перехода на новую систему.
cultura
02.12.2016 11:42+1До сих пор масса сайтов работают под PHP 3.0
Главная причина, по которой мы уходим от ручного труда к автоматике — автоматика работает и зарплату не просит.
То есть — если PHP 3.0 где-то работает и владельцев этой системы всё устраивает, то кто мы с вами такие, чтобы указывать владельцам той системы что им следует перейти на PHP 7.1?
Ни я не вы вовсе не собираемся оплачивать им этот переход.
Они самостоятельно решают как им распорядиться деньгами — сделать апгрейд до PHP 7.1, закупить новую мебель в бухгалтерию или поехать в Ниццу.
Поэтому даже если мы с вами видим недостатки использования PHP 3.0 в современном мире — мы никак не можем влиять на это. Ну ровно до тех пор, пока кого либо из нас (вас или меня) привлекут к доработкам этой системы и мы предложим за 100500 денег допилить с PHP 3.0, а за 100500/2 перейти на 7.1 и допилить уже с PHP 7.1.
Noahzgard
02.12.2016 14:23Зачастую это происходит в тех случаях когда подходит фраза «работает — не трогай». Если проэкт больше не развивается и в нём раз в полгода исправляется какой-то мелкий баг, его нет смысла переписывать с нуля на что-то новое, попутно плодить уйму багов и высасывая кучу ресурсов. Ну а новые проэкты сейчас никто не начинает на мёртвых технологиях.
cultura
02.12.2016 14:27+3Ну а новые проэкты сейчас никто не начинает на мёртвых технологиях.
На мертвых — нет.
На устаревших — запросто. Происходит сплошь и рядом.
А через небольшое время эти устаревшие превращаются уже в мертвые, а проект еще развивать надо.Noahzgard
02.12.2016 15:52Это да. Сами тут мучаемся с Kohana (php). Но это даже не про устаревшие, а просто про рандомное «ну я тут чёто заморился, переписывать не хочу, вот там пацаны класно сделали, пользуйтесь их продуктом». Так что сдохнуть впринципе может почти что угодно, не обязательно даже быть старьём.
mayorovp
02.12.2016 08:42В мире JavaScript каждый день появляются новые фреймворки: Node.js (ключевые слова: событийно-ориентированное программирование)
Э… с каких это пор Node.js является фреймворком? И причем тут событийно-ориентированное программирование?
svboobnov
02.12.2016 12:44+2>> И причем тут событийно-ориентированное программирование?
As an asynchronous event driven JavaScript runtime, Node is designed to build scalable network applications.
Взято с Node.Js/About
http2
02.12.2016 13:12основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты
Я чет в псевдосоцсетях не нашел нормального контента по программированию. :)
Но да, программисты нынче стали модниками. :)
TDD мертв из-за DHH
Хм, возможно позиция DHH повлияла на Ruby. Но да, у толкового разработчика должна быть своя позиция, а не быть флюгером. :)
П.С.
Сам борюсь с хайпом на счет «Фреймворки — наше все» в PHP. :)
shadowxnex
02.12.2016 13:12Профессионализм разработчика оценивается исходя из его опыта (практики решения реальных задач), знаний технологий, и имеющимся результатам. Любой фреймворк, библиотека, архитектурный паттерн — это прежде всего успешная практика использования решения определенного типа задач с определенными условиями и ограничениями.
Разумеется вам не обязательно использовать все подряд, использовать это так и там, как определяют авторы в своих решениях. Но знание подобного рода инструменов очень полезно для собственной базы знаний. Это один из факторов, от которого зависит ваш профессионализм, качество предоставляемых вами решений. Если вы читали статью Роберта Мартина «Screaming Architecture» (https://8thlight.com/blog/uncle-bob/2011/09/30/Screaming-Architecture.html) то понимаете, что програмное решение не должно зависеть от таких вещей как фреймворки, библиотеки, базы данных, веб серверы, и т.п.
Но эти знания не будут лишними, когда настанет время раскрыть детали вашей програмной архитектуры. И тогда вовремя представленное предложение позволит сэкономить вашей команде огромное количество времени, в попытках решить задачу стандартным набором инструментов.
Lofer
02.12.2016 13:12+1Про «новые технологии» уже иногда хочется плакать.
Берешь новую технологи, документации нифига нету, тратишь время, руки по локоть в коде…
Через некоторое время, понимаешь, что это «новая технология» нифига не новая, а самая что ни есть «старая», которую обругали поколение назад.
Пару раз мне было интересно, откуда ноги растут у «новой технологии», и складывается такое впечатление, что люди писавшие «новую технологию» не читали книжек хотя бы 10 летней давности.
Самое забавное, когда доходит до сравнения финансовых показателей похожих проектов по «старой кривой технлогии» и «самой новой правильной технологии». Вот тут и выясняются, что разницы то нету, а зачастую «новая технология» первые год… два может быть дороже :) Но это же фигня? через два года будет «Самая Новая Технология».
Критерий — деньги. Пока иного мерила не придумали
По совокупности скромные/убогие/устаревшие стандарты и решения заложенные в 90х могут дать фору Новым Мегафичам и Правильным Архитектурным Подходам.
Иногда складывается такое впечатление, что кто-то наконец прочитал книжку 90х… попробовать сваять, оно заработало и с криком «Ура! Заработало! Я мегакрут!!!» выкладывает в сеть.
Например: микросервисы. Основная декларируемая проблема, что они должны решить «сейчас делают большие толстые сервисы и это плохо и сложно».
Насколько я помню, в момент перехода от RPC к сервисной архитектуре основным декларируемым достоинством было: мы можем наделать кучу маленьких специфических сервисов, а клиент сам будет решать что ему надо. Середина 90х годов и начало 200х.
Чем декларация середины 90х отличается от декларации середины 201х? на мой вгляд ничем.Gryphon88
02.12.2016 15:51Почти про что угодно можно сказать «Это было в Lisp!». Ну, было, только тогда оно не было готов к использованию.
Fortop
04.12.2016 17:40+1Было готово к использованию.
Основная проблема это либо техника, которая «не тянет».
Либо, что встречается на мой взгляд чаще, дурь религиозная…
Это решение от мс, поэтому фигня.
Достаточно посмотреть на vml/svg, модные датабиндинги в современных js фреймворках и реализации этого же в IE, да тот же dojo с его кастомными атрибутами в свое время поносился как «неправоверный» и нарушающий html, а нынче angular, Bootstrap, knockout и иже с ними работают именно так.
А так… Стек возможностей нынче до боли похож на начало 2000-х.mayorovp
04.12.2016 19:36Датабиндинги в IE принципиально отличаются от современных. Они ведь не к js-объектам привязываются — а к COM.
Fortop
04.12.2016 19:40https://msdn.microsoft.com/en-us/library/ms531385(v=vs.85).aspx
емнип, там был биндинг к элементам страницы. Причем практически любым.
С доступом из Js.
Серьезно принципиально отличаются по сути решаемой задчи?mayorovp
04.12.2016 20:06+2С одной стороны — да, любой элемент страницы. А с другой-то что? А с другой вот это: https://msdn.microsoft.com/en-us/library/ms531386(v=vs.85).aspx
csv-файл, база данных, xml-файл… Ничего такого, чем можно было бы достаточно просто управлять через js.
Современные же решения берут данные из js-объектов
Fortop
04.12.2016 20:20-1Угу, а в объекты мы кладем их из файл/база/файл.
Предоставленные нам сервером.
Рассуждения бессмысленны. Поскольку скатятся к формату «если бы».
Технология была еще в затертом 2001, была не востребована по разным причинам.
Сейчас переизобрели велосипед и года 4-8 его развивали.mayorovp
04.12.2016 20:25Угу, а в объекты мы кладем их из файл/база/файл.
Предоставленные нам сервером.Ради того, чтобы перегнать данные из файла или базы в HTML — датабиндингом никто не заморачивается. Для этих целей есть неплохо работающие серверные шаблонизаторы.
Смысл клиентского датабиндинга — в том, что данные "в объекты" попадают от пользователя, минуя сервер.
Fortop
04.12.2016 20:31Весь этот «клиентский» датабиндинг нужен для ria
В рамках тех времен предполагалось не плодить зоопарк, а работать прозрачно в одной архитектуре. Когда клиентский ввод обрабатывается в одном месте, а не в 2-3 дублях (и на клиенте, и на сервере.
Опять же повторюсь. Рассуждения бессмысленны. Поскольку для корректных параллелей потребуется слишком много допущений о последующем развитии технологии.
Если брать аналогию, то электромобили и двс. Начало прошлого века и началого этого.
Электромобили были раньше и долгое время держали рекорды.
Потом пришел двс который делает то же самое, но немного иначе.
Сейчас на примере Теслы и прочих наблюдаем возврат к электромобилям.mayorovp
04.12.2016 21:04Вообще-то, это вы высказали утверждение — вам его и доказывать. Нельзя что-то доказать сказав "Рассуждения бессмысленны"
Fortop
04.12.2016 21:29Утверждение было в том, что технологии были и работали.
А отказ от них или аргументы против были скорее религиозного характера или просто не тянула техника (например те же чистые js приложения, и, да, я в курсе о влиянии js-движков)
Перечитайте внимательно.
И vml, и биндинги, и dojo Toolkit
Доказательства тут это примеры рабочих систем.
Или отсылки на спецификации.
Первое я вам не приведу.
Второе дал пусть и в единственном числе.
Dojo Toolkit и дискуссии по нему времен 2008/2009 поищите как-то сами. В качестве подсказки могу задать направление — кастомные атрибуты в html, которые он использовал, вызывали возражения.
А вы ожидаете от меня каких-то доказательств вашему личному внутреннему несогласию с чем-то неизвестным мне, поскольку вашей позиции я вообще не знаю.
Вам не кажется смешным для меня вести дискуссию в таком ключе? :-Dmayorovp
04.12.2016 21:30Причем тут религия — если всеми этими технологиями неудобно пользоваться?
Fortop
04.12.2016 21:41Реально неудобно?
Какими из?
Вам неудобно было с vml?
Или с dojo?
Насколько я помню единственное и существенное неудобно было у пользователей линукса, которых на начало 2000-х было чуть меньше чем ничего.
Поскольку многие технологии были завязанными на win-платформуmayorovp
04.12.2016 21:46Я говорю про то, про что знаю — про биндинги. То, что было сделано в IE, могло иметь применение в приложениях для интранета — но в вебе это попросту негде применить.
Fortop
04.12.2016 21:50На минутку напоминаю.
Это было в 2000-2001
Там спроса не было на тяжёлые RIA в вебе.
Соответственно и технологии решали актуальные задачи на тот момент.
Если бы мелкомягкие не факапили, а развивали их, то…
Во рту росли бы грибы.
Как это отменяет тот факт, что современные решения это реализация старых, но в новом окружении реалий?mayorovp
04.12.2016 21:50Это отменяет вот это:
Либо, что встречается на мой взгляд чаще, дурь религиозная…
Это решение от мс, поэтому фигня.Те технологии забыты потому что мелгомягкие факапили, а не потому что мелгомягкие.
Fortop
04.12.2016 21:55-1А, так оно не отменяет.
Ослика подзабросили.
А потом забили камнями окружающие.
И доблестно боролись с трудностями повторно.
Причины там были именно что религиозные.
Возражения о проприетарности и лицензиях появились лет эдак на пять позже.
P.S. И, да, религиозная дурь встречается и сейчас, и не только в отношении мелкомягких.
Просто они были одним из первых и ярких примеров
P.P.S. Как-то дикусс у нас скатился совсем не в техническую сторону, которой вы возражали изначально.
Поэтому предлагаю закрыть его.
shuron
02.12.2016 13:37+4Вот нас постоянно пугают этим эффеком. Но это невозможно распространить на все случаи и компании…
Например я решал определнные проблемы с деплойментом аппликаций и в начале 14-го наткнулся на Докер — который по определнию, если тупо смотреть на графики развития графиков был ХАЙПОМ (а многие до сих пор за хайп считаают)
Но поскольку у меня был уже 10 летний опыт програмирования, заботы о продуктивных серверах и решении организационных вопросов, я стал его испосльзовать и понемногу даже евангилизировать у себя на фирме (где был сраавнительно недавно)
И именно -этим граффиком мне давлаи отпор не вдумываясь… Мол хайп и ерунда…
Вот пол года назад стали ко мне приходить, что-бы показал как-та, было-то… Как его варить его, у тебя мол это же работаает в комманде…
Я смог доверить своему опыту и разобраться нужно это мне или нет не ждать 2-3 года пока кто-то решит что эот уже не хайп…
Мой вывод: Да про хайпы надо знать, особенно если ты юниор… Но когда ты сеньор и поковырял много чего, испытал много проблем, то доверяй своему опыту и остовайся открытым к диалогу…
Ищи диалог с опытными людьми особенно с теми кто другово мнения, если конечно человек умеет открыто общаться… Оставайся в диалоге…
Архитектуры и тулы не вечны и еще не постояннее требования к системам.VolCh
02.12.2016 16:27+1Поддержу. Добавлю только что не ошибается, кто ничего не делает, а ошибкой через несколько лет может оказаться и выбор «хайпа», и выбор «проверено», и выбор «работает — не трогай».
barney
02.12.2016 14:40+1Ребзя, откуда берется такой обширный поток «заимствованных слов»? (Как пример, само слово «хайп»)
Не ради поддержания руссиано, а чтобы знать, откуда черпать все эти «термины», чтобы оставаться в полном понимании картины и быть на гребне сленга?cultura
02.12.2016 14:49+1Нам еще повезло с сохранинем самобытности языка — так как у нас кириллица.
А, скажем, у немцев и французов — огромное количество англицизмов, да еще прямо без какой-либо трансляции с учетом грамматики языка пишутся буква-в-букву.
Правда, китайцам тут повезло больше. Они при всем желании не могут заимствовать.
Но есть и альтернативная модель поведения и на латинице: финны очень рачительно относятся к новым терминам в своем языке. Общемировых сходных во большинстве языков слов типа «фотография» в финнском языке крайне мало. Предпочитают сами придумывать.shuron
02.12.2016 16:45+2французов
эти какраз переводят все научные термины, есть вроде контора такая за это ответственая… — ля гранд натьен — таки ;))
А немцы не паряться так по этому поводу… — и я тоже если честно… глаза режет на русском читать «гибкие методы» и прочее…
Зачем? Никто не заставляет в Пушкина вставлять английские слова… Но в проффессиональной деятельности, совершенно глобально востребонанной и развивающейся области, где английский стандарт, зачем придумывать сложности?
ИМХО.shuron
02.12.2016 16:51-1P.S. Я в России не был давно, транслитом пишу… так что на меня закройте один глаз ;)
Noahzgard
02.12.2016 15:57Ну незнаю как там у китайцев, но корейскую современную речь бывает слушаешь чуть ли не 50 на 50 с английским.
А так-то много слов очень сложно перевести, особенно если тот кто хочет перевести слово уже временами начинает думать на английском. Вот слово hype/хайп, гугл переводчик вообще предлагает в переводы «обман, надувательство», а ведь смысл у слова другой. Я понимаю смысл этого слова, но вот вообще немогу подобрать русский аналог и даже не уверен что он есть. И как тут быть…
dim_s
04.12.2016 22:19+2Я знаком с обратным эффектом, когда закоренелые дядечки в корпоративных компаниях считают многие популярные устоявшиеся технологии хайпом и модой, случай из практики — SVN вместо Git, нежелание внедрять Git из-за того, что техническое руководство считает технологию лишь модой.
azsx
А как быть с тем, что часто именно работодатели требуют знаний по модным технологиям? Соответственно, если знаете — то получаете работу, так как технология новая, то более богатую.
Вопрос, вкратце, Вы уверены, что проблема на стороне программистов?
gimntut
Работодатели тоже подвержены хайпу, а когда текущие специалисты перестают справляться с новыми технологиями, то приходится искать новых со знаниями модных технологий.
Проблема на стороне всех, кто подвержен хайпу.
WildZero
На мой взгляд, работодателю, относительно без разницы что будет использоваться, а вакансии составляются на основе уже имеющегося кода. Так что, если уже начали использовать что-то «модное», то и требовать знание этого «модного» будут в вакансии. Так что — да, проблема на стороне программистов.
cultura
Если на собеседовании вам задают вопросы по новым технологиях — то на самом деле интересуются: являетесь ли вы простым кодером или человеком, которому нравится развиваться в разработке ПО.
То, что на новой работе понабоиться использовать все те технологии, о которых вас спрашивали — вовсе не факт.
Выясняют ваш интерес к профессии разработчика.
1kachan
В корне не согласен. Мне к примеру интересны устоявшиеся на «рынке» технологии или то что можно назвать зрелой технологией, нежели каждый новый вышедший фреймворк, технология или парадигма, а юзать новомодный фреймворк ради одной фичи это бред. Следовательно из ваших слов, многих не интересует своя профессия.
cultura
ИТ — чрезвычайно быстро развивающаяся отрасль.
И интересовать новыми технологиями — это норма для разработчика, который хочет поддерживать себя в форме. Иначе как вы узнаете, что ваша технология не зрелая, а уже устаревшая?
Показать, что вы читаете о новых технологиях — не единственный способ проявить себя на собеседовании при приёме на работу.
Если вы предпочитаете «проверенные решения», то я ожидаю от вас, что вы сможете обсудить плюсы-минусы любимого фреймворка. И минусы в том числе и возможные пути их решения.
Без хотя бы поверхностного знания «а что там происходит в мире» вы даже не узнаете, что это столь досаждающая вам особенность является минусом и как-то там решается в других фреймворках.
Просто для расширения кругозора нужно это знать.
Не обязательно применять немедленно.
Никто и не говорит, что нужно юзать. Я это сразу и написал:
azsx
Уточню вопрос. Давайте навскидку поделим кодеров. Не начальников, которые умеют вести офисные битвы за статус и премии, а кодеров, которым хлеба не надо — работу давай.
а) кодер работает не менее 5 часов. Оставшиеся 3 часа он смотрит в окно, пьёт чай, читает любимый форум.
б) кодер работает от 2 до 4 часов и оставшееся время, в том числе смотрит новые фреймворки. Так сверху, рекламки читает на хабре.
в) кодер работает мало, он сразу в гугл и ищет любой фреймворк или библиотеку, которая хотя бы частично решает его задачу. Ему пофиг на рекламу и перспективы, всё равно года через два он сменит работу по тысяче причин.
Ожидать от А тяги к хайпу, наивно. Он перепишет лучше. Очень опасен Б, он ради премии на пятиминутке обязательно ляпнет, что есть новое и модное и он готов, за доплату внедрить. Ему доплата, всем (цензура). Как правило В не опасны совсем, так как где есть В — там проекты больше 3-х лет не живут.
Но всё меркнет перед начальником, который говорит: «Я знаю, что через браузер можно получить доступ к внутренним ресурсам компьютера, пример, хром ос. Давайте!». И что надо сказать, чтобы угомонит тягу начальника к хайпу?
Честно, очень спорное утверждение. Я всё таки придерживаюсь комментария ниже, так как большая часть людей перестали читать книги совсем, то «внезапно» многие люди осилившие литературу 90-х годов могут предложить нечто новое, которое хорошо забытое старое.
Забыли добавить, работодатели часто требуют опыт не менее 5-ти лет даже по фреймворкам, которым ещё нет 5-ти лет.
mayorovp
Куда отнести того, кто работает много, но половину времени — в гугле в поисках библиотек, решающих задачу?
Или того, кто первым схватит любую подходящую библиотеку — но если ее возможностей не хватит либо в ней найдется баги — сам же и перепишет ее лучше?
azsx
Напомню, это комментарий (то есть кратко) и набросал навскидку. Также, хронометраж рабочего времени, культурно говоря, не нравится никому именно по этой причине проводится редко среди ценных сотрудников.
Б.
А. Только он не схватит любые библиотеку, а проведёт анализ чужого кода и использует чужие наработки для своего кода. Или восхитившись неизвестными мастерами будет юзать их код. Ну правда если речь не о совсем известном, типа БД.
Только это уточнение никак к теме комментария не относится. Надо внести правки в программу на java. Внезапно, кто-то заявляет, что java отстой, а go это тренд! Программа переписывается на go. При этом программисты go изначально не знали, вот учатся на вашем проекте. Для программистов, по моему мнению, это нонсенс. Для работодателей — сплошь и рядом.
То есть я первый спросил, как бороться с начальниками? Кодер человек маленький, чего нам бодаться?
PsyHaSTe
Не понимаю, чем пить чай лучше, чем изучать новые фреймворки. Тем более, что обычно люди эти 2 действия совмещают.
Такое ощущение, что вы не просто не изучаете, что происходит вокруг, а еще и гордитесь этим.
В большинстве вакансий вижу требования к опыту 1-3 года
azsx
Себя я отношу к категории В, то есть я за любой скопированный код, который хоть частично решит мою задачу.
Может сойдёт за оправдание, что пока программирование не мой заработок.
Это вокруг в интернетах все трудоголики грамотные.
herr_kaizer
Интерес к профессии разработчика == подверженность хайпу?
zag2art
> А как быть с тем, что часто именно работодатели требуют знаний по модным технологиям?
ага, обычно опыт должен быть не менее 5-ти лет… )