[HQC - Exam 07.02.2016] Впечатления и коментари

evgenikolov 304 Точки

[HQC - Exam 07.02.2016] Впечатления и коментари

Как ви се стори изпита?

След като разгледах и забутаните тестове и решението съм убеден, че нямаше как да направим всичко, което се изисква от нас. Имаше прекалено много неща за рефакториране, доста повече бъгове и завъртяни случаи, които изяждат супер много от времето в сравнение с предишни изпити, а нулевите тестове бяха много "готини". Вкъщи си погледнах първият нормален тест, промених само една стойност от 1 на 2 и изкарах 6 точки дори без да ми минават нулевите. В началото на изпита ни казаха, че нулевите покривали доста неща и били добре направени, но до колкото разбирам май изобщо не са били.

Здраве да е, ще се видим на поправката като ще се надяваме изпита да е по-съсредоточен върху КПК курса и да е съобразен с времето което имаме. :)

Тагове:

07/02/2016 18:22:23 C# OOP Advanced 07/02/2016 19:32:00

RoYaL Trainer 6849 Точки

Best Answer

Нека споделя моите впечатления от изпитната задача, като човек, който я е видял предварително, от изпита и от това, което видях по време на него.

Първо, да ви успокоя, не съм правил аз задачата :D Може да не ме биете много :D

И аз решавах задачата, само че преди вас, за да тествам изпита. Какво ми направи впечатление:

1. Условието е огромно. Нямаш шанс без да го прочетеш.

2. Абсолютно всичко в скелета беше направено наопаки на това, което се иска.

3. Кодът не е тестваем. Не можеш директно да скочиш на тестовете.

Как подходих:

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

След това реших да рефакторирам малко. Без да оправям бъгове. На всяка имплементация направих интерфейс. Направих базата да не е статична. Направих й интерфейс. Инджектнах я в енджина. Преместих инстанцирането на екзекютора в мейн метода и го подадох на енджина.

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

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

Логиката се промени в мейн метода на:

1. Инстанцирам база данни

2. Инстанцирам Контролер с база данни

3. Инстанцирам диспечер с контролер

4. Инстанцирам Юзър интерфейс

5. Инстанцирам енджин с юзър интерфейс и диспечер

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

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

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

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

Какво видях по време на изпита:

1. Главоломно гонене на точки в джъдж, които междувпрочем са 16 от от 86 (изключая бъгове и перформънс ботълнеци тук)

2. Основни пропуски от лекциите, които сме ги повтаряли много пъти: Да не ползваме статични неща, винаги да гледаме да имаме висока абстракция

3. Голямо абюзване на правилото да не наследяваме при "has a", а само при "is a". Самолетът не е кола, и климатикът за самолет не е вид климатик за кола.

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

Стратегията винаги е - максимално много за максимално кратко време. Както и "да си постелим пътеката". Може би изпита за много хора не може да се побере в 6 часа. Щом е така - не стойте като все едно имате 18 часа! Дали можете или не можете за 6 часа имате 6 и не повече. Тогава се опитайте да направите нещо за тези 6 часа. Това, което много хора правеха е да решават изпита "top to bottom" и просто в един момент времето свърши и бяха до никъде. Да, с тази стратегия при 18 часа например, изпитът щеше да е перфектно полиран и за 120 от 100 точки, само че като няма 18 часа, тогава трябва да се опитаме да направим максимум за тези 6 часа. Да вземем от тук и от там каквото може. Тестовете и рефакторинга както винаги дават най-много. А тестовете и документацията като цяло дават и идея за някои грешки, които може човек да е допуснал, като например да не е прочел добре условието.

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

Важно нещо, което ще ви трябва в кариерата ви като софтуерни инженери и като цяло в живота е това да си управлявате времето (time management). Друго нещо, което е много важно - да се разбира добре бизнес сценария/спецификацията. В случая това е условието. Имайте предвид, че на работа ще получавате спецификации, които трябва да четете и превърнете в код. Спецификациите могат да следват някакъв шаблон и съответно да бъдат доста по-дебели от изпитната задача (пример1, пример 2)

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

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

Нещо в допълнение - не разчитайте на шаблонноста. Имаше хора, които ми казаха "ама то тука няма по 5 класа в един файл и променливите са на английски, трябва ли да рефакторираме нещо?". Надявам се от курса да сте разбрали същината на рефакторинга и че далеч не се крие в това да промениш китайски йероглиф на английски и да екстрактнеш N класа от един файл в множество файлове.

