Як написати мій підхід до вирішення проблем на папері? [зачинено]

Я першокурсник, студент з інформатики, і ми тільки почали робити якісь реальні проекти в Python. Я виявив, що я дуже ефективний, коли використовую метод ручки та паперу, який запропонував мій професор на уроці. Але коли я не можу записати свою проблему і опрацювати свої алгоритми на папері, я дуже повільний. Під час лабораторій мені, здається, завжди доводиться повертати завдання до гуртожитку. Коли я приїжджаю туди і виписую це, я вирішую проблему, яка взяла мене за весь клас приблизно за 5 хвилин.

Можливо, це тому, що я підкреслююсь, бачачи, як люди розв'язують перед собою лабораторії. А може це метод ручки та паперу.

Я переглядав форуми, і хтось написав, що якщо вам доведеться писати свої програми на папері, то ви не повинні бути програмістом. Я дуже переживаю, тому що мені набагато краще, коли я бачу, що робить програма, і відстежую свій шлях через неї, перш ніж набрати фактичний код. Я щось роблю не так?

Редагувати: Вибачте за те, що я зрозумів, але коли я говорив, що пишуть на папері, я мав на увазі підхід до вирішення проблем (наприклад, написання прикладів, створення таблиць зі значеннями тощо) не мій фактичний код. Я просто використовую папір для отримання своїх ідей.

Нічого поганого в тому, щоб спочатку розробити алгоритми на папері. Не стільки для щоденного кодування, скільки для складніших алгоритмів, професійні програмісти постійно їх розробляють на папері або дошці, особливо якщо графічний формат робить це більш зрозумілим. Для студента кожна програма є складною.

Якщо ви хочете краще покращити розробку алгоритмів на комп’ютері, однак є деякі методи, якими ви можете скористатися. Не починайте просто з написання коду, записуйте ті самі речі, які ви розміщували б на папері, як коментарі, а потім розкладайте їх на реальний код або детальніші коментарі по черзі.

Наприклад, якщо я видаляю елемент із середини пов'язаного списку, я можу почати щось із:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Тоді я можу замінити // find the elementфункцію більш псевдокодом і продовжувати роботу, поки не знайду повного рішення. Не думайте, що код потрібно писати лінійно.

Дій! Якщо ми називаємо те, що ти робиш, думаючи та розробляючи рішення, то має сенс, що ваш процес буде набагато швидшим, ніж просто вибух коду.

Люди люблять думати (а галасливі люблять говорити нам), що їх спосіб вчитися краще. Але у кожного вміння та вміння вміння різні. Тож робіть те, що працює для вас. Отримавши практику, ви, ймовірно, перейдете до того, щоб робити більше дизайнерських робіт у вашій голові, і використовуєте папір для більших проблем.

Одне, на що слід звернути увагу, це те, яку форму складатимуть іспити. Чи будуть вони на папері, чи на комп'ютері? Якщо вони на папері, то ваш шлях дасть вам перевагу. Якщо вони базуються на комп’ютері, то це теж добре: зробіть будь-який дизайн на папері, а потім напишіть код. Що б не працювало найкраще!

Я не відкладаю фактичний код на папері, але для чогось нетривіального я майже завжди починаю на дошці або зошиті. Я зазвичай ескізую:

• Алгоритми / процес / контрольний потік
• Структури даних
• Відносини
• Компоненти (як вирішити цю проблему)

Зазвичай це поєднання ескізів, псевдокоду та англійської мови.

Я вважаю, що, роблячи це, легше візуалізувати, коли я починаю кодування. Я також помічу недоліки перед тим, як почати вводити код, тому що я можу побачити все, що переді мною (замість неперервного прокручування та переходу вікон). Мало того, що після того, як це буде виписано, я можу дозволити речей формуватися в моїй душі, коли я працюю над іншими завданнями. Я також можу працювати нелінійним способом, вкладаючи ідею в папір, коли вона потрапляє в мене, а потім повертаюся до неї, коли досягаю тієї точки, де мені це потрібно.

Звернути щось на папір - це величезна допомога для збереження пам’яті. Мітка для торгових марок ноутбуків Field Notes така:

Я не записую це, щоб запам'ятати його пізніше, я записую його, щоб запам'ятати його зараз.

Після більш цілеспрямованого підходу до запису речей на папері, навіть якщо я через хвилину я заробляю запис у додатку ToDo на своєму телефоні, я вважаю, що думка цементується в моїй голові набагато краще, ніж просто робити електронну записку. IOW, плануючи своє кодування на папері / дошці, ідеї краще залишаються в моїй голові.

Він також служить зручною орієнтиром, коли прийшов час документувати те, що я написав.

Я не думаю, що в роботі з кодексом (псевдо або іншим способом) спочатку щось не так - це насправді не відрізняється від написання на дошці, що робить багато людей, коли обговорюють, як вирішити проблему.

