Временните решения и дългосрочните последствия

История от нашата практика и защо контролът върху промените е по-важен от новите технологии

Често използваме израза „в практиката ни сме установили…“. Това означава, че сме работили по много различни казуси – бавни сайтове, комплексни системи, проекти, които с времето са станали по-трудни за поддръжка.

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

Много от системните предизвикателства не започват с лошо решение, а с временно решение.

„Нека го направим така засега.“

„Ще го прегледаме по-късно.“

„Това е само за тест.“

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

Те се появяват по-късно.

Един реален казус от нашата практика

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

Дълги години тази система е работила стабилно – без критични проблеми. Напълно използваема.

В един момент обаче е регистрирано забавяне – над 3 секунди за страница. Само по себе си това не е драматично, но при интензивно ежедневно използване на системата от много потребители, беше дошло време да се обърне внимание на казуса.

Логичните стъпки

Подходихме по стандартния начин:

  • Обновяване на софтуера до актуална версия;
  • Оптимизация на базата данни;
  • Добавяне на Elasticsearch за по-добро търсене;
  • Преглед на настройките по производителността.

Всяка от тези стъпки беше обоснована. Имаше подобрение, но не в степента, която очаквахме и която би била задоволителна за клиента.

Това ни насочи към по-задълбочен преглед.

Какво се оказа

При детайлна проверка открихме тестов код, записан в поле в базата данни, който се изпълнява при всяко зареждане.

Тази „поправка“ в работата на сайта е била добавена в определен момент, с конкретна цел. В контекста си – напълно оправдана.

С времето обаче е останала в системата, без вече да е необходима.

Резултатът е, че при всяка заявка се изпълняват допълнителни операции, които не носят реална стойност.

Потърсихме референции в останалата част от кода, за да сме сигурни, че премахването на тези няколко реда код няма да нарушат нормалната работа на друга функционалност. Макар да нямаше, подходихме предпазливо – първо създадохме staging среда, в която направихме тестово премахване на кода.

Резултатът беше моментален – времето за зареждане спадна значително. От 3 секунди – до 700 милисекунди.

Не беше необходим нов хардуер, повече ресурси или друга технология. Достатъчно беше да се премахне нещо, което с времето беше останало в системата без реална функция.

Как се стига до подобна ситуация

Подобни сценарии не са рядкост. В повечето случаи те са естествен резултат от развитието на една система във времето.

По нея работят различни хора, добавят се нови функционалности, правят се тестове, внедряват се подобрения. В конкретния момент всяка от тези промени има своята логика и решава реална задача.

С времето обаче част от „временните решения“ остават в системата по-дълго, отколкото е било предвидено. Те постепенно се вписват в общата структура и започват да изглеждат като естествена част от нея.

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

И в много случаи проблемът не идва от едно конкретно решение, а от натрупването на много малки решения във времето.

По-широкият извод

Този пример не е свързан с конкретна технология. По-скоро е свързан с начина, по който се управляват промените в една система.

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

С течение на времето по една система започват да работят различни хора. Добавят се функционалности, правят се тестове, внедряват се нови идеи. Всяка промяна е логична в своя контекст, но постепенно става все по-трудно да се проследи цялата картина. Особено при проекти, при които развитието не се управлява чрез системи за контрол на версиите, например git.

В такъв момент системата започва да разчита повече на натрупани решения, отколкото на ясна структура.

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

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

Как това засяга собствениците на сайтове

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

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

В началото това не създава проблем. Всичко продължава да работи нормално.

С течение на времето обаче системата започва да става по-сложна. Поддръжката изисква повече усилия, а всяка следваща промяна започва да изисква повече внимание.

Този процес рядко се случва рязко. Най-често той е резултат от постепенно развитие, при което липсва периодичен преглед с цел опростяване.

Чеклист: време ли е за почистване?

Отговорете си честно:

  1. Има ли тестови функционалности, които са останали активни, но обективно не се използват?
  2. Правени ли са значими промени по кода, функционалностите и настройките им?
  3. Работили ли са по сайта Ви различни екипи през годините?
  4. Преглеждат ли се редовно потребителските достъпи?
  5. Има ли интеграции, за които не сте сигурни дали още са нужни?
  6. Поддържа ли се документация на направените промени?
  7. Прави ли се периодичен преглед с цел опростяване?

Ако нямате ясен отговор на някой от тези въпроси, това не означава непременно проблем. По-скоро е знак, че сайтът се е развивал постепенно и че част от решенията са останали в системата по-дълго от първоначално планираното.

Периодичният преглед на функционалностите, достъпите и интеграциите може да бъде изключително полезен — той помага системата да остане подредена и лесна за поддръжка във времето.

Финал

Временните решения са естествена част от развитието на всяка система. Те позволяват бърза реакция, дават възможност работата да продължи и често решават реален проблем в конкретния момент.

С времето обаче част от тези решения остават в системата по-дълго, отколкото първоначално е било предвидено. Добавят се нови функционалности, правят се подобрения, системата расте. В този процес някои от временните елементи постепенно се превръщат в част от средата, без да е ясно дали още са необходими.

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

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

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

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


Абонирайте се за СуперБлога, за да получавате полезно и експертно познание от света на уеб хостинг услугите, касаещо Вашия сайт и дигитално присъствие.

Красимир Стоев
Красимир Стоев
Над 10 години Краси е част от СуперЕкипа на СуперХостинг. Вярва, че доброто разбиране и ясната логика водят до устойчиви решения — и помага на клиентите да ги открият. Харесва свободния софтуер, писането на скриптове и създаването на системи, които правят живота по-лесен. Извън работата се занимава с музика и писане — два свята, в които също търси смисъл, ритъм и логика.
5 2 votes
.
Абониране
Уведоми ме при
guest

0 Коментара
Inline Feedbacks
View all comments
10 основни грешки при изграждането на един уебсайт

10 основни грешки при изграждането на един уебсайт [Аудио]

0
Последствията от неправилно структурирания сайт могат да бъдат неприятни за бизнеса Ви и да доведат до нежелан ефект.
Онлайн магазин? Направете първата стъпка

Oнлайн магазин? Направете първата стъпка [Аудио]

5
Искате да имате онлайн магазин? Ако отговорът е положителен, вижте първите стъпки, през които да преминете, за да изградите успешен онлайн бизнес.

Имам онлайн магазин, но нямам поръчки. Защо? [Аудио]

0
Изграждането на работещ онлайн магазин изисква време, постоянство и много работа! Ако вече имате магазин, но нямате продажби, вижте възможните причини.