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

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

Этим людям не хватило простой перегрузки стандартных функций языка (malloc & free) которые они сделали.
Вторым уровнем абстрагирования стало создание структуры указателей с определенными именами, в которую записаны были указатели на новые функции заменившие стандартные.
Дальше больше, после создания такой вот системы, они написали верхний уровень интерфейсов с помощью еще одной перегрузки, теперь уже на вызовы по указателям.
А потом сверху написали общий интерфейс уже фуникционально пожерживающий работу с памятью.

Так вот - никогда так не делайте. Хватит с вас одной перегрузки - максимум двух уровней абстрагирования.
Когда пишите код - уважайте труд тех, кто будет в нем разбираться.

Вот и отпустило немного на работе, в свзяи с чем продолжим.

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

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

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

Работаешь работаешь, а оно как бумкнет.
Прямо как в мульфильмах.
Сначала приходят с одной конторы, и долго рассказывают какой же у них заебательский прибор. Вставляется в нужный слот, подключается их любимый драйвер, затем просто тупо пользуешься их интерфейсом, вуаля, простите мой французский, нихера не работает.
Хотя нет, работает, иногда.
Затем приходят другие. Эти просто предоставляют материалы и обещания.
Материалы так же точно соответствуют документации, как и документация не соответствует нашим требованиям. Т.е. абсолютно.
Обещания тверже камня, сроки красивые, вполне себе подходящие.
По прохождении срока даты меняются, красноречивые обещания продолжаются, и так в цикле до тех пор пока не сделаем.
Надоедает быстро.

Берем третьих, все еще проще. Драйвер написан для мультиплатформ. Прекрасно собирается и работает при минимальных усилиях.
Затем некие неустойки с рабочей скоростью, медленно перетекают в отсутствии возможности делать все, что объявлено и написано. Вернее, делать можно, но очень медленно, как в прибалтике.

А потом, потом в драйвере поставщика находится баг. Баг чинится, и в процессе сего действа растет увернность, что незаметить сие безобразие они просто не могли.
Баг с готовой версией починености посылается поставщику. В ответе содержится фраза, которую приведу в очень близком переводе на русский.
Итак внимание:
“Спасибо вам за решение этой проблемы. Да. мы знаем, что такой баг есть, мы обходим его в программе с помощью специального резервирования особого места в памяти, где баг не проявляется. Мы обязательно включим ваше решение в нашу поставку”.

Ощутите великое благородство сего автора.

Если вы думаете, что я это сочинил, вполне могу привести названия фирм и типы картисов с которыми работаю по индивидуальному каналу связи.
И это, кстати, абсолютно нормальная практика работы в хай-тек фирмах. Особенно в маленьких.
Вопрос на засыпку, стоит ли платить деньги за лицензию?

Во что превращается программист во время конца срока разработки?
В механическое чудо с красными, от кофе, глазами. В зомби, которого дети видят либо на фотографиях, либо по телефону.
Вы видели еще более неблагодарное занятие, чем проверка работы всех режимов программы за 2 дня? И не увидите. Зато потом начальство благодарно пожмет руку.
Надо переквалифицироваться в дворники.