Статья была опубликована 24 июня 2008 года, но несмотря на свою древность она очень показательна. В ней есть госзаказ, попил средств, бюрократия и эффективный менеджмент во всей красе. А написана она не про Россию, а про Францию.
***
Несколько лет назад меня пригласили консультантом по одному проекту ПО для крупной французской технологической компании. Увиденное выходит за рамки всего, что я мог представить в разработке. Простое отсутствие профессиональной компетентности оказалось не самым худшим. Гораздо хуже было крайнее презрение к человеческому достоинству, что показалось мне сравнимо с тюрьмой в том виде, как я её представляю. Вот список, проверьте сами.
Масштаб.
- разработка программного обеспечения для государственного агентства.
- сложность низкая, с несколькими вывертами.
Правительство платит авансом несколько миллионов евро. План разработки на два-три года. Для начала компания нанимает несколько разработчиков и продолжает удваивать размер команды каждые три месяца или около того, осваивая бюджет по мере поступления средств.
7 лет спустя проект ещё не оформился. Набегают штрафы по несколько тысяч евро в сутки. Руководство решает сократить расходы и производит увольнения опытных сотрудников, нанимая людей с небольшим или нулевым опытом работы.
10 лет спустя, учитывая катастрофическое состояние проекта, менеджмент среднего звена решает нанять некоторых людей с опытом разработки, чтобы вернуться в график. Средняя текучка среди новичков: три месяца. Это минимальный срок, чтобы иметь право уволиться во Франции.
12 лет спустя проект ещё не закончен. Компания снова попадает на ежедневные штрафы, выставляя новые счета правительству за постоянно растущий поток запросов на изменение. Идёт 2008 год.
Цифры.
- 6 миллионов строк кода
- На основе C++
- Более 50 000+ классов
- Конкретная версия C++ устарела, но привязана к компилятору, который распространяется только с одной (не поддерживаемой) операционной системой
- На основе CORBA
- СУБД от компании-банкрота
- Несколько слоёв поверх друг друга для обработки GUI, ни один из которых фактически не поддерживается авторами
- Сборка занимает 48 часов на 32 параллельных машинах
- От 40 до 50 одновременных процессов для запуска только пользовательского интерфейса
- Отсутствие динамического связывания библиотек: размеры исполняемых файлов начинаются с нескольких сотен мегабайт
- Время запуска программы: около 15 минут
- Среднее время между сбоями: от 30 секунд до 30 минут
Ни один разработчик не скажет, что C++ - простой язык. Наоборот, один из самых сложных. На самом деле он настолько сложен, что даже его создатели признаются, что ещё не овладели всем. См. признание Страуструпа в его знаменитом "интервью", которое сочинили как розыгрыш.
Столкнувшись с таким невероятным лабиринтом бездонной сложности, люди реагируют по-разному. Все гики-выскочки слышали о C++ и хотят доказать, что тоже могут на нём программировать. Они бесстрашно погружаются - и получают увечья до неузнаваемости. Тратят бесчисленные часы, пытаясь понять, почему куча абракадабры бесконечно крашится без видимой причины. У кого есть разум - те быстро уходят на другие языки и другие проекты. Жизнь слишком коротка.
Поддерживать крупный проект сложно независимо от языка. Только представьте, что сотрудникам нужно поддерживать 6 МИЛЛИОНОВ СТРОК кода - и вы получите представление о том, как далеко может зайти безумная разработка. Шесть миллионов - большое число. Если читать по одной строке в секунду, то вы просидите перед экраном семьдесят дней без перерыва.
Для понимания масштаба расскажу два случая.
Одному разработчику поставили задачу проверить, почему нажатие правой кнопкой мыши в интерфейсе полностью подвешивает приложение. После нескольких дней тщательного изучения и невероятного количества терпения он обнаружил, что щелчок правой кнопкой мыши работает нормально, просто контекстное меню появляется примерно через 45 минут. Все меню динамически генерируются из кучи (статического!) контента при каждом нажатии правой кнопкой мыши в главном окне.
В какой-то момент пользователи сообщают, что вообще не работает опция "Загрузить данные с CD-ROM". Потребовалось несколько недель, чтобы разобраться. Но в итоге баг-репорт пометили как "Решён ранее", потому что данные загружались корректно. Разве что загрузка 700 МБ занимала семь суток. Но терпение - это добродетель.
Управление версиями пошло вразнос.
Прошло несколько лет, прежде чем одному смышлёному парню в команде пришла идея использовать инструменты для управления версиями. Первая попытка не слишком получилась, так что команда переключилась на другую систему. А через пару лет - на третью, теряя всю историю с каждым переходом.
В итоге выбрали инструмент-катастрофу с GUI. Мерзость, исходящую непосредственно из Швеции. Пришлось выделить на полный рабочий день команду из четырёх человек для выполнения большинства задач в этой системе. Выглядело примерно так:
- Для первого извлечения кода (checkout) следовало назначить встречу с командой контроля версий. Встречу обычно назначали через неделю.
- Редактирование файлов не разрешалось без разрешения менеджеров среднего звена. Вы должны заранее сообщить своему менеджеру, какие файлы хотите отредактировать, а затем отправить официальный запрос на получение разрешения, который команда управления версиями может рассмотреть в течение нескольких дней.
- Каждая модификация кода запускает ветвление. Это значит, что потом нужно объединить все полученные модификации. С таким количеством файлов в хранилище вы можете подумать, что редко встретятся два человека, работающие над одним и тем же файлом. Но оказалось, что большая часть работы идёт над теми же 100 файлами или около того.
- Возврат (check-in) проходит через болезненную процедуру, когда ваш код проверяет автоматическая программа для обнаружения ошибок, а потом менеджеры. Нечего и говорить, что с таким подходом ошибки плодятся быстрее, чем их успевают исправлять. Внимательный взгляд на количество зарегистрированных ошибок показал, что на каждое исправление появлялось две новых ошибки.
- Управление версиями вообще простое. У старой программы - первая версия, у сегодняшней - вторая, у будущей - третья. Никто не может сказать, какую версию отправили заказчику.
(От себя добавлю, что описаный выше процесс, это просто ужас. Системы управления версиями для того и нужны, чтобы разработчики в любой момент могли редактировать нужный код. Если изменение кода требует написание предварительного запроса за 1 неделю, то работа не сдвинется с места. И если проект занимает 6 млн. строк кода, а основная работа ведется в 100 файлах, то никакая система управления версиями не поможет)
В какой-то момент была назначена официальная дата выпуска, совершенно оторванная от планов команды. Когда пришёл день, клиенту фактически отправили пустой компакт-диск с инструкциями по установке, потому что никто не смог собрать софт в течение нескольких недель. Клиент узнал, что ему прислали пустой диск, официально пожаловался - и получил старую версию. Он узнал об этом, потому что отображаемая дата в поле "О программе" оказалась такой же, как и в прошлом году.
Кадры.
С таким большим количеством народу вообще без опыта разработки ПО разве удивительно, что ошибки плодились в огромном количестве? Какой-то особо одарённый менеджер выяснил, что затраты на персонал - главные затраты в проекте чистой разработки ПО. Совсем не испуганный этим необычайным открытием, он решил уволить всех людей хоть с каким-то опытом, но сохранить всех менеджеров. Было не редкостью видеть книжки "C++ для чайников" на столах многих сотрудников.
Познакомьтесь с командой - 20 разработчиков, 35 менеджеров. Вы не ошиблись: менеджеров больше, чем реальных разработчиков.
Менеджеры продолжают организовывать встречи, где они снова и снова показывают одну и ту же презентацию PowerPoint AD до отвращения, в то время как разработчики убивают время, болтая в огромном офисе открытого типа.
Немногие менеджеры имеют опыт работы в индустрии ПО. В то время как раз SCO судилась с IBM по поводу Linux. Даже если всё было блефом, но реально действовало на всех этих людей, которые понимали, что скоро придётся платить за свободные программы. Никто из них никогда не упоминает "Software Libre", но все они знают о "Software Gratuit". Излишне говорить, что проект напичкан библиотеками GNU, а эти ребята понятия не имеют, что так проект становится совместимым с GNU. Хотя ладно, учитывая ужасное качество этого кода, никто никогда не будет настаивать, чтобы они открыли исходники.
Технические знания ниже плинтуса. Мало кто знает об интернете. Те, кто знает, думает, что он создан для порно. Упомянете, что вы что-то видели в интернете — и вам начнут подмигивать и улыбаться.
Добро пожаловать в ад.
Всё это было бы забавно, если бы высшее руководство не вело себя как нацисты в концлагере. Просто приведу несколько примеров.
- Запрещено приходить на работу после 9 утра. Однажды старший менеджер стоял перед главными воротами и тут же увольнял всех, кто пришел после 9:01. Под раздачу попали в том числе ряд менеджеров и продажников.
- Курильщики берут больше перерывов, поэтому меньше работают. Руководство попыталось заставить всех бросить курить по приказу. Не получилось.
- Кофе-машины регулярно выходят из строя на несколько дней. Те, кто пьёт кофе, меньше работают, чем те, кто неотрывно сидит за своим столом, набирая драгоценные строки кода.
- Те же кофе-машины выключают всякий раз, когда чиновники приходят в офис, чтобы создать впечатление, что все на работе.
- Туалеты самые отвратительные, какие я видел в жизни. Вероятно, идея заключалась в увеличении производительности: чем меньше времени вы тратите в туалете, тем больше (и лучше) работаете.
Наверное, вы задаётесь вопросом, зачем же люди продолжали приходить на работу в такое место. Первой и главной причиной стал глубокий экономический кризис, который переживала Франция в то время (и до сих пор, в определённой степени, переживает). Наличие работы и заработной платы считается привилегией, независимо от условий.
Другая причина заключалась в том, что для многих это была первая работа. Без какого-то сравнения невозможно оценить, насколько ваша работа отстой. Большинство новичков считали совершенно нормальным, что вынуждены приходить ровно в 9:00 или быть уволенными, когда абсолютно ничего не накладывало такого ограничения, кроме больного ума менеджера.
Что касается того, как правительство позволяет подобное: мы все знаем, как это работает. Ребята, отвечающие за бюджет в министерстве, дружат с топ-менеджерами в ряде компаний. В такой стране, как Франция, коррупция не редкость на этом уровне, она в основном не раскрывается и редко преследуется по закону. Видимо, это относится не только к Франции. Я слышал такие же истории из других мест Европы и из США.
В следующий раз при мысли, что твоя работа отстой - подумай еще раз.
Комментарии
Наличие работы и заработной платы считается привилегией, независимо от условий.
ключевое, увы
Сам был удивлен этой фразой, потому что считал, что период 1996 - 2008 был нормальным для экономики Франции.
Спасибо.
Но, понимаете, 25 рабочих и 35 управленцев - ЭТО НОРМАЛЬНО.
Это НЕИЗБЕЖНОСТЬ, это то вырождение профессианализма, как непременное условие существования капитализма в ЛЮБЫХ сферах деятельности. Посмотрите на верхушку айсберга - госдеп, брюссельских гномов и парламенты гейропы. А ведь это, так называемая элита.
Классика, однако.
Извините, но история неправдоподобная. Такого не может быть. Одно или два из описаных девилизмов - ещё ладно, но вот так всё вместе в одной фирме, и она столько лет просуществовала и не пропала? Не верю. Ну и есть технические неточности и глупости. Данные не грузятся с CD-ROM, a потом выяснили что грузятся нескольно часов? А что, никто не догадался посмотреть, мигает ли лампочка на драйве?
Если есть завязки на верху, это может длиться годами. Я про Россию. Не думаю что за бугром по другому.
Это всерьез написано?
Капитализм в данном случае вообще не при чем, ибо речь о госконтракте. Это был попил, а не капитализм. А внутри попила может происходить любой лютейший треш.
"Капитализм в данном случае вообще не причем"
Это вы расскажите Королёву, мотавшему первый срок.
Не понял, что вы хотите сказать.
Королев сел за то что по окончанию срока проекта деньги были профуканы, а телеуправляемой торпеды страна не получила.
Великобритания - тоже самое. Работаю в этой же индустрии, архитектором крупнейших веб платформ для очень крупных веб проектов (Manchester City, EasyJet, HSBС, Metropolian Museum of Art - это все я сделал).
Распилы на менеджмент чудовищные - по сути размытие отвественности. Они не то что бесполезные - они контрпродуктивные. Постоянно ТБМывают моимх работнкв своими бессмысленными планерками репортами и проч единственный смсыл которых лишь в оправдании смысла существования всего этого менеджерсокго слоя. На моем текущем проекте этого слоя больше 50% (!!!). При том что сейчас как и львиную долю я работал именно в частном секторе (который по идее должен считать деньги) но все равно такой ужас. А что же происходит в государственном?
Бывает.
"*Вася, привет! Как дела?
*Привет, Федя. Помнишь, в прошлую нашу встречу ты утешал меня и говорил, что жизнь, как зебра?
*Помню, конечно! Ну и как, черная полоса кончилась?
*Нет, Федя. То была белая полоса."
Путин его тоже рассказывал
Нет. Ключевое - количество менеджеров. Проблема даже не в том, куда идут основные деньги проекта, и что сил не хватает. Проблема в том, что организация по достижению критического количества менеджеров катастрофически теряет ориентиры и вообще всякую связь с реальностью. После достижения критической массы оных становится просто бесполезным говорить о каких-то реальных улучшениях проекта (в коде, в организации, в компиляции) - организация начинает жить и думать в других терминах.
Из личного опыта: я работал в одной конторе, которая писала софт и сдавала его в аренду. Аренда покрывала разработку новых версий, плюс что-то там капало акционерам сверху. Но контора перешла Порог и совершила этот фазовый переход. Там начало твориться много странного (проще сказать, чего странного там не творилось), но апофеозом и кульминацией было назначение нового СЕО, который сразу после прихода подметил интересную (и ужасную!) вещь: прибыльность конторы маленькая, потому что денег от аренды мало, а на разработку тратят много.
Поэтому нужно было сделать что? Во-первых, вместо аренды продать продукт клиентам (приток денег за год внезапно вырос в десятки раз!). Во-вторых, сократить 80% разработчиков (расходы снизились в 5 раз!). Чувак это сделал под аплодисменты всей управленческой братии - реально, резко и просто разрулил годами мучавшие контору проблемы (реально! аплодисменты!). Он получил свои премиальные проценты - 10 миллионов за год и ушёл.
Потом внезапно оказалось, что сдавать в аренду софт больше некому - его ж купили, а продавать больше нечего - разработчиков-то уволили. И более того, даже обслуживать проданное нереально - разработчиков нет, и ушли по некоторым вопросам ключевые люди, кроме которых никто ничего в коде не понимает... Но то же такое, внезапное, верно ведь? Ситуация на рынке изменилась, всё такое...
...
Всё это было бы невозможным в адекватной конторе. Но в конторе, в которой преобладает 100% управленческий персонал и которая теряет непосредственную связь с реальностью, это прошло на ура.
Я, кстати, на этом офигительно поднялся - потом ещё два года в частном порядке работал удалённо на покупателей софта, на поддержке, фиксе мелких багов и т.д. Работа - не бей лежачего.
Но чем кончила контора - вполне понятно.
Максимальный срок планирования коммерческой организации определяется сроком контракта его руководителя. А количество менеджеров всегда пропорционально сложности предприятия. Не потому что сложно, а потому что позволяет распылить ответственность. При финансовом целеполагании, здравый смысл лишний. Оптимальным решением всегда является максимум прибыли сейчас при минимуме ответственности. Отсюда и вся "управленческая динамика".
Хорошая история. Мне кажется у любого мало-мальски опытного разработчика найдется пара такиже.
Я регулярно уже во многих конторах наблюдаю потерю связи у руководства с реальностью. Как пример, была контора, небольшая группа программистов, пара продажных менеджеров. Группа программистов делала продукт, его более-менее продавали. Пока не пришел один хороший по тому времени контракт. После реализации и получения денег, случился в руководстве бзик. Решили что контора на новом уровне, надо нанимать еще менеджеров и разработчиков, а старый продукт внешним видом устарел и его надо бы переделать. Вместо того, чтобы поднять зарплату старшему программисту, и посадить его регулировать проект, сказали что ему хрен, а мы наймем настоящего руководителя. Руководителя нашли, тот нанял еще программистов. Штат разросся в несколько раз. Сам руководитель прекрасно умел чесать языком, создавал впечатление что работу может организовать любую, но в программировании был дуб-дубом. Это был какой-то аля прораб из строительной конторы. Старым программистам на которых контора и держалась, сказали хотите - валите, вас есть кому заменить. Поскольку новых программистов нанимали за большие деньги, а старым оставили зарплату заметно ниже рынка, большая часть старых программистов уволилась.
Ожидалось что разработка нового софта займет полгода, провозились полтора, деньги кончились, проект накрылся медным тазом, нанятый руководитель-прораб купил себе машину и ушел. У руководства сложилось о нем очень положительное впечатление, мол, вот человечище! То что он не сделал нихера почему-то никого не удивляло.
Параллельно этому балагану был нанят КОНСАЛТИНГ. Т.е. руководство наняло левых людей, что бы те рассказали им как в их теме надо вести бизнес и увеличивать прибыли. Консалтинг долго за деньги думал, и разработал новые правила в конторе:
-была разработана методичка "Миссия компании", роздана каждому сотруднику.
-был сильно увеличен штат менеджеров, и нанят над ними отдельный начальник.
-каждый новый сотрудник при приеме на работу должен был рассказать всем, кто он такой, чем занимается, о чем мечтает. Т.е. на полном серьезе вся контора собиралась в круг, он становился в середину и рассказывал. Я такой-то, жил там-то, родился там-то, не женат, люблю то-то, мечтаю о возвышенном.
-ввели правило написания отчетов. Каждый должен был за день в процентах расписать, что он делал целый день. Типа написание кода 20% времени, тестирование 30% и тд.
Консалтинг на этом закончился, за исключением одной тетки, которую тут же пригласили на работу в контору, перекупив у консалтинговой фирмы :)
В общем с таким руководством контора в настоящий момент темой уже не занимается. Осталось три с половиной калеки, разработки нет. Гендиректор ее сбросил на заместителя.
Вы думаете, что подобный алгоритм мудачества существует только в IT? Да ни хрена! В самых что ни на есть кондовых индастриалах то же финансиалистско-менеджерское порно. Вот это ключевая позиция сценария:
Именно эффективный и сравнительно быстрый выход с обварным кэшем является целеполаганием таких топов.
Резкий рост фин. показателей любыми самыми чудовищными средствами и менипуляциями с умопомрачительными, но несколько отдаленными последствиями, получение премиальных в процентах от "экономии", и быстренькое увольнение по соглашению сторон с выходными бонусами ("ну я вам уже тут все настроил, даже неловко такую большую зп продолжать получать, а дальше сама, всё сама...").
Имя им легион (с)
Добавлю. Отсюда.
Был очень серьёзный бизнес, и был у этого бизнеса очень серьёзный проект. Под проект выделили бюджет, согласовали требования, назначили ответственных и приступили к его осуществлению.
Через полгода с момента старта проекта уже значительно затянули сроки внедрения, а руководители всевозможных рангов оживлённо переписывались в стиле: «Какого @#$? Разобраться и обеспечить!» Наконец проблемой заинтересовался и самый большой босс, который вызвал на ковёр представителей бизнеса и представителей исполнителя: заместителя от бизнеса, заместителя от ИТ, руководителя проектов, руководителя подпроектов, руководителя проекта от заказчика, начальника отдела разработки, двух методологов, архитектора системы и трёх менеджеров проекта. Начались взаимные упрёки и обвинения, каждый из участников был изобретателен и имел в запасе набор железобетонных отмазок.
Самый большой босс обвёл усталым взглядом всю честную компанию и задал вопрос:
— Сколько программистов сейчас участвует в проекте?
— Трое.
— Вы хотите сказать, что нас здесь двенадцать начальников на трёх программистов? Вопросов больше нет, все свободны.
На следующий день «свободными» в полном смысле слова стали восемь человек из двенадцати присутствующих, а на их место дополнительно наняли пятерых разработчиков. Надо ли говорить, что через месяц отставание было ликвидировано, а ещё через месяц проект стартовал?
Это большой босс адекватный попался. Прямо на удивление.
Такие боссы встречаются реже единорогов.
Недавно был на совещании заказчик\ подрядчик\субподрядчик где 12 менеджеров минут 20 обсуждали сможет ли выйти один плиточник на работу такого то числа, если известно что ему еще надо доложить столько то квадратных метров кафеля на другом объекте. Дальше еще смешнее, плиточник вышел, но разуклонку пола сделала не в ту строну, менеджеры не проконтролировали. Опять совещание, 12 менеджеров пытали одного проектировщика как теперь сделать слив воды. Объясняли ему бестолковому что он дебил и не может решить элементарную проблему.
гос контракт берут не чтоб заработать, а чтоб вытянуть по максимуму денег
У них негров линчуют, поэтому наши там плохие дороги не так и глаз портят))
Ключевое в этой статье - это работа менеджмента. Здесь не надо разделять Россию и Францию, потому наши менеджеры учатся по западным учебникам.
Ключевое здесь - прибыль! а то, что в итоге ничего не получилось - издержки. Капитализм ))
Страна где это происходит значение не имеет. Такое может произойти везде где в конкретном случае менеджер победит инженера. Создание сложного программного продукта ещё та смоленая яма.
+++++
Всего-то надо менеджмент в стойло ставить.
Да где ж эта волшебная палочка.
Не только лишь все разработчики способны постичь значение систем сборки.
РСКВ — следующий этап.
Они наверное везде исключение. Однако, случись такое в России, стали бы сразу говорить о русском характере, о нашем историческом раздолбайстве.
Что касается менеджера всех увольнявшего, так его понять можно. Сами ж пишете, что менеджеров было с избытком, делать им было нечего, а показать свою нужность хотелось. Вот и предавались идиотизму. Ну и сокращение издержек опять же требовалось, так то ведь сам не уволишь, тебя уволят.
Вот поэтому и счел нужным разместить эту статью.
Интересно что они там такое так долго писали. 50 000 классов это круто. Одно оглавление где искать описание будет занимать толстенный том в 700 страниц. Я до этого думал что Arcgis с его 1000 классами это много.
Автор этой статьи указал, что сложность самого ПО была низкой. Видимо изначально построили неправильную архитектуру, с которой в последствие не смогли справиться.
В этом то скорее всего и дело. Вроде просто ну и решили в лоб решить. Сделали. А тут приходить заказчик и говорит что всё классно но не могли бы вы добавить ещё вот это. Слепили костыли. А это. Ещё костыли и так далее. Я в таком случае через пару лет просто взял и переписал всё заново. Но у меня сроков не поджимали.
И в процессе всего этого разогнали специалистов и набрали новичков, которые даже С++ не знали. Вряд ли они были способны простой рефакторинг сделать, не говоря уже о новой функциональности.
Думаю, 50000 классов означают, что каждый в своей части делал себе собственные классы. В результате там было 50 классов String, 50 Point и т.д. А выражаемых ими концепций - 1000.
Кстати, 6 млн строк / 50 тыс классов = 120 строк на класс. Это максимум, если совсем не было свободных функций.
Наверное. Может что бы не редактировать старый класс, создает новый с добавлением нужного интерфейса. Или проще создать новый чем искать гигабайтах кода нужный.
Это уже само по себе требует высоко квалифицированных программеров. В сочетании с работниками на 3 месяца катастрофа практически неизбежна.
Здесь явная ошибка в изначальном проектировании.
см. выше
Ещё один привет от С++. Они, похоже, не разбили проект на отдельно компилируемые части. "И так сойдёт" .
См. выше. А на что они рассчитывали, запихав весь код непосредственно в исполняемый файл / файлы?
Меня больше всего поразило, что код проекта занимал 6 млн. строчек, а основные работы велись всего в 100 файлах. В такой ситуации нельзя работать - никакая CVS, никакой менеджмент не поможет.
Ну, тут надо понимать, что там за 6 млн. Точнее, сколько там уникального кода. Если среди них, к примеру, 90% - это "позаимствованные" GNUсные, единожды добавленные и никогда не исправляемые, то терпимо. Если же, к примеру, 5 млн строк правят в 100 файлах, то беда.
50 000 строк в одном файле? Многовато но в принципе терпимо. Только не понятно зачем?
Нахер так жить. Открыл файл, начал читать код, чтобы понять что там делается, к вечеру дошел до середины, закрыл. Утром пришел на работу и все по новой. Невозможно удержать в голове столько информации. Вообще такая фигня происходит у тех, кто привык к функциональному программированию: запихнуть все в один класс в один файл.
....
/*
"Война и Мир"
....
....
*/
....
Что ни говори, а работа с микроконтроллерами дисциплинирует: ресурсы закончатся раньше, чем успеешь дров наломать.
Читал, что раньше специально объявляли неиспользуемый массив данных. Когда проект был более-менее вылизан, но памяти все равно не хватало, то этот ненужный массив удаляли и был успех. Сейчас пользуются такими приемами?
Идея хорошая, но, по крайней мере, на моей работе (дочка Боша) так не делают. К счастью, у нас количество инженеров всё же значительно превышает количество менеджеров, да и начальники отделов в большинстве своём из инженеров.
Цена микроконтроллеров низкая, память дешевая, требования к функционалу устройств на МК все повышается и повышается. Таким образом, вылизыванием кода уже никто не парится, и если не хватает ресурсов, просто берешь более мощный камень.
Дисциплинирует, но замедляет разработку. После embedded практически всегда при разработке начинаешь заниматься "ранней оптимизацией" и уже на этапе продумывания архитектуры думать, где её упростить или ужать.
Веб-разработчиков это подбешивает :)
Есть такое :) Я после контроллеров привык например, если число небольшое выделять под него байт. Зачем больше? Но регулярно нарывался на замечания, типа зачем ты тут используешь байты, памяти что ли мало? :)
Ну, с учётом того, что компилятор может выровнять поля структуры под 32 бита, да и процессор с большой вероятностью в кэш или регистр не один байт затащит, выделение по одному байту - жлобство, иногда не оправданное. :)
Страницы