Q1. Чи допомагали ви своїм однокласникам з тестами або вправами? Якщо так, то як?
Так, я допомагав своїм однокласникам як з тестами, так і з вправами. Перед тестами ми перевіряли один одного з тем, які обговорювали на попередніх заняттях, і переглядали важливі нотатки, які ми записали, зосереджуючись на тому, що, на нашу думку, може бути в тесті. Під час тестів, після того як я прочитав кожне питання, я додавав свої зауваження, діллячись релевантними пунктами, які я пам’ятав з наших записів і лекцій, щоб допомогти нам прийти до правильної відповіді. Щодо вправ, я допомагав подвійно перевіряти тестові випадки, які ми вважали неправильними, порівнюючи їх з правильними. Ми обговорювали проблеми в коді, аналізували, що може бути причиною проблеми, і разом вирішували, які зміни потрібно внести, щоб виправити код. Ця командна робота допомогла нам ефективніше підходити до тестів та вправ.
Q2. Що ви думаєте про документ Paper #2: Makefile і як можна покращити його?
Спочатку я знайшов Makefile в Paper #2 досить заплутаним, оскільки я ніколи не створював його самостійно, хоча використовував його на роботі та на заняттях. Багато рядків в Makefile було важко зрозуміти на початку. Однак, працюючи з моїми нотатками і переглядаючи коментарі від однокласників, я зміг скласти картину того, як функціонують процеси та що саме роблять конкретні прапорці в кожній команді.
Щоб покращити документ, було б корисно включити короткий опис або пояснення кожної секції Makefile. Коротке пояснення призначення основних рядків або команд допомогло б студентам чіткіше пов'язати код з його загальною метою.
Q3. Що ви думаєте про твердження, модульні тести, покриття, виключення, і як це можна покращити?
Обговорення на лекціях допомогло мені краще зрозуміти, як ефективно використовувати твердження як у завданні, так і загалом. Я дізнався, що твердження корисні для перевірки передумов, післяумов і інваріантів циклів. Однак вони не підходять для обробки введення користувача або модульних тестів. Якщо твердження не проходить під час модульного тесту, це зупиняє програму і перешкоджає виконанню наступних тестів, що є непотрібним.
У своєму досвіді з модульними тестами я краще зрозумів їх призначення в оцінці конкретних функцій у коді. Кожна функція або допоміжна функція повинна мати власний тест, щоб переконатися, що кожна частина працює так, як очікується. Це відрізняється від тестів вводу-виводу, які оцінюють всю програму лише за вихідними даними. Модульні тести зосереджуються на перевірці менших частин коду, що робить їх важливими для ефективного виявлення та ізоляції проблем.
Щодо покриття, стало зрозуміло, чому важливо прагнути до 100% покриття нашими модульними тестами. Це гарантує, що кожна частина коду тестується належним чином. Однак я також зрозумів, що не тільки кількість тестів має значення, але й якість тестів. Написання змістовних тестів гарантує покриття нашого коду.
Після того, як я дізнався про ці інструменти та їх застосування до проєкту та коду загалом, я знайшов їх надзвичайно корисними. Щоб ще більше покращити розуміння, було б добре мати більше практичних занять, спрямованих на написання ефективних модульних тестів і прагнення до конкретного відсотка покриття коду, можливо, в рамках вправи. Проте лекції були дуже інформативними і забезпечили мені міцну основу для використання цих інструментів.
Q4. Ваші поради або підказки тижня?
Моя порада тижня — практикуйте пояснення вашого коду простими, не технічними термінами. Часто бувають ситуації, коли потрібно описати свій проєкт або код людині, яка не знайома з програмуванням, наприклад, менеджеру, клієнту чи кінцевому користувачу.
Замість того, щоб занурюватися в технічні деталі, зосередьтеся на тому, що робить код і як він сприяє досягненню загальних цілей або вирішує проблему. Ця навичка є надзвичайно цінною, оскільки вона допомагає створити місток між технічними та не технічними зацікавленими сторонами, забезпечуючи, щоб кожен учасник розумів і оцінював виконану роботу. Чітке спілкування також допомагає побудувати довіру, узгодити очікування та зробити співпрацю більш плавною.
Перекладено з: CS 371p Spring 2025: Emely Diaz