На много хора не им е достатъчно време и най-вече опит. Това е разбираемо. Gap-ът във времето се топи по-трудно. Но може да действате по посока опита. За да разширите знанията си и като цяло да имате mindset за/и подход към проблемите ще трябва да сте се сблъсквали с различни ситуации. Затова е добре сами да си ги поставяте. Опитайте се учейки за курс/изпит да си създавате сами проблеми, които да решавате. Като например - ще си направя десктоп/конзолно приложение, което да ми някакви неща, като определен момент настъпи. Или ще си напиша форумче. Надраскайте го - чисто логически. Измислете си нов фийчър в приложението. Опитайте се да го добавите. Пресметнете колко неща пренаписахте, за да добавите новия фийчър - ето измерител за качеството на кода. Минете през лекциите и вижте, които добри практики щяха да са ви от полза, ако ги знаехте. При следващото такова приложение вече ще сте се сблъсквали с определено множество проблеми и ще бягате като опарени от тях. Няма да ги допускате. Но ще допуснете нови. Ще разберете за тях и ще ги оправите. Историята ще се повтори и така.

За един месец със сигурност не е възможно да си видял всичко на този свят (както и за цял живот), но можеш да видиш доста. Това естествено изисква много време - може би по цял ден. Тук човек вече си прави сметката как да вмести във времето си повече за своите приоритети. Имайте предвид, че това не е свършен факт. Ученето е продължителен процес. В общия случай до края на дните ни. Така, че може да се възползвате от съвета ми и от този момент нататък. Ще ви помогне както за бъдещата ви кариера, така и за по-доброто ви представяне в университета.

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

Успех и ще се видим утре на Advanced C# с някои от вас, живот и здраве.

Ваш,

Иван

07/02/2016 21:09:32

iliyanaydenov 25 Точки

Много благодаря за изчерпателния отговор, Ванка :) И на мен не ми стигна времето за да довърша изпита, за жалост. Наистина ми трябва още много опит и много решаване на задачи. Бих се радвал, ако хората, които се събират да решават задачи в СофтУни си кажат, за да можем да се станем по-голяма група. Мисля, че бихме могли да си помогнем взаимно.

08/02/2016 08:11:02

butanfire 32 Точки

Изпита беше супер яката бомба със закъснител! :D
Честно казано с reflection щеше да ми е по-лесно да се ориентирам из кода - даже бях свикнал от примерните изпити!! :))

Не успях и аз да направя всичко - най-големият файл ми е Dictionary-то на базата и прекалено МНОГО време инвестирано във валидации, които бяха супер тънки (trim:)))) , но беше яко предизвикателство, дори със после даденият примерен solution + tests!

Това което Иван е писал, сякаш описва битката при Перперикон и маса хора са тръгнали напосоки в мелето, вместо да правим което са ни учили :))))
Объркванията са от няколко неща :
1) Толкова сплескан и обемен код не сме срещали за рефакториране (Bangalore / Chepelare са перфе!)

2) Reflection -> Command / SwitchCase

3) Уникални стойности!! :)) Ама кой да се сети че уникално име е Model+Manufacturer! :)))

4) Тънките моменти за валидации на вход (от ООП до сега май не сме правили толкова валидации на входните данни, КПК anyone?) :))))

Супер изпит! Натрихa ни носовете малко :))

Поздрави,

Владо

08/02/2016 10:28:19

CharlieScarver 33 Точки

Страхотен отговор!
Благодаря ти, Ванка, че си отделил време да го напишеш, че и хубаво да го напишеш : )

11/02/2016 09:16:13

KrasiNedew 65 Точки

Проверката за pass на теста също беше доста завъртяна - тестовете на климатиците за коли fail-ват ако корена на Volume е по-малък, а за самолетите pass-ват (реално в един if променяш "<" на ">=" и си пушка). Тази промяна ми направи разликата от 6 до 16 точки. При положение, че условието е доста обемно, кода е далеч от идеален и имаме да правим толкова много неща за 6 часа е тъпо да има и такива извъртания в условието.

07/02/2016 18:31:07

Mozez 55 Точки

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

07/02/2016 18:46:19