Ви пишете перші чернетки рефератів для не-CS класів на папері, перш ніж набирати їх? Насправді я раніше це робив тому, коли я ще був студентом коледжу, але після першого курсу я змусив себе написати всі чернетки на екрані, оскільки це значно спростило написання наступних чернеток, і така ж ідея застосовується до написання коду.

Я б запропонував спробувати ввести свої алгоритми, навіть якщо це просто в текстовому редакторі, як Word. Чим більше ви це зробите, тим комфортніше вам буде не покладатися на папір та ручку. А якщо ваших навичок набору тексту дещо не вистачає, і це насправді джерело ваших розчарувань, пройдіть курс набору тексту! Це було б найкраще, що ви могли зробити для своєї майбутньої кар’єри.

Вирішення проблеми та написання коду, який реалізує ваше рішення, - це дві різні дії.

Якщо ви не знайомі з мовою, ви збираєтесь витратити багато часу на сам код - і недостатньо, щоб знайти хороше рішення. Якщо в цьому плані вам допомагають папір, дошка або починаючи від стелі, то, безумовно, зробіть це.

(Особисто мені здається, що я спускаюся з комп’ютера і гуляю по колах, намагаючись створити рішення в своїй думці)

Ви пройдете співбесіди! Вони змушують писати код на папері або дошці. Я протилежний. Намагатися писати дужки або вирізати та вставляти ручку - це набридливо!

Мій тато використовував багато паперу при програмуванні COBOL. Я думаю, що це просто ваш стиль мислення.

У нас був клас на два семестри під назвою Основи програмування. І тести середини семестру, і іспити в кінці були зроблені на папері. Якщо ви зробили якісь помилки компіляції, ви втратили серйозну кількість балів. Якщо ви зробили величезні помилки компіляції, ви не змогли. Однак я вважаю, що це розвинуло в нас здатність розглядати будь-який код і знаходити рядки-баггі за відносно коротший час.

Немає нічого поганого в тому, що ви робите, я навчився програмувати, використовуючи також папір і ручку.

Як і інші запропонували зробити те, що працює для вас. Я пам’ятаю, що перша програма Java, яку я написав, була переважно на папері, і тоді я провела дві години, набираючи її, і п’ятнадцять хвилин плакала, коли побачила 200+ помилок компілятора. Їх було більше, але компілятор показав би лише перші 200! Я хочу зазначити, що, написавши код на папері, я зміг продумати основний алгоритм та функціональність того, що потрібно зробити програмі. Компілятор вказав на причини, чому моя програма не працює. 90% проблем були поза межами винятків з масивами.

Коли ви отримаєте більше досвіду та впевненості, ви все менше користуєтесь ручкою та папером. Ви вже будете знати, як використовувати базові поняття, такі як петлі тощо. Ви матимете приклади в інших програмах, які зможете повторно використовувати. Ви будете використовувати компілятор і IDE, щоб знайти очевидні помилки під час написання програми. Зараз, хоча у вас немає такого досвіду.

Читаючи ваше запитання, я цікавлюсь, чи можуть деякі ваші проблеми пов’язані з фокусом. Якщо використання ручки та паперу в тихому середовищі допоможе вам зосередитись, то це чудово.

Ти все ще в коледжі і все ще вчишся. Зрештою, все, що ви робите, - це те, що працює для вас. Якщо за допомогою паперу та ручки ви упорядковуєте свої думки та мислення чітко та спокійно, тоді ви програмуєте.

Мій код набагато краще організований, коли я записую нотатки та підходи до блокнота, перевіряю книги, перевіряю Інтернет та замислююся над цим. Я також набагато більше візуальна людина, тому малювання малюнків із структурами даних дуже корисно. Я не записую кожен рядок, але роблю те, що я вважаю "важливими" фрагментами або ключовими функціоналами. Для великих проектів я підпалю Visio. Я не впевнений, чому б хтось виступав за стрибки прямо на клавіатуру, якщо вони не набагато ефективніші або не платять за годину.

Робіть те, що працює для вас. Я б не писав код на папері. Я пишу псевдокод і малюю блок-схеми на папері, але написання повного коду здається марною тратою часу.

Я також зіткнувся з тією ж проблемою в свій початковий день 'вивчення технічних навичок.

Але така практика не повинна давати 100% успіху, оскільки якщо ми пишемо код на папері, то немає жодної шансу виправити помилки, є шанс усунути помилки та винятки під час роботи з папером.

Тому робота з папером не дає ніякої навігації для вирішення проблем. І ми можемо отримати швидкість набору в якості бонусу завдяки системній практиці.

Я також займаюся паперовою роботою, але коли перед впровадженням моєї функціональності просто зробіть приблизну оцінку, після цього я розпочну свою реалізацію в системі.

Будь ласка, спробуйте витратити більше часу на системну практику. Це дасть 100% впевненість і результат.