The Mythical Man Month

Една от класиките сред книгите за управление на софтуерни проекти. Написана преди повече от 40год., много от тезите са валидни и днес, което е и причината за преиздаването ѝ след толкова време.

Описват се основни възприятия в процеса на разработка, върху които малко хора са се замисляли и осмисляли – като защо обичаме да програмираме, какви са негативните страни от това, защо не успяваме да прогнозираме добре необходимото време за разработка. Някои от причините за последното са това, че сме оптимисти, не включваме в преценката си времето за комуникация, за дебъгване и тестове. Съществува също така грешното схващане, че работата на един разработчик е константа като човекочас. Съответно при забавяне в разработката на проект най-лесното решение е да се добавят още хора. Пропуска се обаче, че това внася допълнително натоварване към останалите и изисква повече време докато екипът се сработи. От тук произлиза и изводът, станал известен като закон на Brooks – “Adding manpower to a late software project makes it later”.

Друга интересна концепция, която се развива в книгата е начин за управление на разработката на голям софтуерен проект от голям екип разработчици (100+). Представят се предизвикателствата пред ефективното управление на много хора и един подход, който може да помогне – създаването на малки “хирургични екипи”. Малките екипи се състоят от един основен разработчик – “хирургът”, който взима решенията и разработва най-важните части от софтуера. Около него се създава екип от поддържащи роли – “копилот”, който може да върши всичко, но е с по-малък опит; “администратор”, който се занимава с административните дейности; “редактор” – документацията; двама “секретари” помагащи на администратора и редактора; “чиновник”, “инструменталист”, “тестер”, “адвокат на езика”, който познава тънкостите на използвания език за програмиране. По този начин комуникацията се разделя по определени роли и се улеснява скалирането на екипите.

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

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

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

Bulgaria Web Summit 2018

В събота посетих Bulgaria Web Summit 2018 за първи път. Лекциите бяха разпределени в 4 зали на ралични етажи, което значеше, че само 1/4 от тях можеха да бъдат посетени. Това което не ми хареса е, че между отделните лекци не беше предвидено време за за почивка и смяна на залата поради което се получаваше суматоха около края и началото на лекциите.

Първата лекция, което посетих беше How to hack a node app на Asim Hussain от codecraft.tv. И преди съм попадал на негови статии свързани с javascript и Angular. Доста забавно беше представен сериозен проблем със сигурността на повечето уеб проекти. Бяха дадени за примери популярни сайтове станали известни с изтичането на огромен обем лични данни на потребители. А причината за това са дребни на пръв поглед пропуски в сигурността, ненаправени ъпдейти на наличния софтуер, които като се навържат може да се стигне до пълен контрол над системите. Също така се обърна внимание на занижения контрол над библиотеките, които се разпространяват свободно през портали като npm, composer и др. В тях могат да попаднат библиотеки със злонамерен код, имитиращи популярни такива и човек ако не внимава може лесно да се подведе. Основните изводи от лекцията са – контрол над кода, който се използва в нашите проекти, актуални версии и ъпдейт на софтуера.

Следващата лекция беше Sharing code between web and native apps на Sebastian Witalec. Авторът е от екипа разработчици на NativeScript – технология, чрез която могат да бъдат създавани напълно native мобилни приложения пишейки единствено javascript код и използвайки изгледите на съответната платформа – iOS или Android. В лекцията се обърна внимание на възможността да се създаде Angular проект, в който кодът да е един и същ, но да се използват различни модули и изгледи за отделните платформи – за уеб, iOS и Android. За целта уеб версията се компилира от стандартния angular cli tool, а останалите – през native script cli tool. Споменато беше и очаквано съвсем скоро интегриранe на native script cli tool в angular, което още повече ще улесни интеграцията. Беше направено и демо, показващо един и същи проект на трите платформи. Лекторът също така обърна внимание на възможни проблеми и техните решения. Като цяло много полезна лекция за angular и native мобилни приложения.

Третата лекция, което посетих беше Building decentralized apps на Emil Stoyanov. Ставаше дума за приложения използващи world computer в blockchain-а на ethereum като платформа. Имаше доста терминология, с която не бях запознат и ми беше трудно да разбера някои от аспектите. Но все пак лекторът представи с какви предизвикателства се е сблъсквал при разработката на такива приложения, плюсовете и минусите на този подход.

След обедната почивка посетих лекцията React native app: expectations vs reality на Kaloyan Kosev, който разказа за своя опит при създаването на native мобилно приложение, използвайки react native – технология подобна на native script, разработена от facebook и надграждаща техния reactjs. Впечатленията си беше подредил в няколко категории – learning curve, limitations, debugging, ecosystem, performance. Като цяло очакванията му са били по-големи от реалността. Времето за научаване е било значително дори и за опитен reactjs разработчик поради слаба документация, не голяма популярност и съответно липса на информация при възможни проблеми. Ограниченията на платформата са разбираеми с оглед на това, че не е native платформата за разработка, но все пак за зависели от избора на фреймуърк – expo или react native app. Лекторър беше силно разочарован от възможностите за дебъгване на приложенията. Наличните библиотеки и готови компоненти също са били малко и не добре поддържани. Единствено производителността е отговорила на очакванията му – не се усеща разлика от native приложение. Слайдове