kristian.georgiev 15 Точки

Явно повечето сме зле,та ако не друго поне оценките на базата на общото представяне може да са малко по-високи :D

07/02/2016 18:56:49

bacuty 55 Точки

Те резултатите говорят за изпита, аз лично се притеснявам, понеже към Unit тестовете подходих малко... ексцентрично...имах field с валидна команда(която се сетва в TestInitialize, като на всеки тест, променях някои от параметрите), та малко е може би странно.

Другото няма какво да го обсъждаме :)

07/02/2016 19:16:22

kristian.georgiev 15 Точки

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

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

Добре че нямаше рефлекшън :D

07/02/2016 19:34:07

nasun4o 15 Точки

Ужасен

07/02/2016 19:19:54 07/02/2016 19:37:24

mbencheva 52 Точки

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

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

Очевидно беше много лоша идея:-) Нулевите тестове вървяха, ама нищо друго, после открих поне още 5-10 проблема.

Толкова се разочаровах, че дори StyleCop-a не пуснах:-)

07/02/2016 19:21:42

MiBuena 7 Точки

Здравейте,

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

Аз искам да попитам един въпрос относно контролера и командите.

Може ли някой да сподели как е подходил, за да избегне switch case-а коя команда да се изпълни? И съответно за Dependency Injection-a.

Аз направих един клас CommandManager и отделен клас за всяка команда FindAirConditionerCommand и т.н. - всяка със своя Execute() метод. CommandManager-ът решава коя команда да инстанцира чрез рефлекшън спрямо подадения вход. Целта ми беше така да избегна switch-case-a и така да е open for extension.

Методът, който избира коя инстанция да вдигне, обаче ми е вътре в CommandManager-а. Замислих се дали не трябва да го сложа в Engine и Engine-ът да подава като Dependency Injection на CommandManager-а, обаче се замислих, че тази логика като че ли е по-свойствена на CommandManager-а.

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

Благодаря много предварително!

07/02/2016 19:41:04 08/02/2016 12:35:53

krisitown 45 Точки

Според мен, изпита не беше толкова труден, колкото казват колегите. Че нулевите тестове бяха бомба, бяха. Моето любимо състояние на всички нулеви минават и 0 точки. При мен проблема не беше в сложността а във времето. Дали беше защото съм се занимавал със странични неща незнам но просто не ми стигна времето. Unit тестовете ги нацъках за последните 15 минути.

Мисля че горе долу съм ги разкачил нещата, защото бяха сериозно couple-нати. Ето решението за тези които искат да погледнат интетресно ми е какво другите хора биха помислили за него:

https://github.com/krisitown/HQC_AirConditionerTesting

Чак сега осъзнах, че солюшъна ми се казва BigMani, oh well

07/02/2016 19:42:10

VladimirVidenov 5 Точки

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

07/02/2016 20:00:12

krisitown 45 Точки

След тоя код мисля. че и на църква да ида няма да помогне.

DoMagic(), Baito, нещата бяха вързани яко.

Само съм разочарован, че нямаше някоя променлива или клас на японски, щеше да си върви перфектно с backstory-то на задачата.

07/02/2016 20:05:09

CharlieScarver 33 Точки

Хаха, всъщност имаше неща на японски. Baito значи 'временна работа' на японски :D

11/02/2016 09:13:57 11/02/2016 09:14:40

Покажи всички коментари

djc_bg2015 923 Точки

Ползата от нулевите тестове беше нулева :D

Някой да е на мнение, че пренаписването от 0-та би било по - бързо и лесно в конкретния случай?

07/02/2016 19:50:21 07/02/2016 19:51:02

krisitown 45 Точки

За това няма спор

07/02/2016 19:51:18

enevlogiev 1168 Точки

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

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

07/02/2016 20:08:25

djc_bg2015 923 Точки

Думата описваща изпита - Драма :D

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

И това условиe 56 стриници :), почнах задачат 3 пъти от начало, цяло чудо е , че в крайна сметка стигнах до нещо :D

07/02/2016 20:12:40

Покажи всички коментари

Sideroff 22 Точки

После на Данчо задачите били нерешими хахаха

07/02/2016 20:23:25

Blaskowitzzz 41 Точки

Направо Vehicle Park System 2.0 ...

07/02/2016 23:04:50 07/02/2016 23:18:40