- последна редакция на: 2017-11-02
Машинно зависим срещу машинно независим софтуер
Дефиниции
Машинно зависим софтуер наричаме този, който е свързан или разработен във връзка със специфичен хардуер. Такъв софтуер работи само с този тип устройство или устройства. Софтуер, който е машинно зависим, не може да бъде лесно преработен за употреба/управление на друг тип хардуер. Този процес обикновено изисква значителни модификации или дори пренаписване на оригиналната програма. Компонентите, които са написани за конкретно устройство, работят правилно само с правилния модел устройство.
Машинно независим софтуер наричаме този, който работи с даден логически тип устройства, независимо от конкретния модел. Дадена програма, която е написана по този начин - не трябва да се притеснява за модела на хардуера, с който работи и не се нуждае от преработка, но в краен случай, ако се наложи то тя е несъществена. Софтуера, разработен по този начин трябва да съдържа в себе си информация за значителен по обем характеристики и възможности на устройствата, с които работи.Предимства и недостатъци
Информацията по-долу е резултат на личния ми опит при разработката на софтуер, свързан с управлението на POS устройства. Не забравяйте, че мнението ми е субективно и е напълно възможно да не съм прав, но все пак е резултат от седемнадесет годишен опит в същата област.
Оценка по отношение на скорост
- Машинно зависимите програми се произвеждат значително по-бързо. Причината е, че машинно независимите програми са всъщност пакет от няколко слоя, като само един от тях е машинно зависим. Дори и да няма неизвестни в технологията и опита, чисто технически изработката им е по-сложна и отнема повече време и усилия;
- Като цяло, машинно зависимите програми работят малко по-бързо с даденото устройство, защото няма междинни звена за “превод” от машинно независимата логика на програмата към конкретното устройство и обратно при отговора на устройството, ако има такъв;
Поддръжка
- Поддръжката на програма, написана специално за даден тип устройство е по-принцип по лесна от поддръжката на програма, която работи с десетки устройства. Ако обаче в последствие се окаже, че точно тази програма трябва да поддържа повече от един модел, то работата Ви по доработката и съответната поддръжка ще върви към кошмар със скорост, която зависи от броя устройства и степента на тяхното различие. Когато Ви възлагат подобна работа - питайте! Това ще Ви спести изключително много нерви и усилия впоследствие. Ако Вие разработвате собствено решение - спокойно можете да започнете още от самото начало с идеята, че ще поддържате повече от едно устройство. Светът ни е такъв, че ако проекта е жиснеспособен - той ще се промени дори и ако Ви се струва, че хардуера, който сте измислили е идеален;
- Когато говорим за машинно независима програма, написана съобразно с даден стандарт - поддръжката в дългосрочна перспектива е значително облекчена. Както ще видим по-нататък наличието на стандарт, описващ и изискващ информация за определен набор характеристики и възможности от страна на драйверите на различните модели, води до значително облекчаване при внедряването и поддръжката на нови устройства.
Подходи при разработката на машинно независим софтуер
Следващото изречение ми е любимо с безсмислието и очевидността на информацията, която носи. При разработката на машинно независим софтуер, може да се подходи по различни начини. Истината е, че мнозинството от хората обичат да чуват очевидни изречения и ако не им ги казваш, защото са очевидни - те имат за особняк, надут или за темерут и въобще разговора не потръгва добре. През годините съм открил, че когато някой Ви попита за нещо очевидно, всъщност е по-добре да си загубите от времето и да му отговорите без да изтъквате очевидността на отговора. :Просто е по-добре за бизнеса, а и не всички знаят очевидните за Вас неща. Точно както съм сигурен, че в деветдесет и девет процента от случаите, четящите тези редове не знаят повечето от очевидните неща при отглеждането на брокули.
Нека все пак да се върна към подходите при разработка на машинно независим софтуер.
- Софтуера Ви ще бъде резултат от сечението на всички налични характеристики и възможности на устройствата. Ако става дума за SDK, възможно е списъка с характеристиките, възможностите и методите да се получи значително по-малък от списъка поддържан от всяко едно от устройствата. Когато говорим за фискални устройства - сечението (или минимума) понякога се определя индиректно от законите в дадената страна, които изискват всяко фискално устройство да ги имплементира. Колкото и да е странно, подобна минимизация е възможна и често е напълно достатъчна за нуждите на бизнеса;
- Софтуера Ви ще бъде резултат от изискванията на дадена стандартизация, свързана с нуждите на бизнеса в дадената област. Като цяло всеки тип стандартизация води до списъци с характеристики(properties) и възможности(capabilities), които някой от междинните слоеве обявява нагоре към слоя контактуващ с клиентското приложение;
- В зависимост от крайните бизнес цели - софтуера може да бъде:
- еднослоен - всичко необходимо се намира на същия компютър, към който е свързано съответното устройство;
- многослоен - част от необходимия софтуер за управление на устройството се намира на компютъра свързан с него, а друга част или части се намират на отдалечен сървър;
- облачно базиран - част от софтуера управляващ даденото устройство е сървис в даден облак (частен за фирмата или някой от общоизвестните), а самото устройство е разработено за директна комуникация с дадената услуга. В някои случаи - ако устройството не притежава такива възможности се разработва още един междинен слой;
Лични предпочитания
В течение на годините съм се убедил в следното:
- Колкото повече е отдалечен даден програмист от работата с крайни клиенти и от поддръжката на софтуер, толкова по-голяма е вероятността да Ви убеждава, че няма нужда да се разработва машинно независим софтуер. В някои конкретни случаи и аз смятам, че наистина няма нужда, но има ли повече от един модел хардуер в повече от една страна…
- Да се разработва машинно независим софтуер е наистина досадна и трудоемка задача. Изисква да се преминат много и много цикли и знанията на конкретния разработчик (или екип) да обхващат проблема изцяло. С други думи - не само, че е досадно и отнема време, но и като първоначална инвестиция е доста по-скъпо;
- Ако наистина сте решили да разработвате софтуер за повече от едно устройство и за повече от една страна и ако нямате в наличност екип от безумни работохолици, гении, които са готови да зарежат семействата си и личния си живот… Наистина Ви съветвам да изберете машинно независимия софтуер. В дългосрочна перспектива - сметките (като ги калкулирам във време, нерви и в крайна сметка пари) излизат в полза на този тип софтуер;
- Ако сте със скромен бюджет и искате да стъпите за първи път на дадения пазар (например имате поръчка за разработка на софтуер за ресторант, който ще работи с предварително точно определен тип устройства) - тогава можете да подходите и с машинно зависим софтуер, но… страданието Ви ще започне още със следващия клиент. В крайна сметка, ако държите на балансите и бъдещето - рано или късно ще стигнете до идеята за някакъв тип машинно независим модул, който да управлява устройствата Ви;
- Ако пред Вас е клиент, който иска просто да му направите програма или библиотека за управление на малко устройство... И особено пък, ако за него вече има осигурена поръчка от няколко хиляди бройки... Не му губете времето! Реализирайте максимално бързо поръчката. Направете му машинно зависим софтуер!
- Първо - и той и Вие ще свършите работата и няма да загубите поръчката (бизнеса е пари);
- Второ - ако все пак сте му обяснили, че има вариант за машинно независим софтуер и т.н. предимства и недостатъци, Вие ще сте постъпили напълно честно и ако след всичко това приказване бизнесмена избере бързата печалба (защото те така си правят), то Вие ще спите спокойно;
- Ако вече имате разработени всички варианти и просто ги предложите на клиента... това е максимума, който на всичкото отгоре носи удовлетворение на всички участващи в сделката. Винаги, когато съм имал възможността да предложа всички варианти и да усетя задоволството на клиента, съм изпитвал и удоволствието от добре свършената работа. А ако имате късмет и клиента Ви спомене, колко зле се е представила конкуренцията... е тогава ще разберете за какво говоря. Както и да е - това е максимума, който позволява на клиента да си избира, а ние хората обичаме да избираме, дори и след това да направим грешния избор.
Винаги постъпвайте честно, ако Ви попитат за вариантите. Много често Вие не знаете какви са възможностите на човека срещу Вас откъм бюджет, време и желания за развитие. Оставете отсрещната страна да прецени и избере (освен ако не са Ви платили или попитали за Вашето мнение). Ако постъпите честно - дори и да се избере неправилния вариант, поради текущите условия, човекът ще е останал с добри впечатления и следващия път ще дойде отново при Вас. Независимо дали става дума за проекти между фирми или за вътрешнофирмен проект, за мен поне това е правилния подход. През годините съм виждал много опити в бранша да се създава софтуер, който да обвърже клиента с постоянни и допълнителни доработки (платени) и да - това доста често сработва. Истината е, че клиента ще избяга от Вас при първата появила се възможност.
За мен лично, когато се избира как да се направи нещо - почти в сто процента от случаите, отговора е във въпросите, които сте задали на клиента или на себе си. Правилните въпроси довеждат и до правилните отговори. Ако си мислите, че единия или другия тип софтуер е за предпочитане и Вие знаете по-добре от клиента Ви кое е по-добро за него... Бих спорил по темата на по бира, но тук ще се спра повече на обсъждането на технологии.
Ако смятате, че нещо в тази статия е некоректно, непълно или недостатъчно - моля пишете ми, за да коригирам статията.