Лекцията Beyond documentation with OpenAPI на Boyan Yordanov ми беше наистина интересна – описваше решение на основен проблем при разработката на API – писане на документация, трудната поддръжка и несъответствие с кода. Решението е писането спецификация/схема на апито, която да се използва за документация и тестове удостоверяващи правилните данни. Споменати бяха различни стандарти като API Blueprint, RAML, JSON Schema,но беше обърнато внимание на предимствата на OpenAPI initiative (преди Swagger). Схемата се пише във формат yaml или json. Разработва се активно и има голяма популярност, поради което има много инструменти, с които се генерира документация, интегрира се лесно в тестове за различни езици, създават се автоматично gui-та за примери, интеграция в редактори. Представени бяха и различните възможности на спецификацията при описването на пътищата и параметрите, интегриране на JSON Schema.

Следващата лекция беше отново на javascript тематика – There is a lot of buzz around the progressive framework named VueJS, представена от Roman Kuba. Много добра интродукция за VueJS – javascript framework, който в последно време настига по популярност React.js и Angular. Лекторът нагледно показа защо се нарича progressive framework – можеш да започнеш да го използваш много лесно за елементарни неща – data binding, templating и т.н. и да надградиш към доста по-сложни концепции. Наистина удобен и интуитивен за ползване framework. Гледната точка на лектора беше обективна – той е бил част от решението да заменят angularjs с vuejs в интерфейса на codeship – популярна платформа за continuous integration, където работят с голямо натоварване и производителността на интерфейса е от голямо значение. Слайдове

Лекцията Testing against time in javascript applications на Jessica Jordan ми беше малко трудно да проследя поради особеностите на говора на лектора – много бързо, монотонно и слято. Все пак представи различни техники за тестването на асинхронни операции при писането на unit test-ове в Emberjs. Въпреки, че примерите използваха тестови рамки за Emberjs, концепцията е валидна и за останалите. Използваха се таймаути, мокване на заявки, callbacks.

Working the right way by knowing all the wrong ways на Boyan Djumakov беше последната лекция, която посетих. За жалост времето беше съкратено и крайно недостатъчно поради продължителността на предишната лекция в същата зала. В резюме бяха представени лоши практики в работния процес на разработката на софтуер както и съвети и решения за по-висока продуктивност, по-добра комуникация и успешни проекти. Важни изводи от лекцията – грешки винаги ще се правят, не трябва да се прикриват. Важно е да се споделят дори неуспехите и затрудненията. Временните компромиси почти винаги излизат скъпо след време. Ако не си в състояние да работиш ефективно – по-добре си почини. Обръщай внимание на комуникативните си умения, ефективното търсене на решения. Винаги някой ще знае повече от теб – търси помощ, не прави всичко от нулата. Не обещавай сляпо, бъди отговорен. Не следвай сляпо модата (инструменти, рамки, езици). И много други съвети, които са описани добре в слайдовете

Modernizing Legacy Applications In PHP

Modernizing Legacy Applications In PHP

Тази книга описва необходимите стъпки за модернизирането на остаряло приложение. Дава добро описание на понятието “legacy”, както и защо трябва да бъде модернизирано. Самите стъпки са добре подбрани, макар че ми се искаше примерното приложение в книгата да придобие още по-завършен вид. В крайна сметка крайният резултат доста наподобява това, което представляват повечето модерни MVC frameworks, но в по-опростен вариант. Истинската полза от изброените стъпки е това, че се разбира защо е необходимо да се предприемат, обяснени са подробно, както и след всяка глава има въпроси и ситуации, които могат да възникнат. Това, което ми липсва, обаче са неща, които са споменати в книгата като възможно развитие, но изрично е посочено, че няма да бъдат описвани и са дадени препратки към други материали по темата. Това са неща като testing frameworks, data mapper / active record database patterns, domain driven design. Липсва ми и отделна глава относно конфигурация на приложението за различни среди (само се споменава), както и error handling. Има и неща, които са излишни и идват в малко повече (споменават се почти във всяка глава): как и какво точно да търсим в кода на целия проект когато се заменят разни структури; кога да направим commit и да известим QA отдела; кога да искаме помощ или какво да кажем на operations отдела за промени по конфигурацията на сървъра и др. Като най-полезни мога да определя четири от стъпките, които виждам доста често, че се пренебрегват при разработката на приложения или просто не са усвоени: 6. dependency injection, 7. tests, 16. dependency injection container.

Continue reading “Modernizing Legacy Applications In PHP”