Қазыларға арналған README: хакатон жобасының тексерілетін демосын дайындау
Жобаны тапсыру пакетін бір сценарийге құрыңыз: нақты кіріс пен нәтиже, тексерілген командалар, қауіпсіз деректер, қазының қолжетімділігі және бекітілген коммит.
·5 мин оқу
Не білесіз
Бір сценарийді нақты кіріс пен күтілетін нәтиже арқылы сипаттаңыз.
Нұсқаулықты бекітілген коммитте ауызша көмексіз тексеріңіз.
Жұмыс істейтін функцияларды, уақытша алмастырғыштарды және қолжетімділік шектеулерін ажыратыңыз.
Жобаны тапсырар алдында командадан тыс адам дәл сол нәтижеге жете ала ма, тексеру керек. Репозиторийге ашылатын сілтеме мұны растамайды. README ішінде нақты деректер, қадамдар және сәтті орындалғанын көрсететін белгілер қажет. Солар арқылы қазы баптау ақауын өнім қатесінен ажыратып, шынымен жұмыс істейтін бөлік туралы сұрақ қоя алады.
Құжатты қайталауға дайын сценарийдің айналасына құрыңыз. Төменде оқу мысалы ретінде бөлмелерді жабдығына қарай іріктейтін сүзгіні қарастырамыз. Идентификаторлар мен деректер ойдан шығарылған; сипаттама нақты іс-шараны немесе бөлмелерді білдірмейді. Кірісті, нәтижені және іске қосу шарттарын ауыстырсаңыз, осы тәртіп басқа прототипке де жарайды.
1. Бір аяқталған тапсырманы көрсетіңіз
Пайдаланушы әрекетінен бастаңыз: «Проектор мен тақтасы бар бөлмелерді таңдау». Содан кейін нәтижені атаңыз: сәйкес идентификаторлар тізімі. Оқу жиынтығында demo-room-a бөлмесінде projector және whiteboard, ал demo-room-b бөлмесінде тек projector бар. {"required":["projector","whiteboard"]} кірісі {"rooms":["demo-room-a"]} жауабын беруі керек.
Адам сұрауды қайда енгізетінін және жауапты қайда көретінін жазыңыз. Интерфейс үшін экран мен басқару элементінің атауын, API үшін нақты маршрутты, әдісті және сұрау мазмұнын көрсетіңіз. Жоғарыдағы мысал дайын сервис адресін емес, сұрау мазмұнын көрсетеді. Тек іске асырылған жолды енгізіңіз.
Нәтижені қалай салыстыру керегін анықтаңыз: бөлмелердің реті маңызды ма, қосымша өрістерге рұқсат етіле ме, сәйкестік табылмаса не қайтарылады. Прототип тізім көрсетсе, қатенің жоқтығын ғана емес, тізімді тексеріңіз. Біздің деректерде {"required":["microphone"]} сұрауы үшін {"rooms":[]} күтіледі. Бұл екінші оқу кірісі сәйкестік жоқ кездегі әрекетті тексеруге көмектеседі.
Құжат басында жобаның күйін көрсетіңіз: жұмыс істейтін прототип, тексерілген сценарий және аяқталмаған бөліктер. GitHub README туралы нұсқаулығында оқырман жобаның мақсатын, жұмысты қалай бастау керегін және көмекті қайдан алатынын түсінетіні сипатталған. Тапсыру үшін тексерілетін код нұсқасына сілтеме қосыңыз.
Соңғы коммитке дейін README файлын жаңартыңыз. Коммит жасалған соң оның толық идентификаторын тапсыру формасына және демоның тексеру жазбасына көшіріңіз. README бар коммиттің идентификаторын ол жасалғаннан кейін жазыңыз: идентификаторды файлдың өзінде сақтау үшін жаңа коммит жасау керек болады. main тармағын өзгермейтін нұсқа деп көрсетпеңіз.
Нақты файлға сілтеме алу үшін оны GitHub-та ашып, Y пернесін басыңыз: тұрақты сілтеме коммиттегі нұсқаға апарады. Жарияланған демоны қандай код іске қосатынын бөлек түсіндіріңіз. Жергілікті нұсқа мен сервер өзгеше болса, қазыға оны экрандағы әрекеттен анықтауға тура келмесін.
3. Оқырманды таза көшірмеден жауапқа дейін жеткізіңіз
Негізгі жолды таңдаңыз: жергілікті іске қосу немесе қолжетімді жарияланған демо. Қадамдардың алдында нақты тексерілген орта нұсқаларын, тәуелділіктер менеджерін және қажетті сыртқы сервистерді көрсетіңіз. «Ең соңғы» деген сөз жобаны қандай шартта тексергеніңізді сақтамайды.
Жергілікті жол үшін жұмыс бумасын, сақталған тәуелділіктердің lockfile файлы бойынша орнатуды, конфигурацияны дайындауды, тест деректерін жүктеуді және іске қосуды жазыңыз. Әр қадамнан кейін байқалатын нәтижені көрсетіңіз: баптау файлы пайда болды, оқу бөлмелері жүктелді, қажетті экран ашылды. Командаларды өз репозиторийіңізден алып, көрсетілген ретпен тексеріңіз. Әмбебап орнату нұсқаулығы сіздің миграцияңызды немесе файл жасау қадамын өткізіп жіберуі мүмкін.
Баптауларды атауы арқылы түсіндіріңіз. Мысалы, жобаңызда осындай параметрлер іске асырылса, APP_MODE демо режимін таңдайды, ал DEMO_DATA_PATH оқу деректеріне жолды көрсетеді. Әрқайсысының міндеттілігін және қайда қолданылатынын жазыңыз. Интеграцияға SERVICE_API_KEY қажет болса, README ішінде кілт мәнін бермей, оның атауын және тесттік қолжетімділікті алудың келісілген тәсілін көрсетіңіз. Қолданба оқымайтын айнымалыларды қоспаңыз.
4. Деректерді және қайта іске қосуды дайындаңыз
Қауіпсіз кірісті қолжетімді файлға сақтап, күтілетін жауаппен байланыстырыңыз. Біздің мысал үшін аталған екі идентификаторы мен жабдығы бар оқу бөлмелерінің тізімі жеткілікті. Файл атауы мен орны нұсқаулыққа сәйкес болуы керек. Оқырман жиынтықты скриншоттан қалпына келтірмеуі тиіс.
Бастапқы күйге қайтаруды түсіндіріңіз: қандай демо жазбалар жойылады, не қайта жүктеледі және бастапқы шарттардың қалпына келгенін қалай тексеруге болады. Қалпына келтіруді тест деректерімен шектеңіз. Прототип күйді өзгертсе, бастапқы күйге қайтарғаннан кейін сценарийді қайталап, нақты нәтижені сақтаңыз.
Файлдар мен экран жазбасында нақты байланыс деректері, жұмыс құжаттары, токендер және бөтен жүйелерге қолжетімділік жоқ екенін тексеріңіз. Бөтен код үшін жұмыс құпиялары мен негізгі компьютер бумалары қосылмаған бір реттік оқшауланған ортаны қолданыңыз. Бұл шарттар техникалық қабылдау чек-парағына сәйкес келеді.
5. Демоның тәуелділіктері мен шектеулерін атаңыз
Кодта жұмыс істейтін, уақытша алмастырғышпен көрсетілген және әлі іске асырылмаған бөліктерді ажыратыңыз. Біздің оқу сүзгіміз деректер жиынтығындағы жабдықты тексереді. Ол нақты ғимаратта бөлме бар екенін, белгілі уақытта бос екенін немесе брондауға болатынын растамайды. Бұл шектеулер күтілетін нәтиженің жанында болуы керек.
Сыртқы сервис қажет болса, тәуелділікті, тесттік қолжетімділікті және сервис қолжетімсіз кездегі байқалған әрекетті сипаттаңыз. Резервтік жазба жазылған сценарийді көрсетеді; жаңа сұраудағы жұмысты растамайды. Демо режимін жұмыс істейтін интеграция ретінде ұсынбай, демо режимі деп белгілеңіз.
ЖИ прототипі үшін қолжетімді компоненттердің нұсқаларын, промптты, бастапқы жауапты және іске қосу параметрлерін сақтаңыз. Бір сәтті мысал басқа деректердегі сапаны көрсетпейді. Бақылау тексерісінің толық тәртібі ЖИ демосын тексеру нұсқаулығында берілген. Сыртқы сервистің шарттарын бекіту мүмкін болмаса, нәтижені қайталауға уәде бермеңіз.
6. Дәл қазыға берілетін құқықтарды тексеріңіз
Кодты, демоны, деректерді және жазбаны тексеруші алатын құқықтармен ашыңыз. Оларды иесінің есептік жазбасында ашу қазылардың қолжетімділігін растамайды. Шақыру қажет пе және тесттік қолжетімділік қашан аяқталатынын жазыңыз. Жабық репозиторий үшін материалдарды берудің келісілген тәсілін қолданыңыз.
GitHub репозиторийге қолжетімділікті басқаруға мүмкіндік береді. Шақыру мен қажетті құқықтарды қолданбаның жұмысынан бөлек тексеріңіз. Ыңғайлы сілтеме үшін жабық материалдарды жарияламаңыз. Кіру деректерін рұқсат етілген арнамен беріп, README ішінде оларды алу тәртібін қалдырыңыз.
7. Дәлелдерді бағалау критерийлерімен байланыстырыңыз
Жарияланған бағалау критерийлерін алып, жұмысыңызға қатысты әр тармақ үшін тексерілетін орынды көрсетіңіз: сценарий, файл, нәтиже немесе түсіндірме. Өзіңізге балл қоймаңыз және бір іске қосуға сүйеніп өнім дайын деп мәлімдемеңіз.
Өз жұмысыңызды және бастапқы компоненттерді хакатон ережелері талап ететін көлемде сипаттаңыз: дайын код, көмек, кітапханалар және ЖИ қолдану. «Бәрі өзіміздікі» деген сөз үлестің шекарасын түсіндірмейді. Файлға сілтеме мен өзгерістің сипаттамасы қазыға нақты сұрақ қоюға негіз береді.
8. Көмексіз репетиция өткізіңіз
Командаласыңыздан құжатты таза ортада басынан нәтижеге дейін орындауды сұраңыз. Тексеру кезінде тоқтаған жерлері мен қажетті көмекті жазыңыз. Жасырын баптау файлын қолмен жасап немесе деректерді өзгертсеңіз, бұл сипаттап, қайталау қажет сценарийдің бір бөлігі.
Қысқа жазба сақтаңыз: тексерілген коммит, орта, кіріс, қадамдар, күтілетін және нақты нәтиже, тоқтаған қадам, автордың көмегі және шектеулер. Stavleak acceptance kit тексеру нәтижесін рәсімдеуге көмектеседі; оның валидаторы жазба құрылымын тексереді, ал қолжетімділік пен сценарийдің орындалуын адам тексереді.
Тапсырар алдында README, файлдар және жоба формасы арасындағы айырмашылықтарды түзетіңіз. Құжат нұсқасын кодпен бірге сақтап, сілтемелерді қайта тексеріңіз. Сонда питчте нақты тексерілген сценарийге сілтеме жасап, қалған шектеулерді түсіндіріп, қазыға жұмысыңызды қайталауға мүмкіндік бере аласыз.
