Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими $9 в час

Автор оригинала: Peter Robison
  • Перевод
image

В разгар кризиса вокруг Boeing-737 Max, до сих пор остается загадкой: каким образом компания, прославленная своим тщательным подходом к проектированию, допустила, судя по всему, детские ошибки при разработке софта, приведшие к двум катастрофам с человеческими жертвами. Инженеры, работающие в компании много лет, говорят, что разработка была осложнена из-за делегирования части работы низкооплачиваемым контракторам.

Недостатки софта, возможно, оставят самолеты прикованными к земле еще на один месяц — на этой неделе американские регуляторы обнаружили дополнительные проблемы. Программное обеспечение для серии 737-Max было написано во времена, когда компания Боинг увольняла опытных инженеров и оказывала давление на поставщиков.

Более того, икона американского самолетостроения и ее субподрядчики, доверяли временным работникам, зарабатывающим всего лишь $9 в час, разрабатывать и тестировать свое программное обеспечение. Зачастую, это были работники из стран с неразвитым самолетостроением, а именно из Индии.

“Вчерашние выпускники, нанятые на работу индийской софтверной компанией HCL Technologies Ltd, занимают несколько рядов столов в офисах Boeing Field в Сиэтле (официально King County International Airport, в этом аэропорту компания Боинг имеет свой ангар и проводит испытания самолётов — прим. перев.)”, говорит Марк Рабин (Mark Rabin), бывший инженер Боинга, работавший в группе тестирования самолетов серии 737-Max.

Кодеры из HCL обычно разрабатывают, согласно спецификациям, присланным из Боинг. Но, по словам Рабина “это спорное решение, так как оно гораздо менее эффективно, чем просто дать писать код инженерам Боинга”. Он вспоминает, что “зачастую требовалось переделывать всё по несколько раз, поскольку код был написан неверно”.

Поддержка индийских компаний возможно принесла и другие плоды. В течение последних нескольких лет Боинг выиграл несколько тендеров на поставку военных и коммерческих самолётов в Индию, например контракт стоимостью 22 млрд. долларов для компании SpiceJet Ltd. Этот контракт включает 100 самолетов 737-Max 8 и является крупнейшим заказом за всю историю индийских авиалиний, традиционно сотрудничавших с Airbus.

Согласно выводам, опубликованным в соцсетях, инженеры из HCL участвовали в разработке и тестировании ПО для PFD (Primary flight display, основной пилотажный дисплей — прим. перев.), а сотрудники другой индийской компании, Cyient Ltd., занимались ПО для контрольно-измерительных приборов, предназначенных для лётных испытаний.

Дорогостоящая задержка


В одном из постов, сотрудник HCL охарактеризовал свои рабочие обязанности таким образом: “По-быстрому сделал костыль, чтобы решить проблему на продакшене и не задерживать лётные испытания 737-Max (задержка каждого полёта обходится компании Боинг в огромную сумму)”.

Компания Боинг заявляет, что не доверяла инженерам из HCL and Cyient разработку системы MCAS (Maneuvering Characteristics Augmentation System), с который связывают катастрофы рейса JT-610 Lion Air возле Джакарты в октябре 2018 и рейса ET302 Ethiopian Airlines под Аддис-Абебой в марте 2019. Также, по словам Боинга, ни одна из этих компаний не связана с проблемой, обнаруженной после катастроф — неработающей у большинства покупателей сигнальной лампой в кабине.

“Боинг имеет многолетний опыт работы с поставщиками и партнёрами по всему миру”, говорит официальный представитель компании. “Наша главная цель — всегда быть уверенными в том, что наши продукты безопасны, высочайшего качества и выполнены по всем правилам”.

В свою очередь, компания HCL в официальном заявлении утверждает, что “имеет крепкие и давние деловые отношения с Боинг и гордится работой, которую компания проделала для своих клиентов. Тем не менее, HCL никак не комментирует, какая именно это была работа. HCL никоим образом не связана с текущими проблемами с 737 Max”.

Недавние тесты на эмуляторе, проведенные Федеральным управлением гражданской авиации США, выявили, что проблемы с софтом лежат на более глубоком уровне. Акции компании на этой неделе упали в цене, после того как регуляторы обнаружили проблему с микросхемой, начинающей отдавать критически важные ответы с задержкой, в случае, если она перегружена запросами.

Разработка 737 Max началась 8 лет назад, и работавшие над ним инженеры жаловались на давление со стороны менеджеров. Выдвигались требования ограничить изменения, потенциально создающие дополнительные издержки.

“Боинг делал всё возможное, всё, что вы только можете себе представить, чтобы сократить издержки, включая перенос разработки из Puget Sound (регион в штате Вашингтон, в котором находятся производственные мощности компании Боинг — прим. перев.), потому, что это обходится слишком дорого”, утверждает Рик Людтке (Rick Ludtke), бывший инженер по лётным испытаниям, уволенный в 2017 году. “Это можно понять, если взглянуть на ситуацию с точки зрения бизнеса. Постепенно, с течением времени, выяснилось, что это ослабило способности инженеров из Puget Sound к проектированию”.

Рабин (Mark Rabin), бывший программист, уволенный в 2015 году, вспоминает, как один из менеджеров на всеобщем собрании заявил, что компания Боинг не нуждается в сеньорах, так как их продукты уже достаточно зрелые. “Я был шокирован, что в зале, заполненном парой сотен преимущественно сеньор-инженеров, нам на полном серьезе говорят, что мы не нужны...”

Типичный реактивный лайнер состоит из миллионов частей, и миллионов строк кода, и Боинг давно уже передал большую часть работы поставщикам, которые просто следуют детальным чертежам.

Начиная с запущенного в 2004 году 787 Dreamliner, компания Боинг стремилась увеличить прибыль, вместо чертежей предоставляя высокоуровневые спецификации, а затем предлагая поставщикам самостоятельно прорабатывать детали. Идея заключалась в “они — эксперты, понимаете, и они позаботятся об этих вещах за нас”, говорит Фрэнк МакКормик (Frank McCormick), бывший инженер по лётным испытаниям, который позднее работал консультантом для регуляторов и производителей. “Это была просто глупость”.

Дополнительной причиной переноса работы за границу являются продажи. Взамен на 11-миллиардный контракт с Air India, подписанный в 2005 году, Боинг обязался инвестировать 1.7 млрд долларов в индийские компании. Это, конечно же, было благом для HCL, Cyient и других компаний, чьи программисты широко использовались в компьютерной индустрии, но еще не были задействованы в самолётостроении.

Rockwell Collins, производящая электронику для кабин самолётов, была одной из первых самолётостроительных компаний, передавших значительную часть своей работы в Индию, где начиная с 2000 года HCL начала тестировать их программное обеспечение. К 2010 году в HCL работало более 400 человек, занятых разработкой и тестированием ПО для Rockwell Collins, в офисах располагающихся в Ченнаи и Бангалоре.

В том же самом году, Боинг, совместно с HCL, открыл так называемый “центр передового опыта” в Ченнаи, заявив, что компании будут сотрудничать “с целью создания критически важного ПО для лётных испытаний”. В 2011 году Boeing добавил Cyient (в то время известный как Infotech) в список своих “поставщиков года” за проектирование, проведение испытаний и разработку ПО для моделей 787 и 747-8, осуществлёнными в другом центре в Хайдарабаде.

Конкуренты компании Боинг также частично полагаются на аутсорсеров. В дополнение к поддержке продаж (о чем упоминалось выше), самолётостроительные компании утверждают, что распределенные проектные группы имеют более высокую эффективность, так как работают круглосуточно. Но аутсорсинг давно стал больным местом для некоторых инженеров Боинга, которые, помимо боязни потери работы, говорят, что это привело к проблемам с взаимодействием между командами и ошибкам.

Московские ошибки


Боинг также расширил центр проектирования в Москве. В 2008 году, во время встречи с главным инженером, ответственным за Boeing-787, один из сотрудников пожаловался, что 18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе, рассказала Синтия Коул (Cynthia Cole), бывший инженер Боинга, возглавлявшая профсоюз инженеров с 2006 по 2010 год.

“Проектирование стало превращаться в дешевый товар”, добавляет Вэнс Хильдерман (Vance Hilderman), соучредитель компании TekSci, предоставлявшей услуги инженеров-контракторов и начавшей терять заказы из-за зарубежных конкурентов в 2000-е годы.

По словам Хильдермана, инженера по безопасности с тридцатилетним опытом, в число недавних клиентов которого входят основные поставщики Боинга, американские компании, занимающиеся авионикой, за последние несколько лет перенесли более 30% разработки своего ПО за границу, в сравнении с всего лишь 10% европейских компаний.

Сильный доллар был залогом привлекательности данной модели. Инженеры в Индии зарабатывали около $5 в час, сейчас это $9 или $10, в сравнении с $35-40 для тех, кто находится в США по визе H1B, добавляет Хильдерман. Но он объясняет своим клиентам, что в реальности низкая цена за час обходится им в $80, из-за необходимости контроля, и говорит, что его фирма частично возвращает заказчиков, которым нужно исправлять баги.

HCL, ранее известная как Hindustan Computers, была основана в 1976 году миллиардером Шивом Надаром (Shiv Nadar) и имеет годовой объем продаж более 8,6 миллиардов долларов. По словам вице-президента компании Сукамала Банерджи (Sukamal Banerjee), HCL — это глобальная компания с 18000 сотрудниками в США и 15000 в Европе, она имеет огромный опыт в области вычислительной техники. И выиграла заказ от Боинга именно поэтому, а вовсе не из-за цены. Он прямо утверждает: “У нас большой опыт в R&D (Research & Development, научно-исследовательские и опытно-конструкторские работы — прим. перев.)”.

