Разработка на услуга или какво се крие зад бутончето

 

 

 

Като разработчик на сървъри предлагащи услуги, както и на приложенията, които ги използват, често се сблъсквам със странен феномен. Хората, които не са правили никога през живота си нещо подобно, не осъзнават колко много задачи всъщност трябва да се изпълнят за да се прояви реалното действие или действия стоящи зад натискането на даден бутон в програмата, която използват.

 

 

 

В тази статия ще дам относително прост пример по темата. Задачата, както ми се обяснява е проста:

• да направя програма за конфигуриране и настройка на дадено устройство и някъде в нея да има да кажем един бутон. Обикновено е възможно е да има и повече, но в момента обсъждаме точно този. :)

• когато потребителя го натисне – програмата да си сваля от сървъра файловете необходими за устройството, към което програмата е свързана и съответно да ги използва за да запише в него нещо си...

Тук нарочно не уточнявам какви са файловете, защото вариантите са много и различни. От специфична конфигурация и настройки за даденото устройство, до например зареждане на фирмуер при производство на чисто ново. Въпрос на случая.

Въпросната задачка е добре да се разбие на подзадачи:

1. Първо трябва (ако въобще имаме такава възможност) да имаме еднозначно определяне на устройството, което е свързано с дадения компютър;

   1. Ако разчитате, че човека от другата страна е задал в настройките на програмата правилния модел и версия на фирмуер, значи наистина не сте се сблъсквали със силата на човешкия фактор. Закона на Мърфи важи с пълна сила – човекът може да е просто разсеян или да мисли например за котката на баба си, но фактите са си факти. През над двадесет годишния ми опит в областта съм стигнал до следното просто заключение – ако дадеш възможност на човек да сбърка... той рано или късно прави грешката. Случвало се е и лично на мен и то за мой срам с моите собствени програми.

   2. Това с други думи означава, че ако Вашата програма може да попита устройството за модел, версия и всичко останало (и ако то въобще я връща в текущото си състояние) – Вие трябва да предвидите такъв вид действие, като начало на изпълнение на задачата. Ако устройството е в състояние да не отговаря... уви ще трябва разчитате на човека от другата страна;

2. След като сте получили по един или друг начин горната информация – явно тя ще трябва да участва в запитването към сървъра, за да сме сигурни, че даденото устройство ще си получи правилните неща, а не нещо което да го блокира завинаги.

   1. Тук се сблъскваме със следната силно неприятна, но напоследък адски необходима част от живота – сигурността. Какво ще стане, ако дадената програма попадне в неправилните ръце? И нещата си тръгват по нанадолнището:

      1. потребител с потребителско име и парола;

      2. криптирана връзка – например SSL;

      3. управление на данните от страната на сървъра;

   2. Упс... стигаме до следния куп въпроси и задачи:

      1. какво ще бъде натоварването на сървъра?

      2. поддръжката 24х7 ли ще бъде?

      3. каква база данни да се избере за дадения случай?

         1. Как ще се администрира базата данни, в която е необходимата информация?

         2. Трябва ли оператора на данните да бъде квалифициран администратор на бази данни или ще осъществява дейността си през допълнителна програма? Някакъв... Wizard?

         3. Как ще се осъществява бекъп-а на базата – ще има ли отдалечен disaster center?

      4. Ще има ли система за автоматично уведомяване:

         1. при промяна на правата на потребител на системата?

         2. при добавянето или промяната на нова информация?

         3. при не оторизирана промяна на състоянието на сървъра?

   3. Упс... а системата... предвижда ли се нейното разширяване в бъдеще? Повярвайте ми, ако Ви кажат нещо от вида – направи го сега така, пък после ще го мислим... това означава, че впоследствие ще го мислите Вие или Вашия наследник. Ако имате късмет – впоследствие задачата може и да е решима, но отново според закона на Мърфи – ще е адски кофти за разрешаване. Например: ако не събирате информация за това къде, какви устройства са обработени от Вашата програма, както и от кого – когато това потрябва на същите хора, които искат просто да стане сега нещото пък после... С други думи – проблема ще си е Ваш (незнайно защо).

      1. Задачи за запис на „история на устройството“;

      2. Справки за извършени действия по потребител;

