Изпита беше идеален откъм обем, НО

Мисля, че ако не беше гадния рефлекшън(с който никой от нас не беше запознат) щях да предам много по-добре рефакторирана работа и с добри Unit тестове, а може би и мокинга щях да пробвам...

Аз както и другите оправях неймспейсовете и имената и изгубих сигурно 1 час да оправям бъгове които са супер лесни и то само заради гадния рефлекшън. 

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

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

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

За моя радост успях да разбера как работи пустия рефлекшън и да оправя всички бъгове, да рефакторирам колкото време имах, да намеря 1-ния bottleneck и да понапиша unit тестове до колкото успях

Да обобщя: Поредния лош изпит по КПК.... + недостатъчно подготовка(предните изпити не ги броя... те са просто нереални да бъдат направени за 6 часа....)

ПП. Данчо, задачата беше интересна, но този рефлекшън не мисля, че му е там мястото..

Преди малко във фейсбук страницата ми се появи този линк:

http://www.7financial.com/%D0%B8%D0%BC%D0%B0-%D0%BB%D0%B8-%D1%81%D0%BC%D0%B8%D1%81%D1%8A%D0%BB-%D0%BE%D1%82-%D1%83%D1%87%D0%B5%D0%BD%D0%B5%D1%82%D0%BE/

https://www.facebook.com/svetlin.nakov?fref=nf

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

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

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

За изпита..... Данчо и на видеото за подготовката, и в указанията за изпита (и Фил също) обясни, че откриването на бъговете не е това, с което се почва, и не е това, което носи основните точки - аз съм си виновна, че 4 часа опитвах да оправям бъгове, и то като заменям всяко registry с речници......, и после почбах отначало и претупах част от основната работа по задачата за 2 часа само, можех с лекота да си направя и mocking - не си оставих време.... Като се явя следващия път ще знам какво да не правя :)

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

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

На мен изпитът много ми допадна. Беше преценен като сложност, не беше over-the-top осран (демек беше си четим) и показа MVC архитектурата, което според мен е доста полезно предвид програмата в следващите нива.

Някой по-горе каза, че този изпит бил почти толкова труден колкото Vehicle Park. Горчиво бърка. Докато на този изпит над 15% от хората успяха да вземат максимума точки от джъджа, при нас нямаше нито един. Т.е. бяха ви спестени много неща, които по мнението на мен и колегите ми от моя випуск нямат много общо с КПК-то и не са неща, за които следва да се губи време на изпита. Мненията ни явно са били взети предвид, защото аз прекарах около 3 часа в продуктивно рефакториране, без да ми се налага да трия 10 страници табулации и да уча чужд език. Изобщо доста преценено беше омазан проектът и беше ясно кое какво е. При нас имаше класове и методи, които не можехме да ги разберем какви са преди да пуснем дебъгера. Ако не се лъжа 17 страници условие, в което може да се загубиш и съответно 90% от хората не бяха видели, че на едно място трябва да се сортират някакви неща. На този изпит - кратко условие, всичко важно синтезирано в таблици, с които си направих целия изпит. По-добре разписано условие за изпит трудно може да се изисква.

Относно болната тема - рефлекшъна. На нашия изпит по ООП имаше релфекшън, тогава и идея си нямахме какво е това, така че не сте пионери. В целия проект само в еднжина има рефлекшън и на едно място в контролера ако не се лъжа. Целият енджин е 60 реда. Самият рефлекшън се прави с методи, които са именувани по начин, който ясно подсказва какво се случва. 

 var controllerType = Assembly
                    .GetExecutingAssembly()
                    .GetTypes()
                    .First(type => type.Name == route.ControllerName);

Взимаме асемблито (текущото, това, което рънва в момента), взимаме всички негови типове и хващаме първия, чието име отговаря на някакъв стринг, взет от рута, демек от входа. На този етап от обучението би трябвало да знаете какво е асембли, какво е тип и методите от LINQ.

 var controller = Activator.CreateInstance(controllerType, database, user) as Controller;

Викаме някакъв статичен метод, който, според името му, създава инстанция на нещо. Като първи параметър се подава типа, т.е. какво искаме да създадем, като следващи параметри се подават параметрите, които конструкторът на съответния тип очаква да получи. Методът връща object, затова накрая има кастване с as. Това сте го виждали ако сте гледали нашия изпит по ООП (Console Forum), или уъркшопа, който аз водих преди няколко месеца. Общо взето с това се изчерпва и моят опит с ползването на рефлекшън.

var action = controllerType.GetMethod(route.ActionName);

var view = action.Invoke(controller, parameters) as IView;