Тем не менее, при работе над 787, HCL выставил Боингу замечательную цену — бесплатно, согласно словам Сэма Сваро (Sam Swaro), помощника вице-президента, который предлагал услуги HCL на конференции в Сан-Диего, организованной журналом Avionics International в июне. Он сказал, что компания не брала авансовых платежей за 787 и начала выставлять счета только на основе продаж через несколько лет — «инновационная бизнес-модель», которую он предложил распространить на другие компании в отрасли.

Модель Boeing-787 была введена в эксплуатацию в 2011 году, с опозданием на три года, и превысила бюджет на миллиарды долларов, отчасти из-за путаницы, вызванной стратегией аутсорсинга. Под руководством Денниса Муйленбурга (Dennis Muilenburg), давнего инженера Боинг, который стал генеральным директором в 2015 году, компания заявила, что планирует вернуть в свои руки большую часть работы над новейшими самолетами.

Инженерное болото


Boeing-737 Max стал лидером продаж вскоре после того, как его анонсировали в 2011 году. Но для амбициозных инженеров это было что-то вроде “болота”, говорит Питер Лемм (Peter Lemme), спроектировавший автопилот для Boeing-767, ныне являющийся консультантом. Boeing-737 Max был обновлением конструкции 50-летней давности, и изменения должны были быть достаточно ограниченными, чтобы Боинг мог штамповать новые самолёты как горячие пирожки, с небольшими изменениями для сборочных линий или авиакомпаний. “Для инженера, это не самая лучшая работа”, добавил Лемм.

Rockwell Collins, в настоящее время являющаяся подразделением United Technologies Corp, выиграла контракт на поставку кабинных дисплеев для 737 Max и в своей работе опиралась на инженеров HCL, работающих в Индии, в штате Айова и в Сиэтле. Пресс-секретарь United Technologies отказался прокомментировать данную ситуацию.

Инженеры-контракторы из Cyient помогали с оборудованием для лётных испытаний. Чарльз Лавджой (Charles LoveJoy), бывший сотрудник Боинга, сказал, что инженеры из США вынуждены были каждое утро в 7:30 перепроверять чертежи, сделанные в Индии ночью. “У нас были проблемы с индийской командой. Они выполняли требования, но мы могли бы сделать лучше”.

Многочисленные расследования, в том числе уголовное расследование, осуществляемое Министерством юстиции США, пытаются выяснить, как и когда были приняты критические решения относительно программного обеспечения 737 Max. По словам следователей, во время крушений самолетов Lion Air и Ethiopian Airlines, в результате которых погибло 346 человек, система MCAS подтолкнула самолеты к неконтролируемому пикированию из-за плохих данных с одного датчика.

По словам Лемма, такая конструкция нарушает базовые принципы избыточности, бывшие незыблемыми для нескольких поколений инженеров Боинга. По-видимому, никто и никогда не проверял, как программное обеспечение будет реагировать в данной ситуации. “Это был оглушительный провал”, — сказал он. «Не один человек, а множество людей должны были подумать об этой проблеме».

Боинг также сообщил, что вскоре после начала поставок 737-Max в 2017 году, они обнаружили, что сигнальная лампа, которая могла бы предупредить экипаж о проблеме с датчиком, была неправильно настроена в ПО полётного дисплея. В майском заявлении компании Боинг, объясняющем, почему компания вовремя не проинформировала об этом регуляторов, говорится, что инженеры решили, что это не является проблемой безопасности.

“Генеральное руководство компании”, — говорится в заявлении, — “не участвовало в данной проверке”.

От переводчика: после прочтения статьи я перестал удивляться ситуации в своей отрасли (e-commerce). Если в промышленных гигантах, ответственных за человеческие жизни, такая неразбериха с процессами, то о чем говорить в более мелких конторах. Ну и добавлю, что Блумберг конечно передергивает (сложилось такое впечатление), так как их задача — хайп и просмотры, поэтому написанное нужно делить на два.

Сообщения об ошибках, опечатках и прочих проблемах приветствуются.
Поделиться публикацией

