Бьорн Фант

18 май 2018 г. · 4 минути четене

На телефона и компютъра ви работят приложения и софтуер, които ежедневно ви молят да актуализирате до най-новата версия. Ежедневно! Кога стигнахме до това и защо се случва сега? Ето защо софтуерните компании го правят и защо всъщност ги боли.

заплаха

Първо, крачка назад в историята. Когато израснах през 80-те, купувахме игри и софтуер в магазините на 1,44 MB флопи дискове. Ние седяхме и хранехме компютърната дискета по дискета, за да инсталираме най-новата готина игра. По това време най-големите игри бяха около 40 диска (около 55 MB). Понякога игрите се разваляха и трябваше да вземете диска за корекции, но това беше рядко. Разходите за разпространение на издаването на диска за корекции бяха високи за софтуерните компании, така че те се фокусираха върху издаването на софтуер, който беше щателно тестван.

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

Ако разпределението е решено, просто трябва да наемем хиляда разработчици, за да имаме успех, нали? Софтуерът с поток от актуализации в крайна сметка се раздува, което го прави по-бавен, твърде сложен за използване и заема твърде много дисково пространство. Преди три месеца моето дете се оплака от малко място за съхранение на нашия iPad от 16 GB. Оказа се, че последната актуализация на Angry Birds е 450 MB. Това беше сигурен начин играта да бъде изтрита за постоянно.

Още едно. Ето екранна снимка от моя Mac, която ми казва да актуализирам Microsoft Office.

Добре, признавам. Не бях актуализирал MS Office от около месец, но това е безумно! Използвам Word за писане. Какво може да добави Microsoft към това преживяване в 1.0 GB? И рядко използвам Powerpoint. За какво са допълнителните 716,6 MB? Това не може да бъде критична корекция за сигурност.

Докато сме в това, нека поговорим за съобщенията. Приложение на телефона ми иска да изтегля най-новата версия 35 MB с бележките за изданието: „различни корекции на грешки“. Страхотно, това наистина ме кара да искам да проверя новата версия. Разбрах, понякога трябва да пуснете корекции на грешки и ако е критично, някой лош разработчик обикновено няма време да напише нещо невероятно. Но това трябва да бъде изключение, а не правило. Но може би нямаме нужда от убедителни аргументи за продажбите. Хората все пак ще надстроят? Ще рискувате ли за постоянно да изтриете приложението си?

Така че подуването на вашия софтуер не е нещо добро. Софтуерните компании трябва да имат поне 1/10 разработчици, притесняващи се за подуване и производителност и да се уверят, че това не се случва. Подуването на корема е 100% свързано и с техническия дълг. Раздутата кодова база е по-трудна за развитие по-нататък. Ако сте мениджър на софтуерна компания, задайте на разработчиците си този въпрос: „Колко време отделихте за кодиране срещу проучване как кодът ще се побере с текущата кодова база в последния ви проект?”Повече от 30% изследвания са лош знак.
Когато софтуерът е твърде сложен за актуализиране и крайните срокове се приближават, за разработчика е лесно да избере лесния изход; „Нямам време да разбера този стар наследствен код. Вместо това ще напиша нов модул!”Резултатът е, че кодът вече е два отделни модула, които правят почти едно и също нещо, добавяйки към подуването и абсолютно ще обърка следващия разработчик, който ще докосне кода. Освен това потребителският опит на софтуера е в опасност. Функциите започват да изглеждат и функционират по различен начин.

И така, как трябва да управлявате затлъстяването с код. Както при всички усилия за отслабване, рядко се случва да се подлагате на диета от време на време. Имате нужда от промяна в начина на живот. Може би имате нужда от личен треньор. Но първа стъпка е да поставите по един човек във всеки отбор или 1/10 разработчик, отговорен за обучението на останалите отбори в строителния код, който е годен за спринт. Не забравяйте да добавите правилните KPI. Тук няма точен отговор, но ето три примера:
• Дял на кодирането спрямо изследването на кода (като примера по-рано)
• Ср. увеличаване или намаляване на теглото за освобождаване
• Тегло на софтуерните активи, които никога не се използват

Включете цялата компания в процеса на изграждане на по-добра използваемост, като попитате „кое е едно нещо, което можем да премахнем, за да може някой да използва нашия продукт по-бързо или да му се наслаждава повече?”. Планирайте оптимизацията на кода, както бихте направили с всяко друго физическо упражнение. Използвайте облачно съхранение и услуги, ако не разчитате на лоши мобилни интернет връзки. И наистина ли ви е нужно това видео за въвеждане на 4K резолюция на началния екран на приложението ви?

Гордейте се с наличието на годна кодова база и не забравяйте, че дори големите компании правят грешки. IBM плащаше на разработчиците по реда код, който те написаха.