Тук влизаме в напълно непознати за мен води. От контролера взимаме някакъв метод с GetMethod и подаваме името на метода като стринг. Получаваме някакъв action, който е MethodInfo. Викаме Invoke с някакви параметри. Е, явно е, че викаме съответния метод, след като сме го взели, и викайки го му подаваме нужните параметри.

В метода MapParameters имаме:

 return action.GetParameters()...

action е метод, GetParameters очевидно ще бръкне в асемблито да вземе параметрите му. Оттам нататък се ползва LINQ, за да се преровят тези параметри и да се провери кои са int.

Основният проблем на повечето хора не е в рефлекшъна, а в неефективното дебъгване. Пример:

var viewType = Assembly
                .GetExecutingAssembly()
                .GetType(fullPath);

return Activator.CreateInstance(viewType, model) as IView;

Взимаме някакъв тип чрез пълния му път (всички неймспейси и накрая името на класа). Разбира се при положение, че пътят е грешен, това ще хвърли грешка. Това се вижда още на първата стъпка, когато viewType излиза null. Е, гледа се пътя, и се проверява дали е правилен. Виждате къде програмата търси съответния клас и къде вие сте го сложили. 

В случая рефлекшъна прави две неща: 

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

2) Принуждава ви да си структурирате приложението правилно. Да има папка Views и в нея подпапки Users и Courses. Дори това да не беше изрично казано в условието (а то дори беше нарисувано), логично е като има около 10 класа в две категории да ги разделите в два отделни неймспейса. Вадите класовете в отделни файлове, слагате ги в правилните неймспейси и рефлекшъна тръгва. Ако държите да слагате View на името на класа - не е проблем, добавяте го като суфикс във fullPath променливата.

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

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

Тъй че рефлекшъна не е фактор в цялата работа. Имаше един по-гаден бъг в MapParameters, който ми отне около 15 минути да го открия, но тук не говорим за опит с рефлекшъна, а за обикновено дебъгване на ламбда функция, демек на foreach. Методът търси параметър courseId, пък в контролера въпросният параметър е сложен само като id -> KeyNotFoundException.

По логистични причини пропуснах голяма част от курса, но от упражненията, които прегледах, ми направи впечатление, че Данчо още от самото начало ви караше да четете чужд код, да се ровите в големи проекти. Не може да знаете всичко и няма как всичко да бъде вкарано в един курс. Нормално е и целенасочено се слагат неща, които не са изучавани. Но правилото е - това, което не е учено, работи. Т.е. очаква се да схванете какво прави да речем Activator.CreateInstance, за да може ако някъде другаде има проблем да знаете защо точно този метод ви гърми. Например, подавате грешни параметри на конструктора. Виждате какъв клас се опитвате да инстанциирате, гледате какво иска конструкторът и виждате къде е несъответствието. Разликата е там, че това нещо ако го объркате ще изгърми runtime, а по принцип ако си викнете конструктора с new и не подадете каквото трябва ще се хвърли грешка още по време на компилация.

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

Относно MVC архитектурата, някой спомена, че се дебъгва трудно, защото минаваме от 9 класа в 10-ти. Така е, ще става все по-засукано. Чакайте да дойде JS Apps курсът, където ви гърми с "undefined is not a function" или друго подобно "описателно" съобщение от някоя минифицирана библиотека. Големи приложения не се дебъгват лесно ако не ги познавате. В случая е сравнително лесно. Моделите, това са класовете, там си правите валидациите и толкоз. Няма какво да гръмне там ако не сбъркате по невнимание. Вю-тата просто създават съобщенията, единствена грешка там би била правописна/печатна. Т.е. ако програмата ви гръмне с ексепшън, почти със сигурност това се е случило в енджина или контролера, където е реално цялата логика. Или в репозиторитата ако не сте инстанциирали някоя колекция (NullReferenceException). Слагате брейкпойнт където трябва и така няма да се налага да помпате F10 и F11 да минавате през очевидно верни методи. Или натискате F5 и виждате къде гърми. Това трябва да са до болка познати техники. 

Надявам се като ви поотминат страстите, че сме ви забили с неизучавани неща, всеки ще си направи равносметка къде всъщност е сбъркал - в подхода към самия изпит, в избързване с промените, в недобро дебъгване или друго. В крайна сметка КПК е курс, който цели да подготви хората да създават и работят по (т.е. да не засират) големи проекти, а не може в голям проект да има само if-else, for, foreach, StringBuilder и малко LINQ. Ще има много неща, които виждате за пръв път, външни библиотеки и др. За всичко си има документация (това в случай, че кодът не е self-documented, когато и документация не ви е нужна даже). Така че гледайте позитивно на нещата и вземете максимални ползи от неделя.

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