Ако имахме 8-10 часа - може би, но за 6 - според мен е невъзможно да се изкарат 100/100. Аз специално се захванах направо с по-неприятната работа(както си мислех към онзи момент) - декапалване, изнасяне в класове(както и писане на нови от нулата) и писане на интерфейси. Джъджа го оставих на страна и пак не мисля, че всички принципи на ООП и КПК са ми ОК. Бъговете бяха яко зачукани...като цяло трябваше да се вземе решение - структурата или бъговете...За тестове отделих 35 мин, колкото да не е без хич...Като заключение - нито един от компонентите не изпипах.

    За мен фактът, че нито един от нас не успя да се пребори за повече от 50% от точките в Джъджа е доста показателен. Иначе изпитът според мен беше доста готин, не се съмнявам, че е  било доста трудоемко да се напише подобна задача. Честно казано като изключим напрежението от недостига на време, ми беше интересно и що-годе приятно. Дано на поправката се даде задача, която да е реално съобразена с предоставеното ни време.

Успех на всички, с които ще се видим на 10-ти Март ;)

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

Подобно на ООП, решавах изпита няколко дни по-рано, като бета тестър. За разлика от ООП, този път не се справих.

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

На мен изпита ми се стори по-лесен като логика от предишните, но огромен като обем.

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

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

Аз за разлика от ооп, ми се струва че,  бях доста по подготвен. Прочетох си условието няколко пъти, бих казал че го разбрах. Почнах да си правя интерфейси. Като дойде време да си правя отделните класове нахам едно светка друго. опитах се да напипа класовете от 0 . И като гледам 40 грешки ми изписва долу се отчайвах. По едно врреме се ядосах и почнах от начало и така си мина времето. Иначе знаех какво да направя, просто не успях. На поравката ще сме по подготвени!

Поздрави!

Според мен авторското решение е правено повече от 6часа :) 
Аз ако имах време щях да им направя на всички Interface-и сигурно, но реших да продължавам напред с тестове, документация и т.н... 

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

Като съм правила dependency injection-a, малко съм разменила имената на класовете, не съм рзбрала кое точно е controller-a в случая -> аз си го представях, че контролера предава message-a на engine-a, ActionManager-a всъщност държи всички методи..... предполагам ,че и това не е голяма драма :D

В тестовете на авторското решение се тестват exception-ите, които идват от моделите, на мен само с 2 метода, който тестват или successful message ili exception, че не същестува или има дупликат в зависимост от метода, ми излязоха всички с 100% coverage. Тук пак си личи ,че автора е имал достатъчно време да направи допълнителните методи и да тества Моделите :)

А да не говорим ,че за Mock-ването се е престарал :) Аз мокнах метода TestAirConditioner да приема any string и да връща 1 и също съобщение и го тествах, но тук не пишеше за над 80% covarge, а то нямаше и време де.

П.С Някой беше писал, че ползата от нулевите тестове е нулева :) съгласна съм, явно се покриват всички случаи. Аз няколко пъти прегледах условието и всички message-и , exception-и ми бяха ок. Само тоя switch с А...Е го бях оставила, освен от там да е била грешката, но не ми остана времето да гадая, щото и без това нямаше как да проверя :) Не се бях сетила и за енумерация да направя, ама кво да се прай :)

П.С2 Bottleneck-a наистина предполагах ,че е заради използването на List, вместо Dictionary, ама за 4 точки не ми се рискуваше да омажа нещо работещия ми код :) и без това не съм минавала структурите от данни и не съм достатъчно уверена.

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

Според мен хубавото на изпита е, че в работна среда по такъв начин се случват нещата много често. Много често имаш малко време, стегнати срокове и трябва да си разпределиш времето много добре и да наблегнеш на важните части, ако нещо ти отнема повече време от нормалното го оставяш  и т.н. В ИТ сферата работя, но не се занимавам с програмиране. Също очаквам 2-ка, но като цяло изпита стана доста интересн и полезен, по скоро не трябва да се мисли как е можело да го направим за 10 часа, а какво по-добро е можело да се направи за 6те, които имахме, Защото именно това разпределение на времето ми е трудно и на работа да го правя, а е голям фактор.

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

Жесток изпит... буквално и преносно.

Успех на 10-ти Март :)

На мен също изпита ми допадна и най-вече беше едно добро упражнение. За съжаление найстина беше доста обемен и според мен целия скелет си беше един голям бъг :D. Аз съм също от тези които не си прочетоха условието от край докрай и направо дебъгера подгарах. При мен изпита протече по следния начин: започнах да дебъгвам 5,10 минути видях колко е омацано всичко и реших, че е по-добре да започна да пиша, рефакторирам и изнасям класове интерфейси и прочие. След това пооправих мааааалко бъгове, ноо за съжаление и аз не малко време отделих на judge-а. На края успях да напиша само няколко теста та като резултат от цялата работа - нито всички бъгове бяха оправени,нито успях да взема всички точки от judge, нито  да рефакторирам абсолютно всичко, нито пък да направя всички тестове. Не знам как са преценили на толкова омацан код да дадът толкова малко точки за "бъгове" и рефакториране, но каквото такова. Днес разгледах подговките и задачите ми се видяха по-лесни  сравнение с нашия, но пък именно от такива задачи се научава най-много. 

Аз съм твърдо за това, да се трупат опит и знания.Моето мнение, може би субективно, но все пак е че изпита не беше насочен към КПК.Какво имам в предвид, нека разгледаме изпита, като един Unit Test.Както са ни учили в Софт Уни, целта на един Unit Test e да разграничи и дори изолира определени сценарии, за да може да бъдат тествани, конкретни условия.Разсъждавайки от тази гледна точка, не бих казал, че това се случи на практика.Тъй като в него на първо място се тества ООП.Даден ни е скелет, който не е правилен от гледна точка на ООП принципите - поправете го.Добре, но това беше предния формат на ООП изпитите.Т.е включва се сегмент от ООП, доста трудоемка и отнемаща солидно време задача.Нямам нищо против.Трябва да се научим на ООП, но защо в изпита по КПК ?Не ме рзбирайте греншно, много ми беше приятно да го правя и бих желал да се науча.Но изолирания сценарий вече отпада, т.е не се оценяват SOLID,DRY,YAGNI и т.н принципите, а нали точно тях трябва да усвоим и да бъдат оценени?Моcking - трябва да се знае, ок, но поради липсата на изолиран сценарий, трябва първо да сме минали стршно голяма част от работата по изпита, за да можем да покажем, дали сме научили mocking-a и неговата концепция, пак липсва изолирания сценарий.Dependency Inversion - смятам, че може да се провери през всеки един етап, дори, докато се форматира кода, би могло да се използва, т.е тук вече, изолиран сценарий не е нужен, т.е може лесно да се оцени, в каква степен е усвоен.6 часа за изпит по ООП и КПК в едно, мисля, че е крайно малко.Според мен трябваше по някакъв начин, да се дискретизират условията, така, че да можем да покажем, освен по ООП, какво сме научили и по КПК.На мен времето не ми стигна, да си довърша изцяло задачата, форматирайки я по принципите на ООП - цялостно, да не говорим за mocking.Не искам да критикувам, защото не е никак лесна задача, да се направи изпит и е страшно много труд.Просто исках да си кажа, каквото ми тежи от вчера :D

Радвам се за опита, който придобих.За поправката ще се подготвяме много по-здраво.Това бяха моите 5 стотинки по въпроса.