Комментарии 534

    –7
    У суперджетов с двигателями, которые ходят 1-2 тысячи часов вместо 8 — история такого же плана?
      +28
      Это нужно спросить у французов, в суперджете их двигатели
        +17
        Также и Боинг может сказать: «Спросите у индусов, это же их софт»… ;-)
        Как сказано ниже «это проблема приемки»
          0
          Там не только их движки. Их инженеры еще и участвовали в проектировании.
            +2
            Честно говоря, если у них движки такие же, как авто… Я лучше на ТУ полетаю.

            Не знаю, правда ли, но, говорят, французские танки имеют сходную надежность, и до поломки накатывают километров 60-100 — так, что их даже на учения возят только трейлерами, от греха.
              +10
              Ты не поверишь. Танки всех стран мира транспортируют на тралах
                +1
                не поверю, с НВВКУ на полигон своим ходом ездят.
                  +3
                  Невыгодно. Двигатель танка очень сильно больше, чем нужно для передвижения по обычным дорогам, ресурс его ограничен и стоит он на порядок или два дешевле трала.
                    +2
                    дороже
                      +2
                      Я им говорю ходят, и это факт. А они говорят не выгодно. Они параллельно трассе ходят пару раз её пересекая. километров 10 в каждую стороны.

                      Думаю выгода там и в преодолении пересеченной месности: лес, склоны, брод, поле, трасса
                        +3
                        А тут все правы.

                        Невыгодно. Гусеничный движитель — вовсе не образец эффективности. У вполне гражданского, и довольно легкого ГТС-М (двигатель от ГАЗ-66) пробег до капремонта составляет, емнип, 5000 км. Танк и тяжелее, и дороже, и требования к двигателю у него повыше.

                        Но основное назначение танка, как бы странно это не звучало, вовсе не те пятнадцать минут гипотетического боя. Основное назначение танка — боевая учеба, именно ей на танке занимаются долгие годы. А это занятие, как ни крути, связано с расходом моторесурса: чтобы учиться, надо ездить и ездить.
                        Поэтому на полигон своим ходом — тоже оправдано.
                        0
                        А ещё невыходно потому, что потом асфальт после танков перекладывать. Ну и скорость на асфальте у них такова, что движение просто встанет.

                        Да и половину Конкорда французы делали :)
                          0

                          Танки, конечно, разбивают дорогу быстрее, чем колесная техника, а тяжелая колесная техника делает это быстрее, чем легковушки, но если асфальт положен правильно, то периодические проезды современного танка сильно ему не повредят.
                          Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.
                          Единственная причина, по которой танки катают на трейлерах (кстати, если и быстрее собственного хода танка, то ненамного) — высокая стоимость покатушек танка своим ходом, что проистекает из трех составляющих: малый ресурс ходовой части (как у любой тяжелой гусеничной техники), большой расход горючки (как не в себя) и (в мирное время) необходимость дополнительных мероприятий по обеспечению безлпасности движения (танки "забыли" оснастить хорошим обзором для мехвода и сигналами поворота и остановки).

                            0
                            Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.
                            а если разрешённая скорость — 120?
                            В остальном — так и есть.
                              0

                              Во-первых, с такой сеоростью танк и на трейлере не поедет.
                              Во-вторых, движение замедлится, но не станет.

                                0
                                В-третьих, разрешенная скорость 120 — это на дорогах первой категории, а там как минимум две полосы в одном направлении
                                  0
                                  про категории местные не знаю, но на участке 120 3 полосы минимум, местами 4-5.
                                  0
                                  90-100 тягач едет.
                                    0
                                    Да, но у тягача с танком все равно по правилам будет ограничение 70 км/ч.
                                      0

                                      А разве так можно с грузом больше 40 тонн? Правила не запрещают?

                                0
                                Слышал как-то рассказ, как колонну грузовиков, едущую по трассе со скоростью около 80, по полю обогнала колонна танков.
                                  0
                                  Да то байка чья-то. Не бывает танков, которые ездят по пересеченной местности с такой скоростью, да и вообще скорее всего, такой шустрой гусеничной техники не существует. На такое только колёсные машины способны, например, БТР-90.
                                    0
                                    Да наверняка. У танков типа Т-80, Т-90 скорость хода по бездорожью заявлена 50-60кмч. Пусть даже он мог такой достигнуть на ровном поле. Если скорость колонны грузовиков убавить раза в 2 то достоверно получается.
                                    0

                                    Маловероятно. Самые шустрые танки из распространенных по достаточно твердой и ровной поверхности делают до 80.
                                    Так что либо скорость преувеличили, либо спидометр врал (кстати говорят, что спидометры завышают показания скорости, чтобы не превышали).
                                    Или случилось чудо и они встретили Т-15, который может больше 80, но это маловероятно.

                            –2
                            Причём тут танки? У французов Миражи есть, у которых за всю историю у всех моделей 3 или 4 случая отказа двигателей
                              0

                              Ничего против французской техники не имею. Но заявленная вами надежность ИМХО не очень реальна. Откуда такие данные? Катастрофа из-за отказа двигателя и отказ двигателя — разные вещи. Открытую статистику отказов военного самолета сложно представить.

                                +4
                                Точно Mirage? Статистика происшествий с двигателем на Mirage III по ВВС Австралии (второй по численности парк Mirage III в мире):

                                A3-79 — отказ двигателя в полете, самолет потерян, пилот погиб

                                A3-4, A3-18, A3-28, A3-46, A3-52, A3-67, A3-70, A3-82, A3-94, A3-95 — отказ двигателя в полете, самолет потерян, пилот успешно катапультировался

                                A3-97 — отказ двигателя в полете, самолет поврежден, пилот не постардал

                                A3-2, A3-41 — отказ двигателя в полете, пилот успешно посадил самолет

                                A3-63 — разрушение двигателя при опрбовании на земле, пилот не пострадал

                                A3-74, A3-75 — попадание птиц или осколков в двигатель, самолет потерян, пилот успешно катапультировался

                                Итого 15 серьезных происшествий по вине двигателя. И это только один тип и одна страна c 116 закупленными самолетами. А были еще Mirage IV, 5, F-1, 2000 — всего порядка 3500 выпущенных.

                                  0
                                  A3-74, A3-75 — попадание птиц или осколков в двигатель, самолет потерян, пилот успешно катапультировался

                                  Ну тут как бы немного не вина двигателя. Не удивлюсь, если и среди остальных проишествий имеются спорные моменты, связанные с возможной неправильной эксплуатацией.
                                    +1
                                    Случаи попадания посторонних предметов в двигатель в «Итого» не посчитаны, как не относящиеся к делу. В целом двигатели устанавливавшиеся на Mirage какой-то выдающейся надежностью не отличались. Особенно SNECMA Atar 09.
                                    Я всеже думаю что имеется в виду Rafale с M88 у которых ЕМНИП небыло серьезных происшествий по вине двигателей. Но Rafale двухдвигательный и суммарный налет парка не очень большой.
                                0
                                Если завод не напротив полигона — иначе никак, гусеницы разрушают дороги уже за 1 проезд. Достаточно посмотреть на следы после бульдозера, когда он по асфальту проехал. Или надо ставить резиновые накладки, что для парада можно сделать раз в год, но гонять на полигон и назад постоянно — это долго. И не факт что они вообще так умеют.
                                  0
                                  У нас от НВВКУ до полигона ходят параллельно трассе через поля. Пару раз трассу пересекая. Километров 10 так проходят )
                                    0
                                    У нас близко к полигонам спец. ветки ЖД были, от неё уже бетонка проложена. Из гражданских дорог раздалбыванию были подвергнуты только пара кусков по паре сот метров в военнородке (ничего сильно плохого им, если мне память не изменяет, от этого не стало, возможно, это всё та же бетонка, закатанная асфальтом сверху). В месте разгрузки — здоровенный пандус-перрон тоже бетонными плитами покрытый, на длину нескольких вагонов, чтоб техника прямо с платформ могла съезжать на дорогу. Потом в некоторых местах ЖД и платформы разобрали, и никто там больше танков не видал, лет 10 уж как. А такое пацанве счастье было! Но кое-где инфраструктура осталась, что как бы намекает.
                                    +4
                                    Если завод не напротив полигона — иначе никак, гусеницы разрушают дороги уже за 1 проезд.

                                    Как житель Донецка, могу сказать однозначно: это миф. Танки и САУ, конечно, оставляют царапины на асфальте, но никакого сколь-нибудь заметного вреда ему не наносят. Наверное, если взять полуразвалившуюся дорогу без основы, её и размолотят. Но по обычной нормальной городской дороге хоть сто танков проедет, ничего особого ей не делается, кроме вот таких царапин:
                                    pbs.twimg.com/media/BsqqrOsCEAAoc3-.jpg
                                      0
                                      Именно про это я и говорю. Тут явно не сотня проехала, а уже такие повреждения (а они довольно серьёзны — через год будут больше). Теперь представим что сотня танков утром проехала на полигон, вечером назад. И так месяц. И от каждого такие «царапины», выбивающие всё больше из полотна.
                                      Плиты прочнее асфальта, и не подвержены разрушению от воды.
                                        +1
                                        Это проспект Ильича в Донецке. По нему за пять лет их сотни, если не тысячи туда-сюда проехали, без какого-либо ремонта дороги. И это никакие не повреждения, просто поверхностные царапины. Они за день-два просто исчезают, т.к. затираются обычными легковыми машинами.
                                          +2
                                          пять лет ......, без какого-либо ремонта дороги.

                                          Off.
                                          Судя по картинке, у вас и разметка вместе со снегом весной не сходит.
                                          /посмотрел в окно, на переложенные к ЧМ 2018 дороги с колеями, проваливающимся асфальтом и следовыми остатками разметки/.
                                            0
                                            Репетиция парада к дню независимости в Минске (ДН 3-его июля). Царапины эти потом внешне затираются, т.е. перестают выделяться цветом, но поверхность остаётся гребёнкой
                                            image
                                      –2
                                        +1

                                        Затем, что до поля боя еще нужно доехать и это будет совсем не катание до полигона.

                                          +4
                                          Эта статистика художественная, чтобы люди прониклись сочувствием к танкистам. Никаких выводов из нее делать нельзя (и никто в общем-то не делает), особенно о требованиях к двигателю, это средняя температура по больнице.
                                          Как думаете, какое среднее время танка с отказавшим двигателем в бою?
                                            0

                                            Это вроде вообще статистика по боям во время второй мировой войны. С того момента живучесть танков значительно повысилась. Да и пехоты тоже.

                                              +1
                                              Ну и как бы противотанковые средства на месте не стояли. От пушек колотушек с целым взводом обслуги до индивидуального РПГ.
                                              +1
                                              Зачем ему ради 15 минут супернадежный двигатель?

                                              Потому что не каждый бой это Курская дуга, до первого серьезного боя может быть несколько недель маневров, ну и среднее время жизни это как и среднее время пехотинца в бою (которое тоже что-то минут 10), кто-то погибает в первой минуте первого боя, кто-то проходит всю войну от начала до конца.
                                              0
                                              В наших Палестинах танки тоже на трейлерах возят, время от времени вижу их на дорогах.
                                              +1
                                              Это нужно спросить у французов, в суперджете их двигатели

                                              Двигатели SaM146%


                                              Доля НПО «Сатурн» в совместном предприятии составляет 49,84%.
                                              Доля НПО «Сатурн» в общем объёме работ над двигателем SaM146 составляет около 38%.

                                              Пока что списывают на то, что французы не умеют делать камеру сгорания, но, по странному стечению обстоятельств, это — именно та версия, которая устраивает всех. По ещё более странному стечению обстоятельств, о проблемах с двигателем известно только из Ведомостей и их источников: никто из незаинтересованных лиц проверить слив не смог.


                                              Так или иначе,


                                              Нытьё Бочарова Олега Евгеньевича из минпромторга на этот счёт

                                              Мы испытываем мощнейшие сложности, связанные с нашим партнерством с французскими партнерами по двигателю SaM146. У коллег жесткая бизнес-модель и идти на симметричные снижения стоимости владения двигателем они не готовы. Разбирая все проблемы эксплуатации двигателя с региональными компаниями, мы видим, что и они пользуются сложившейся ситуацией, стремятся занять более выгодное для себя положение, в наших спорах с французами. (Фотография очень грустного кота) Мы понимаем, что нам надо создать банк подменных двигателей. Такая программа у ОДК есть. Документацию на полную разборку/сборку двигателей на территории рыбинского завода мы получили. Первый двигатель там уже полностью отремонтирован, то есть, разобран-собран. Вопрос коммерческий – идет торговля, за сколько мы с французами сговоримся. Мы понимаем, что условия, которые они выставляют по покупке/аренде подменных двигателей у компании PowerJet, неприемлемы для российских региональных авиакомпаний. Просто не приемлемы и все. А качество самого двигателя вне гарантийного срока и внутри гарантийного срока, вызывает вопросы по горячей части (горячая часть — французская производственная зона ответственности). С этим двигателем нам все равно жить и дальше. Это решение предшествующих периодов и никто не мог знать, что оно так пойдет. Безусловно, будем мучиться с этим двигателем, пока не произведем свой.


                                              TL;DR: Каким бы плохим двигатель ни был — будете мучаться. О чём вы собираетесь спрашивать французов я не совсем понимаю.

                                                +2

                                                Эти же французы (Safran) поставляют движки для A320 и 737MAX и даже второй знаменит не отказом движка. Так что наверное проблема где-то ещё.

                                                +1
                                                  –1
                                                  «Однако, здравствуйте», прямо. Спасибо за статью.
                                                    –9

                                                    Ещё есть на просторах интернета интересное заявление главы Роснефти о "немного нечестной конкуренции" когда европейские производители занижают ресурс своим двигателям в случае использования для заправки топлива произведённого российскими компаниями.

                                                      –6

                                                      Ссылка на статью про сокращение ресурса производителями https://www.kommersant.ru/doc/3869044

                                                        +22
                                                        Это те компании, которые нефть с хлорорганикой гнали?
                                                        Тогда я понимаю занижение ресурса двигателей, да.
                                                    +2
                                                    У меня есть подозрение, что малый ресурс движков на Суперджете связан с эффектом пылесоса — движки слишком близко к ВПП.
                                                    Общее в истории с Боингом — рост диаметров современных двигателей. Больший диаметр движков требует иных компоновочных решений, на которые авиапроизводители идти не хотят, прибегая к паллиативам (костылям).
                                                      0
                                                      Ваши подозрения в корне неверны.
                                                    +48
                                                    Как-то некорректно сравнивать оплачиваемость специалистов и недотестированность софта.
                                                    Индусы может и написали код точно в рамках ТЗ, но как это отменяет тестирование?
                                                    По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работало, но если софт кривой и написан спецами с зарплатой в 1 миллион долларов в секунду, то как это отменяет кривость софта?
                                                    Имхо, это проблема приемки, а не зарплат.
                                                      +7
                                                      но ведь тесты тоже какие-то спецы пишут
                                                        +24
                                                        По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работало
                                                        Кривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.
                                                        как это отменяет тестирование? Имхо, это проблема приемки, а не зарплат.
                                                        Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.
                                                        Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.
                                                          –3
                                                          Кривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.

                                                          так 9 баксов в час — это не копейка. Если вы не умеете в преувеличение — используйте исходные данные.
                                                          Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.

                                                          вы, видимо, плохо представляете себе правильное тестирование. Это не только юнит-тесты. Это целая методика. Наши тестеры для каждой (намного более простой и менее ответственной, чем самолет) фичи пишут сценарии тестирования, определяют корнер кейсы и т.д. И у нас оно еще (осознанно) далеко от идеала. Потому, что от нашего софта жизни не зависят.
                                                            +10
                                                            вы, видимо, плохо представляете себе правильное тестирование. Это не только юнит-тесты. Это целая методика. Наши тестеры для каждой (намного более простой и менее ответственной, чем самолет) фичи пишут сценарии тестирования, определяют корнер кейсы и т.д. И у нас оно еще (осознанно) далеко от идеала. Потому, что от нашего софта жизни не зависят.

                                                            Задача юнит-тестов — зафиксировать поведение кода, чтобы он не ломался при рефакторинге. А вот проверить правильность работы сложного кода с помощью юнит-тестов попросту нельзя. Но многие до сих пор считают, что 100% покрытие тестами гарантирует правильность работы кода.


                                                            А вот более сложное высокоуровневое тестирование с написанием сценариев, обнаружением крайних случаев — всё это уже требует высокой квалификации тестировщика и его компетенции в смежных областях. Программист, который пилит маленький модуль в большой системе, о которой ничего не знает, не сможет написать интеграционные тесты.

                                                              0
                                                              более высокоуровневые тесты должны писать не те, кто имеет компетенцию в смежных областях, а те, кто имеет компетенцию в более высокоуровневых областях. Кто видит картину шире. Кто принимает код.
                                                                0
                                                                У них так и есть. Инженеры пишут спецификации, а кодеры просто тупо переводят их на язык Си. Юнит-тестировщики проверяют, что поведение кода соответствует спецификациям. Никто не требует от кодеров понимать, как работает автопилот или датчик высоты.
                                                                  +3

                                                                  Инженеры — отдельная тема. Как правило, редко человек бывает одновременно и хорошим инженером, и хорошим кодером. Человек достигает высокой квалификации, если занимается чем-то одним.


                                                                  В итоге проблема заключается не в переводе спецификации в код, а в переводе спецификации на язык, понятный кодеру, потому что если кодер не понимает (да и не должен понимать) спецификацию, то это будет только зря потраченное время.

                                                                    0
                                                                    а в переводе спецификации на язык, понятный кодеру

                                                                    В боинге с этим все было ок, по крайней мере, в те полгода, когда я участвовал в написании юнит-тестов для 787. Спецификации были очень подробными и понятными, и не требовали знаний по разработке авиации.
                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                                        0
                                                                        Это было в 2007 году. Я точно не помню почасовую ставку. Я учился в универе и работал неполный день (как и большинство коллег). Наверное долларов 3-5 в час. Там же была куча посредников, желающих поиметь свой гешефт. Для меня это были очень хорошие деньги, особенно если учесть что альтернативой была работа эникейщиком в больнице за 3500р в месяц. Потом начался кризис и весь наш филиал сократили.
                                                                    +2
                                                                    вы напрасно зацикливаетесь именно на юнит тестах. Этого сильно не достаточно. Нужны более разнообразные тесты на всех уровнях, и этим должны заниматься специально обученные люди
                                                                      0
                                                                      Я ни на чем не зацикливаюсь и сам считаю что юнит-тестов недостаточно. Я всего лишь рассказываю о той области, в которой довелось работать. Как там все проверяется уровнем выше, я не имею представления, но уверен, что как-то проверяется.
                                                                      P.S. У нас в иехархии были люди, которые тщательно проверяли, что юнит-тесты написаны правильно :)
                                                                        –2
                                                                        346 трупов ставят под сомнение ваше утверждение.
                                                                          0
                                                                          ваше утверждение

                                                                          Какое из моих утверждений?
                                                                          Если в реализации ПО оказались какие-то косяки, то, очевидно, на каком-то уровне проверяли недостаточно тщательно. Но это еще не говорит о том, что проверок вообще не было.
                                                                    0
                                                                    более высокоуровневые тесты должны писать не те, кто имеет компетенцию в смежных областях, а те, кто имеет компетенцию в более высокоуровневых областях

                                                                    В идеале компетенция в низкоуровневых вещах тоже должна быть.


                                                                    Кто видит картину шире

                                                                    Так я это и написал.

                                                                      0
                                                                      абсолютно не обязательно. А учитывая невозможность знать все, в идеале человек должен заниматься своим делом.
                                                                  +4

                                                                  Непонятно где производственный выигрыш такой модели — экономите на разработчиках, увеличиваете расходы на тестирование, да еще и сроки проекта увеличиваете, т.к. проходите больше итераций.

                                                                    –1
                                                                    большая управляемость. Найти одного чудо-разработчика, который не лагает очень-очень сложно. Если его переманят — бизнес встанет.
                                                                    А вот такой зерг раш прекрасно масштабируется и работает.
                                                                      +10

                                                                      Видел я такой "Зерг раш". За пару дней до конца спринта завершается тестирование с результатами, что ни один юз-кейс полностью пройти нельзя. При этом команда раздута до десятков человек, суб-команды перекидывают ответственность друг на друга, из-за размеров команды частенько кто-то нужный сваливает в запланированный отпуск, центральный менеджемент мечет молнии но ничего не понимает, т.к. не в состоянии погрузиться глубоко. Неизбежно начинается игра с Заказчиком в "Это было в требованиях, а этого не было".

                                                                        0
                                                                        да, есть такая проблема, но за счет новых архитектурных моделей — разбиения на микросервисы, фронтенд-бекенд и прочее, ну и всяких там аджайлов, получается все больше людей включить в этот хоровод.
                                                                        И все равно это проще, чем найти чудо-разработчика.
                                                                          0

                                                                          Бортовые системы самолёта по тем же принципам работают?

                                                                            0
                                                                            по тем же принципам, что и управление персоналом?
                                                                            Мне кажется, вы как-то не правильно вопрос задали.
                                                                              +1

                                                                              Вопрос: нужны ли все эти микросервисы-фронтэнд-бэкэнд в бортовой системе самолёта?

                                                                                0
                                                                                Там не то что микросервисов нет, там по-моему даже ООП и динамическое выделение памяти стараются не использовать, из соображений что код должен быть максимально отказоустойчивым, чтобы летательный аппарат не упал.
                                                                                  0

                                                                                  Вот поэтому мне и хочется понять, насколько популярные сейчас методы и инструменты разработки подходят под rocket science.

                                                                                    0

                                                                                    Не отказоустойчивым, а выполняемым в реальном времени. То есть программа должна гарантированно выполниться за xx миллисекунд при любых входных условиях. Большее время выполнения равнозначно отказу ПО.

                                                                              0

                                                                              Да, про чудо-разработчика абсолютно согласен. И сложно найти и массу рисков несёт. Нужны крепкие миддлы, выстроенные процессы, железная дисциплина (чему кстати способствуют кажущиеся бессмысленными приседания в Скраме). Но вам понадобится чудо-менеджер, которых наверное еще меньше чем чудо-разработчиков.

                                                                                +1
                                                                                про менеджеров ничего не знаю.
                                                                                Вот только одна проблема: крепкие мидлы остаются мидлами очень ограниченный срок.
                                                                                  0

                                                                                  Это прозвучит не очень красиво, но я в какой-то момент понял что основная часть команды не должна состоять из амбициозных людей. Они действительно стремительно вырастают и улетают из гнезда.

                                                                                    +1
                                                                                    если вы создаете условия для дальнейшего роста и платите в соответствии с квалификацией — с чего бы им улетать?
                                                                                    Другое дело, работодатели любят дуть в уши про то, сколько они в тебя вложили, поэтому ты должен работать за сильно меньшую зп, чем мог бы получать.
                                                                                      +2
                                                                                      если вы создаете условия для дальнейшего роста

                                                                                      в одной команде сложно ужиться нескольким сеньорам. Они хотят либо тимлидить либо принимать общие архитектурные решения, а не исполнять в коде чьи-то идеи.

                                                                                        0
                                                                                        Правильный подход к управлению командой легко решает такие проблемы
                                                                                          0

                                                                                          Такого "правильного" управленца найти еще сложнее чем крутого разаботчика, писал выше.

                                                                            +2
                                                                            А вот такой зерг раш прекрасно масштабируется и работает.

                                                                            Данная статья показывает, что для высокотехнологичных задач зерг раш не работает, а может стоить даже дороже.

                                                                              +3
                                                                              мне больше показалось, что данная статья говорит о том, что кто-то хочет избежать ответственности за счет этой темы, свалив все на индусов.
                                                                        0
                                                                        Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.

                                                                        Абсолютно верно, проблема по существу, в ускорении конкуренции
                                                                          0
                                                                          Не удивлюсь, что тестирование выполняли те же индусы
                                                                          +11
                                                                          Как было сказано в статье, «белые» инженеры задолбались исправлять ошибки «черных». Здесь белые и черные — это условные названия высокооплачивемых спецов и низкооплачивамых аутсорсеров. Если ошибки встречаются 100 раз в день, то гораздо легче пропустить ошибку, чем в случае, когда ошибки встречаются 1 раз в неделю. Так что тут общая отвественность. Хотя конечно, высшему руководству стоило подумать, прежде чем аутсорсить такую важную часть работы.
                                                                            0
                                                                            Хм. Если код пишет аутсорсер, то на выходе должен быть товар, проходящий автотесты, то есть как минимум обеспечивающий затребованный функционал. Кроме того, при хорошей архитектуре не так уж и важно, что там внутри модуля, если на допустимый диапазон входных данных от выдаёт ожидаемые значения. Хоть таблица соответствия на гигабайт. Так что дело не аутсорсерах, «белых» и «чёрных» девелоперах, а в организации процесса.
                                                                              +9

                                                                              Если код проходит автотесты, это лишь означает, что при определённых входных данных он выдаёт соответствующие выходные значения. А вот о правильности код речи идти не может.

                                                                                0
                                                                                Да и само тестирование не исключает наличие ошибки, а лишь снижает вероятность наличия…
                                                                                  0
                                                                                  При этом соответствующие значения совершенно необязательно вообще верны.
                                                                                    +16
                                                                                    Приведу пример из моей практики.

                                                                                    Работал как-то над софтиной, написанной индусами. Прилично удивил кусок кода вида (примерно, на псевдокоде):
                                                                                    function CalculateSomething(int id, ...params...) {
                                                                                      ...
                                                                                      distance = GetOdometer(id)
                                                                                      ...
                                                                                      if (id = 123456) {
                                                                                        return
                                                                                      }
                                                                                      ...
                                                                                      PerformSomeComputations(distance, ...params...)
                                                                                      ...
                                                                                    }
                                                                                    


                                                                                    В отличие от прочих «программистов» компании, я стал в этом коде ковыряться и докапываться до истины — благо базы были доступны. Оказалось, что у одного из клиентов какой-то *удак в графу «показания одометра» у автомобиля с id=123456 забил число вроде 3786731 (если кто не знает — редкий автомобиль может проехать 200'000 миль, не развалившись на запчасти, а тут имелось в виду 37867,31 — но забивальщик отвлёкся и пропустил запятую), соответственно при обработке конкретно этой записи у конкретно этой компании PerformSomeComputations() падала из-за переполнения и рушила всю систему. В нашу компанию пришёл баг вида «у клиента X при обработке автомобиля id=123456» падает система". «А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.

                                                                                    Автотесты код, естественно, проходил…
                                                                                      0
                                                                                      «А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.
                                                                                      Автотесты код, естественно, проходил…
                                                                                      А ревью кода у них отсутствовал как класс? СММ какого уровня у конторы?
                                                                                        0
                                                                                        У меня вопрос, а какого чёрта входные данные не проверяются на стадии ввода?
                                                                                          0

                                                                                          Так данные-то корректные (формально). Просто они оказались неожиданными конкретно для функции PerformSomeComputations().


                                                                                          Мы вот как-то в базе прода "нашли" 78-осный грузовик, и он так же "не пролез" через одну из функций. Означает ли это, что грузовик некорректный?

                                                                                            0
                                                                                            Почти 4 миллиона миль это корректные данные? При том, что для этого автопарка и 200 000 это уже много. Кроме того уверен, что в той базе данных предыдущие показания одометра по данному ТС есть. Там считается, что проехать пару миллионов миль, между событиями учёта, это корректные данные? Кто вообще писал ТЗ и проектировал этот бардак?

                                                                                            >>Означает ли это, что грузовик некорректный

                                                                                            Зачем Вы подменяете понятия? Вопрос не в грузовике, а отсутствии контроля входных данных при импорте/входной форме, это же грёбаные азы.
                                                                                              0

                                                                                              Тут мы упираемся в парадокс кучи: где та граница, ниже которой значения еще реальные, но свыше которой ни одна машина ни одного километра проехать не может?


                                                                                              Почему вы даже не рассматриваете вариант, при котором функция PerformSomeComputations должна работать с любыми числами?


                                                                                              Или тот вариант, при котором она должна на них падать, но не рушить при этом всю систему?

                                                                                                0
                                                                                                Кто вообще писал ТЗ и проектировал этот бардак?

                                                                                                Компания называлась ADP — гигантский когломерат, производящий автоматизацию всего и вся. Я в то время работал в подразделении, которое автоматизировало (вернее, привносило зачатки big data в) работу автосалонов. Подразделение почти целиком состояло из индусов. :) Дело было лет 12 назад, тогда код-ревью и проч. ещё не были buzzwords.


                                                                                                Кроме того уверен, что в той базе данных предыдущие показания одометра по данному ТС есть.

                                                                                                Одной из характеристик выставленных на продажу б/у автомобилей как раз и является пробег — он фиксируется, когда продавец привозит машину на продажу, и, естественно, не меняется, когда машина стоит на продажной площадке. Поэтому предыдущих значений нету.

                                                                                            0
                                                                                            У меня был пассат с пробегом около 300к км по одометру, на момент моей покупки он уже был сломан и больше не считал, а я ещё хз сколько накатал. То есть моя машина не может быть внесена в вашу базу без скручивания?
                                                                                              0
                                                                                              у вас 300 тысяч, а в комментарии выше речь идет про 3 миллиона.
                                                                                        0
                                                                                        если 100 ошибок в день — значит тестить надо еще тщательнее. Значит, двое должны ревьювить. Или трое. Все-таки самолет делают.
                                                                                          +15
                                                                                          А в чем тогда смысл аутсорсинга, если код одного индуса будут проверять два высококвалифицированных инженера? Может тогда пусть они и пишут?
                                                                                            +11

                                                                                            Пример работы эффективных менеджеров в действии.

                                                                                              0
                                                                                              не одного, а сотни. И пишет он неделю, а проверяют час. По хорошему, значительную часть работы в виде покрытия тестами аутсорсы сделают сами.

                                                                                              а что, код белого человека проверять не надо? Он ошибок не совершает? А это, повторюсь, самолет.
                                                                                                +4
                                                                                                И пишет он неделю, а проверяют час

                                                                                                В том-то и дело, что не час. Это же самолёт.


                                                                                                По хорошему, значительную часть работы в виде покрытия тестами аутсорсы сделают сами.

                                                                                                Юнит-тесты не проверяют правильность кода. А более высокоуровневые тесты индусы писать не смогут.

                                                                                                  0
                                                                                                  так все равно эти тесты нужны. Даже если самых-присамых лучшие кодеры будут это писать.
                                                                                                    +2

                                                                                                    Они нужны, но решают другую задачу.

                                                                                                  +2
                                                                                                  Где-то я читал, что в коде SQLite 95%, что ли, занимают тесты и только 5% — код самой базы. Так что в самолетостроении очень может быть, что сам код занимает значительно меньше, чем тесты, а затраты на тестирование больше затрат на разработку — отчего бы и нет
                                                                                                    +1
                                                                                                    В случае системы с большим количеством возможных состояний и большими рисками при ошибке тестирование легко может занимать гораздо больше времени чем разработка. Причем временами — на порядок больше. И это даже не касаясь юнит тестов.
                                                                                                  0
                                                                                                +10

                                                                                                Чем больше и разнообразнее опыт инженера и чем лучше он знает для чего он пишет софт и как это работает не только программно, тем меньше вероятность получить комплексную проблему на выходе (а к пуговицам то претензий нет), но такой инженер стоит, обычно, немного дороже, работает, часто, медленней, в общем пока гром не грянет — сплошные убытки :)
                                                                                                p.s. наблюдаю такую картину постоянно, кусочки работают по регламенту и по т.з. а в сумме то тут то там что-то идёт не так...

                                                                                                  +3
                                                                                                  Чем больше и разнообразнее опыт инженера

                                                                                                  В данном случае дело даже не в опыте. Специфическая для индийских хм… «инженеров» (а равно и программистов в инженерных доменах) проблема закладывается еще во время учебы, и отлично описана Фейнманом в его известной книге. Конечно, там место действия — Бразилия, НО. Удивительным образом все совпадает до деталей. Поэтому не буду плодить сущности и просто процитирую (извиняюсь за размер)

                                                                                                  Но потом я спросил, можно ли, имея всего один кусок поляроида, определить, в каком направлении он поляризует свет. Они совершенно не представляли себе. Я знал, что это требует известной доли находчивости, поэтому я подсказал: «Посмотрите на залив. Как от него отражается свет?» Все молчат. Тогда я сказал: – Вы когда-нибудь слышали об угле Брюстера? – Да, сэр. Угол Брюстера – это угол, отражаясь под которым от преломляющей среды, свет полностью поляризуется. – В каком направлении свет поляризуется при отражении? – Свет поляризуется перпендикулярно плоскости падения, сэр. Даже теперь я не могу этого понять. Они знали все наизусть. Они знали даже, что тангенс угла Брюстера равен показателю преломления! Я сказал: «Ну?» По-прежнему, ничего. Они только что сказали мне, что свет, отражаясь от преломляющей среды, как, например, воды в заливе, поляризуется. Они даже сказали, в каком направлении он поляризуется. Я сказал: «Посмотрите на залив через поляроид. Теперь поворачивайте поляроид». – О-о-о, он поляризован! – воскликнули они. После длительного расследования я, наконец, понял, что студенты все запоминали, но ничего не понимали. Когда они слышали «свет, отраженный от преломляющей среды», они не понимали, что под средой имеется в виду, например, вода. Они не понимали, что «направление распространения света» – это направление, в котором видишь что-то, когда смотришь на него, и т.д. Все только запоминалось, и ничего не переводилось в осмысленные понятия. Так что, если я спрашивал: «Что такое угол Брюстера?», я обращался к компьютеру с правильными ключевыми словами. Но если я говорил: «Посмотрите на воду», – ничего не срабатывало. У них ничего не было закодировано под этими словами.

                                                                                                  Вот это нынешняя система технического (= не гуманитарного) образования в Индии как она есть.

                                                                                                  +8
                                                                                                  Пример кода специалиста с оплатой в 1 копейка в сутки:

                                                                                                  bool value;
                                                                                                  if(value.ToString.Length() == 4)
                                                                                                  return true;
                                                                                                  else if(value.ToString.Length() == 5)
                                                                                                  return false;

                                                                                                  else
                                                                                                  return !true && !false;

                                                                                                  Приемка тестирует функцию — она работает? работает.
                                                                                                    0

                                                                                                    И что в ней может привести к падению самолёта?


                                                                                                    Кроме ошибок аллокации памяти в ToString, которыми, имхо, можно пренебречь при данных вводных.

                                                                                                      +2

                                                                                                      Например если toString выбросит NPE

                                                                                                        0

                                                                                                        А почему там NPE может быть?

                                                                                                          0

                                                                                                          Потому что, согласно спецификации, работа toString гарантируется только на корректных входных данных, а здесь на вход пришли неинициализированные. На корректных тестах всё работало. Undefined behavior, однако.


                                                                                                          Это, конечно, была ирония. Протестировать тестами полностью всё невозможно — два int' а во входных данных уже дадут де-факто бесконечное время для перебора.

                                                                                                            0

                                                                                                            Если бы там данные были неинициализированные, то эта функция и для обычного сравнения упала бы, разве нет?


                                                                                                            Но я C#, считайте, не знаю, мне правда интересно.

                                                                                                              0

                                                                                                              Тут разве что оом может упасть при попытке строчку выделить, но это такое.

                                                                                                                –3

                                                                                                                Неинициализированный bool нормально сравнится, оба if будут ложными либо сравнение на true будет заменено компилятором на "не ноль". Дальше если оптимизатор вырезал "недостижимый" код, то все плохо, иначе сработает последний return и всё хорошо.


                                                                                                                toString для bool можно сделать как return constantStrings[boolValue], которая полагается на то, что bool превращается в 0 или 1. Неинициализированный, соответственно, даст выход за границы массива и там можно схватить вообще что угодно, NPE в том числе. Но тут надо будет старательно завернуть всё в unsafe и выкрутить оптимизатор.

                                                                                                                  +2

                                                                                                                  В C# не бывает "неинициализированного" bool.

                                                                                                                    0
                                                                                                                    Даже если передать указатель на структуру с bool в очень плохой unmanaged код?
                                                                                                                      0

                                                                                                                      Да.

                                                                                                                        0

                                                                                                                        Да, даже в этом случае. В результате в bool может оказаться мусор — но это все равно будет инициализированный мусор.

                                                                                                                    –3
                                                                                                                    Но я C#, считайте, не знаю, мне правда интересно.
                                                                                                                    Хвала Аллаху, что подобные системы ещё не докатились до шарпа.
                                                                                                              +2
                                                                                                              А, зачем вообще String и динамическое выделение памяти в ответственных местах?
                                                                                                              Такой код, скорее всего не пройдет по стандартам.
                                                                                                                0

                                                                                                                Это другой вопрос, и я поэтому и сказал сразу, что проблемами возможного недостатка памяти пренебрежём — это сразу в целом, вообще, совсем другой класс процессов разработки и подходов к коду.


                                                                                                                Может, там, кстати, small string optimization, хехе.

                                                                                                                  0

                                                                                                                  small string optimization тут ни при чем, если это и правда C# имелся в виду — то там все строковые литералы интернированные (так же как и в Java, Javascript и Python). А результат bool.ToString() должен быть именно литералом (нет никаких причин делать иначе).

                                                                                                                0

                                                                                                                ИСТИНА/ЛОЖЬ — и мы поворачиваем не в ту сторону.

                                                                                                                  0

                                                                                                                  Почти, но мимо. В C# не предусмотрена локализация для типа bool.
                                                                                                                  Только "True", "False".

                                                                                                                    0

                                                                                                                    Почти, но мимо. В C# ToString() — функция, а не свойство.
                                                                                                                    PS. А Length — наоборот, свойство.

                                                                                                                      0

                                                                                                                      Вы вообще о чём?
                                                                                                                      bool.ToString() возвращает всегда либо "True", либо "False".

                                                                                                                        0

                                                                                                                        ToString != ToString().


                                                                                                                        На случай, если не видели исходного комментария:


                                                                                                                        bool value;
                                                                                                                        if(value.ToString.Length() == 4)
                                                                                                                        return true;
                                                                                                                        else if(value.ToString.Length() == 5)
                                                                                                                        return false;
                                                                                                                        
                                                                                                                        else
                                                                                                                        return !true && !false;
                                                                                                                          +1

                                                                                                                          Слишком похоже на опечатку. Вводить код в textarea не очень удобно, и компилируемость кода при этом автоматически не проверяется...

                                                                                                                +7
                                                                                                                Последний return — впечатляет :-D
                                                                                                                  0

                                                                                                                  Более того, если это переписать на С++, компилятор все равно оптимизирует что индусятину, что прекрасный код. !true && !false точно уйдет.

                                                                                                                    0
                                                                                                                    >!true && !false точно уйдет

                                                                                                                    А в шарпе что будет?
                                                                                                                      0

                                                                                                                      Своя, шарповская магия ;) Я о том, что процессор выполняет совершенно не тот код, который написан в текстовом редакторе.

                                                                                                                    +1

                                                                                                                    Источник. Сколько получает автор кода – там не указано.

                                                                                                                      –1
                                                                                                                      Я думаю, что в этой области применяют, всё-таки, фортран
                                                                                                                      +21
                                                                                                                      Рецепт быдлокодеры+тестирование=хороший софт является в корне ошибочным.
                                                                                                                        +2
                                                                                                                        Осталось донести эту мысль в головы владельцев заводов, газет и пароходов. Ну или Итшных галер для начала.
                                                                                                                          0
                                                                                                                          А, в чем проблема то для них? Владельцы заводов, пароходов, «галер»..., и так получают прибыль.
                                                                                                                            +2
                                                                                                                            В том-то и дело что для них это не проблема, пока деньга капает, а пипл хавает. Плюс к этому эффект короткого горизонта планирования в стиле отчитаться перед годовым собранием акционеров, на крайняк перед SEC и FBI, а потом хоть потоп.
                                                                                                                              +2
                                                                                                                              боинг больше не получает.
                                                                                                                              Самолеты не летают. Предзаказы отменены. Новых контрактов на авиасалоне не заключено.
                                                                                                                            +5
                                                                                                                            В России так же дороги делают. Отдают на аутсорс подрядчикам. Те в свою очередь еще одним, а те находят команду, готовую работать за еду. К сожалению, это во всех сферах так.
                                                                                                                            +3
                                                                                                                            Согласен. Главное, проблема была в единственном сенсоре который отвечал за стабилизацию, без резервирования. Качество разработчиков, ИМХО, тут не причем.
                                                                                                                              0
                                                                                                                              Там было резервирование сенсора. Но реализовано криво.
                                                                                                                                0
                                                                                                                                В том-то и беда, что их (датчиков угла атаки) два, и при расхождении данных с них MCAS выбирает большее значение.
                                                                                                                                +1
                                                                                                                                halted вам нужно своими глазами посмотреть хотя бы на 1 проект, сделанные индусами. Вопросы отпадут сами собой.
                                                                                                                                Т.е. то что вы говорите — верно, но только если пишут не индусы.
                                                                                                                                  +4
                                                                                                                                  поправлю вас — «сделанные дешевыми индусами». Я работаю сейчас с «дорогим» индусом, который эмигрировал из Дели в Финляндию, он пишет код намного чище и лучше большинства наших разработчиков.
                                                                                                                                    +3
                                                                                                                                    поправлю вас — «сделанные дешевыми индусами».

                                                                                                                                    Может, следует поправить сразу до "сделанных дешевыми программистами"? И даже не "дешевыми", а просто "плохими"?

                                                                                                                                      0
                                                                                                                                      Всё-таки есть разница между теми, кто сидит в бангалоре и теми кто вырос из бангалора и сумел трудоустроиться в Европе или Штатах.
                                                                                                                                      У нас тут тоже завелись индусы, и их всё больше. Жду когда нас призовут переходить с С++ на Яву
                                                                                                                                    +3

                                                                                                                                    Как проверить, что функция, перемножающая два числа и делящая результат на третье, работает всегда корректно? Кроме "открыть, почитать, подумать", я другого способа не вижу. Можно скормить ей произвольные данные, но это будет вероятностный тест. Вдруг внутри этой функции какое-то значение промежуточного результата используется как код ошибки? Это отсылка к функции MulDiv из winbase.h.

                                                                                                                                      0

                                                                                                                                      Для этого есть языки с автоматическим доказательством теорем. В таких, например, невозможно получить ошибки типо деление на ноль. От ошибок в бизнес логике, впрочем, это не защитит

                                                                                                                                        0

                                                                                                                                        Осталось только узнать, умеют ли среднестатичтические индусы а ATS.

                                                                                                                                      +9
                                                                                                                                      Цена за час — это просто объяснение, почему отдали в индию. Речь не об этом.
                                                                                                                                      Речь о том, что люди, которые выползли из трущоб не могут мыслить широко и глубоко, иначе они бы не жили там десятилетиями. А те, кто могут, уверяю вас, уже давно там не живут и работают далеко не за 10, а может даже и не за 40 в час.

                                                                                                                                      Качественно протестировать код тоже стоит денег и хороших инженеров. Кстати если брать метрики за строчки кода (да, такие встречаются), то протестировать строчку кода стоит примерно в 2 раза дороже (в часах), чем её написать.
                                                                                                                                      Например у меня была история с одним самолетом. Было, казалось бы, пустяковое изменение — изменение частоты процесса в 2 раза. Это не подразумевало никаких других изменений в коде и тестах, а тесты стали падать (т.к. их требовалось просто перепрогнать). Весь модуль был давно написан и протестирован (угадайте с одной попытки — кем ;)). Но даже когда он попал к нам, специалисты уровня Middle не смогли даже подступиться к причине на первом этапе.

                                                                                                                                      Чтобы не раздувать пост, скажу только что были требования, был код, написанный четко по этим требованиям, и тесты, которые, о боже, тоже написаны по требованиями. Проблема была в том, что требования были неоднозначны.
                                                                                                                                      За полтора года за не сколько итераций удалось привести требования в нормальный вид, и тесты заодно. Почему так долго? Потому что вместо того чтобы плавно и аккуратно исправлять косяки на следующей итерации они выкатывают один CR за 2 дня до дедлайна, в котором «запилены» все непонятные_им_проблемы_в_виде_костылей. Инженер, который не принимал участие в тестировании этого модуля сразу упадет в обморок. Человек с опытом будет громко кричать что это всё г****но и надо переделать, но большинство его замечаний будет проигнорировано. Там по большому счету надо было пару месяцев плотной переписки, чтобы всё привести в порядок. А когда это 2 дня раз в 5 месяцев… ну сами понимаете.
                                                                                                                                      А вот код не успели, потому что сертификация закончилась и времени и бюджета на исправление косяка в одну строчку уже не было, хотя первый раз я им ткнул на эту строчку за подлгода до дедлайна.

                                                                                                                                      К чему это я…
                                                                                                                                      А к тому, что даже очень опытный и дотошный тестировщик не имеет нормальных возможностей убедить разработчиков исправить косяк до того, как этот код начнет перевозить пассажиров. В тех реалиях, которые есть на данный момент.
                                                                                                                                        +4

                                                                                                                                        Вот так оно и есть. Вся эта возня с делегированием задач оправдывает себя, если работник обладает собственными разумом. Индусу сказали копать — он и копает, не загружая мозг посторонними задачами.


                                                                                                                                        Вы составили ТЗ, индус что-то написал в точном соответствии с ТЗ. Но тут внезапно оказывается, что то, что для вас очевидно, для индуса не является таковым. В итоге ТЗ выполнено, но на выходе совсем не то, что вы ожидали. Поэтому приходится уточнять ТЗ и отправлять на доработку и т.д. Но у вас нет времени на переделку, поэтому в какой-то момент просто принимаете работу в том виде, в котором она есть.


                                                                                                                                        Чтобы индус написал нужный код, придётся скрупулёзно составлять ТЗ, расписывая всё до самых мелочей. И в какой-то момент окажется, что накладные расходы на делегирование задачи окажутся выше, чем решение задачи собственными силами. И если в случае штатных сотрудников такое оправдано (сотрудник наберётся опыта и станет более автономным), то в случае аутсорса каждый раз нужно начинать всё с нуля.

                                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                          +3
                                                                                                                                          Дима, привет! с тех пор, как ты от нас ушел, в индустрии все изменилось еще дальше в худшую сторону :)

                                                                                                                                          Что касается исходной статьи, ты прав, в целом она — «плач Ярославны» про то, что хороших американских инженеров заменяют в пропорции 1 к 5 на неопытных инженеров из Индии (собственно, большая часть статьи — слова бывших/уволенных инженеров), что со временем должно привести к плачевным результатам (тут я согласен, и, некоторым образом, жду отложенного эффекта). Даже такая пропорция не позволяет компенсировать опыт, необходимый в авиационной индустрии для разработки новых устройств, хоть и позволяет значительно сэкономить.

                                                                                                                                          При этом, если почитать другие статьи по теме MCAS на том же Блумберге, можно увидеть, что основная проблема как раз не в софте — он мог вполне отработать согласно разработанным системным/функциональным требованиям.

                                                                                                                                          Ошибки, скорее, оказались заложены еще на уровне разработки системы (стандарт ARP-4754A), и, что еще точнее, на уровне проведения анализов отказобезопасности (ARP-4761).
                                                                                                                                          В тех самых других статьях писали, что изначально система MCAS должна была компенсировать кабрирование самолета (задирание носа) на малых скоростях из-за изменения расположения новых двигателей под крылом и изменение направления их вектора тяги, при этом за раз она могла уменьшить это самое задирание носа на 0.5 градуса.

                                                                                                                                          Функционал устройства был согласован с экспертами отказобезопасности FAA и ему был назначен уровень критичности B по стандарту DO-178C (собственно, устройство не приводящее к катастрофе в случае отказа, но при этом уже возникают вопросы — как даже для уровня б разрешили снимать данные с одного датчика угла атаки...).

                                                                                                                                          Ну и далее пошли совсем странные вещи (ручаться не буду, рядом совсем не стоял, но пишут): эксперты FAA были изрядно завалены работой, поэтому анализ отказобезопасности они делегировали инженерам Боинга, «тут-то им фишка и поперла» — устройство неожиданно стало «исправлять» задирание носа не на 0.5 градуса, а на 2.5, при этом делать это не один раз, а много раз, последовательно, что сделало возможным катастрофические последствия, которые и реализовались (если не ошибаюсь, в первом случае отказал датчик угла атаки, во втором — там что-то провода отсоединились от датчика из-за тряски на взлете).

                                                                                                                                          Т.е. по факту — разработчикам спустили какие-то требования, может быть ни их реализовали правильно, проверить их тоже могли вполне полностью и хорошо, но кто из разработчиков кода или тестов задумывается, почему один из выходов изменил диапазон рабочий с 0.5 до 2.5? Нет таких в принципе, эти должны заниматься писатели системных требований и safety engineer, который и делает анализ отказобезопасности.

                                                                                                                                          В целом же, по ситуации можно сказать следующе — боинг давит всех своих поставщиков последние несколько лет очень активно на предмет снижения стоимости поставки устройств и сервисов, те вынуждены снижать издержки за счет дешевого аутсорсинга (это все-таки из разрешенных методов), вынуждены объединяться для противостояния давлению боинга (RCI + UTC + (возможно) Raytheon) и т.п.
                                                                                                                                          Боинг, в свою очередь, возвращает разработку некоторых устройств, в частности Flight Control, FBW и т.п. внутрь себя, тоже сокращает собственные издержки за счет увольнения опытных и найма пачек неопытных и так далее. В целом, в индустрии идут довольно сильные изменения, которые снаружи могут быть не так заметны.
                                                                                                                                            0
                                                                                                                                            Как ужасно! Полное разложение нормальной инженерии!
                                                                                                                                          –8
                                                                                                                                          Совершенно согласен с вами, к тому же в этом сквозит скрытое презрение к другому миру. В последнее время часто замечаю эту родовую проблему капитализма — отсутствие госнадзора за действиями капиталистов, к тому же «менеджеры» губят любое технически сложное дело на корню своими «оптимизациями», базирующимися на невежестве. По сути, Боинг следовало бы отдать хотя бы на время под госнадзор, жесточайший, и заставить пересмотреть параметры испытаний любых систем.
                                                                                                                                            +4
                                                                                                                                            Боинг и так находится под надзором FAA. Так что как мы видим госнадзор тоже не панацея.
                                                                                                                                              0
                                                                                                                                              Боинг не находится под надзором FAA.

                                                                                                                                              Там жесть жестяная. Фактически, 737 «сертифицировался» не FAA, а самой корпорацией Boeing.

                                                                                                                                              FAA «делегировала полномочия по сертификации» разработанного тем, кто это разрабатывал.

                                                                                                                                              www.nytimes.com/2019/03/26/us/politics/boeing-faa.html

                                                                                                                                              medium.com/@alexlee611/faa-delegates-aircraft-certification-to-boeing-and-yet-they-recorded-the-best-safety-record-ever-e72fc38af274
                                                                                                                                                +3
                                                                                                                                                Официально Боинг находится под контролем FAA. И то что FAA делегировала контроль кому-то другому, а точнее самому Боингу, сути дела не меняет.
                                                                                                                                                Потому что точно так же любая другая госконтора может «делегировать» надзор за Боингом кому-то другому, в том числе и менеджерам самого Боинга :)
                                                                                                                                                  0
                                                                                                                                                  … джентельмен джентельмену верит наслово, и тут мне такая масть пошла!
                                                                                                                                            +4
                                                                                                                                            Я работал (правда, недолго) тестовщиком кода для Боинга 787, когда был студентом.
                                                                                                                                            Код реально писали индусы (у нас был доступ к VCS с историей коммитов), и да, код был плохим. При том, что на каждый маленький модуль было четкое описание, что он должен получать и отдавать, они умудрялись написать код, не соответствующий этим требованиям.
                                                                                                                                              0
                                                                                                                                              А как с тестированием там было?
                                                                                                                                                0
                                                                                                                                                Тестированием чего?
                                                                                                                                                Мы не разрабатывали код, мы только писали юнит-тесты на готовый код, сами же их прогоняли и в случае каких-то несоответствий с документацией писали репорты по установленным образцам. Все это перепроверялось старшими, а потом отсылалось на уровень выше. Что там дальше с этими репортами происходило, я не знаю, но обычно потом ошибки фиксились в новых ревизиях. Я был всего лишь джуном на аутсорсе, и у меня естественно не было полной картины происходящего.
                                                                                                                                              0
                                                                                                                                              IMHO это проблема менеджмента компании, а точнее тех, кто делает следующие заявления:

                                                                                                                                              “Генеральное руководство компании”, — говорится в заявлении, — “не участвовало в данной проверке”.


                                                                                                                                              один из менеджеров на всеобщем собрании заявил, что компания Боинг не нуждается в сеньорах, так как их продукты уже достаточно зрелые.


                                                                                                                                                0
                                                                                                                                                А вы работали с индусами на аутсорсе?

                                                                                                                                                Мне вот довелось — врагу не пожелаю. Описывать элементарную задачу пришлось несколько раз и в конечном варианте я написал спеку… которою можно было копипастить в код… что они и сделали наделав еще и ошибок.

                                                                                                                                                Нет, я допускаю что мне не повезло с конкретными индусами, но только они работали на подряде у автомобильного гиганта с мировым именем.
                                                                                                                                                +63
                                                                                                                                                Правильный заголовок:
                                                                                                                                                Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими 98 280 рублей в месяц


                                                                                                                                                И уже не так резко звучит для российских программистов, особенно вне мск-региона, верно?
                                                                                                                                                  +1
                                                                                                                                                  вроде же софт писался когда доллар был по 30р
                                                                                                                                                    +9
                                                                                                                                                    Окей, для 2010го года следует читать так:
                                                                                                                                                    Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими 45 360 рублей в месяц
                                                                                                                                                    Много российских программистов в 2010м получали 45 000?
                                                                                                                                                      +3
                                                                                                                                                      Т.е. размер зарплаты освобождает от ответственности за жизни людей? Посыл получается именно такой.
                                                                                                                                                        +28
                                                                                                                                                        Нет, не освобождает. А посыл звучит типа «ваша жизнь зависит от джунов, потому что на сеньорах и даже миддлах мы решили сэкономить».
                                                                                                                                                          –1

                                                                                                                                                          Размер нет, а сложная схема передачи ответственности вполне может спасти головы в руководстве, но всё зависит от уровня возникших проблем. Моё личное ИМХО если бы вторым самолётом оказался самолёт American airlines, уже бы не один человек считал годы до окончания срока...

                                                                                                                                                            +1
                                                                                                                                                            а много гениев и даже просто скрупулезных спецов пойдут на такую зп?
                                                                                                                                                            0
                                                                                                                                                            Думаю зп 45тыр в 2010 для спецов 2-3 года после вуза это минимум для города 1млн человек. сейчас около 90 наверное.
                                                                                                                                                              +11
                                                                                                                                                              Либо вы живете в какой-то другой реальности, либо не в России.
                                                                                                                                                                0

                                                                                                                                                                в 2013 я устроился на 15 тысяч полставки (от 30), студентом-третьекурсником с 0 опыта. 45 тысяч через 2 года после вуза более чем реально. ХОтя конечно, может 2010 и 2013 сильно отличаются, не знаю.

                                                                                                                                                                +2
                                                                                                                                                                2019 год на дворе. Город 2+ млн человек. Скоро 20 лет после вуза. Недавно прилетело предложение «инженер Линукс, от 50тыр». И это было бы хорошее предложение (если бы компания вызывала хоть малейшее доверие, что такую зарплату действительно заплатят).
                                                                                                                                                                0
                                                                                                                                                                Насколько помню, я в 2010м в Перми примерно столько и получал.
                                                                                                                                                                Если сравнивать с однокурсниками, это было чуть ниже среднего. Но зато было интересно )).
                                                                                                                                                                  +1
                                                                                                                                                                  Ну и минус ~40% налогов, надо полагать. Всё-таки в РФ обычно считается з/п после вычета всех налогов, так что ~27к рублей.

                                                                                                                                                                  Ну и опять же, мы не знаем, сколько из этих $9 в час забирал аутсорсер. Программисты же компании-заказчику обходились в $9 в час. Если аутсорсер ещё минимум 30% забирал, то всё вообще плохо. Хотя в оригинале статьи и написано, что это был именно доход разработчиков, но кто знает.
                                                                                                                                                                    0
                                                                                                                                                                    много
                                                                                                                                                                  +6
                                                                                                                                                                  Проблема не в сумме зарплаты сотрудника, а в том, что не только разработка, но весь цикл проектирование-разработка-тестирование-приёмка проводился в компании, которая никогда не делала отказоустойчивые системы.
                                                                                                                                                                  Если взять разработку в самой Boeing, где есть инженер, заложивший дублирование, тест-писатель, описавший известные ему и компании случаи отказов в тестах, и менеджер, который не примет код до того, как он пройдёт тесты — то да, можно заменить разработчика на дешёвого. Будет ли дешевле час работы сотрудника за $50 или неделя возни и возвратов индусу с $9 — другой вопрос.
                                                                                                                                                                  А если вся задача делегирована людям, которые, условно, раньше делали софт уровня 1С — то ТЗ будет выглядеть как «типа надо компенсировать недостаток манёвренности», тесты буду выглядеть как «взлетаем, не хватает управления, триммирование включается, всё хорошо начальникама» — разработчик ПО (который, в отличие от менеджера и инженера, не обязан хоть что-то знать про самолёты) мог написать с первого раза идеальный код, который на 100% делает ровно то, что описано в ТЗ.
                                                                                                                                                                  Но ТЗ неадекватно требованиям к подсистемам в авиации. В этом и проблема, насколько я понял — в делегировании проектирования целых подсистем в компании-подрядчики
                                                                                                                                                                    +22
                                                                                                                                                                    Суть не в уровне зарплат, суть в заголовке, который за бугром еще можно назвать кричащим, но у нас этот заголовок звучит еще хуже, чем если бы статью опубликовали в Индии.

                                                                                                                                                                    Т.е. грубо говоря у нас заголовок преобразуется в:
                                                                                                                                                                    «Аутсорс программисты с позорно низкой зп выше чем у вас написали говнокод для Boing»
                                                                                                                                                                      +11
                                                                                                                                                                      Я на всякий случай хочу уточнить, что статью переводил совершенно не ради заголовка, он такой же, как в оригинале.

                                                                                                                                                                      Мне знакома изнутри ситуация, когда компания сначала зарабатывает себе имя и репутацию, растёт, и в какой-то момент оказывается, что заказов набрали больше, чем возможно выполнить. И менеджмент принимает решение воспользоваться контракторами, стажерами, вообще всеми подряд, лишь бы побольше и подешевле.
                                                                                                                                                                      Что, в свою очередь, приводит к снижению качества, потере репутации, ухудшению продаж, увольнениям и в конце концов к коллапсу.

                                                                                                                                                                      Да, у Boeing запас прочности большой, но вот этот «эффективный менеджмент» и погоня за краткосрочными прибылями точно до добра не доведёт.
                                                                                                                                                                        +18
                                                                                                                                                                        Так вот и умирают или загнивают монополии. Большие зарплаты и возможность «карьерного роста» привлекают халявщиков карьеристов. Те быстро смекают, что качество работы отходит на второй план, уступая человеческим отношениям. Специалисты, работающие на совесть, в итоге разбегаются и работать становится просто некому. Остаются вруны и дармоеды, которые рисуют красивые цифры на графиках, не имеющие ничего общего с реальностью. Реальные продажи падают, конкуренция проиграна, компания стагнирует или волочит существование на вторых ролях
                                                                                                                                                                          +1
                                                                                                                                                                          Поставил бы плюс, если бы мог. Похожая ситуация сейчас у Интел. Десятилетиями компания купалась в деньгах, однако, вместо того, чтобы продолжать интенсивно крутить педалями, просто зажралась. И теперь приходится глотать пыль азиатских тигров, которые уже давно освоили 7нм техпроцесс.
                                                                                                                                                                            +2
                                                                                                                                                                            Полностью соглашусь на счет Intel. У компании исторически очень сильные позиции на рынке ПК, но вот в мобильном рынке они отстают колоссально. Интел выпускает процессор с компоновкой big.LITTLE в начале 2019. Китайский MediaTek сделал это в 2013. Есть слух, что и процессорах для ПК у Intel не все так безоблачно. AMD со своим Ryzen потеснил Intel с первых строчек бенчмарков. Но это еще не самое плохое. Плохо настанет тогда, когда Apple откажется от процессоров Intel на Macbook. А слухи такие уже ходят, что яблочники разрабатывают собственный процессор, как это было в случае с PowerPC (кто еще помнит)