3. И така – ако въобще сте имали до момента сървър ще трябва да предвидите разширението (в най-добрия случай промяната) на базата данни, която в момента използвате. Т.е. да създадете и извършите един доста дълъг списък със задачи свързани с базата данни;

4. Въпреки че не ми се вярва някой от колегите да не го знае вече - тук е добре да се спомене, че не е добра идея да давате достъп до данните си директно. Дори и програмата Ви да работи единствено в локалната Ви мрежа – не използвайте двуслоен модел! Причините са дали повод за написването на наистина много статии. Просто... Не го правете, въпреки че ако системата Ви ще работи (първоначално) само във вътрешната мрежа на фирмата Ви – ще Ви е много по-лесно да го направите. Това ще сработи само до някое време – при първия отдел намиращ се в друг град или държава ще разберете, че многослойния модел е бил супер още в началото.

   1. избор на технология – избирате си DataSnap (ще обяснявам по-късно защо, но само една от причините е, че ме кефи);

   2. проектиране на предоставените методи (все пак ставаше дума за интеренет услуга);

   3. задачи по имплементацията;

5. Въпроса с капсулирането на код. Задайте си следния въпрос – възможно ли една такава система (вече доста гъвкава, като проект) да се използва след време за сваляне на подобна информация за други подобни проекти? И... ако отговора е да – възможно ли е след време тази система да се използва от друг програмист? (идеята ми е че ако една такава система е проектирана правилно – тя би трябвало да се използва години, след като нейния разработчик (теоретично) вече не е на работа) В такъв случай – възможно ли е въпросния нов програмист да използва друг език за програмиране? Вероятността е равна на 100%.

   1. задачи за разработване на SDK за връзка към сървъра;

      1. избор на технология;

      2. проектиране на предоставяните методи;

      3. задачи по имплементацията;

6. Тестове... Тестовете на цялото това нещо са задължителни, ако искате то да започне да работи и да живее повече от два дена;

   1. тестове за базата данни (валидация на данните, вградени процедури и т.н.);

   2. тестове за системата за управление на данните;

   3. тестове за сървъра предоставящ услугата;

   4. тестове за SDK-то което ще използвате в програмата си;

   5. тестове за програмата, в която ще се появи въпросния бутон, който като го натиснете ще използва въпросната интернет базирана услуга;

   6. тестове на резултатите в реални условия (компютрите, които не са собственост на разработчици на софтуер са тъмно и опасно място, където оцеляването на програмите и техните версии е несигурно);

7. Упс... разпространението... - доработка за съществуващата вече инсталация и ако сте благословени с нещо такова, доработка в системата за автоматичан ъпдейт на програмата Ви;

8. Документация... Ако не документирате добре всичко дотук – Вие сте обречени на огромни неволи в бъдещето. Вие или Вашите наследници. Не бъдете злобни към тях – те не са виновни за това, че не Ви се занимава с тази досадна... Напънете се и документирайте всичко. Технологията, тестовете, задачите, а не е зле да използвате и сорсконтрол системата. Въобще... не се стискайте в тази част при проектирането. Бъдете щедри, направете си тасковете и после ги изпълнете един по един.

9. Разпространение. Колкото и да е странно – разпространението на нов продукт не е просто написване на едно писмо. Направете си задачите и в тази част.

 

И така... грубата основа, бланката за промените по Вашия проект е вече готова. Подробностите са доста повече и както знаем – там са загинали значителен брой програмисти, но това е тема на следващата статия. Това беше просто загатване за сложността намираща се в редовете код зад бутона и защо нещата не винаги стават толкова бързо.