Каков Ваш Принцип работы для решения (программирование) проблема? [закрытый]

Каждая проблема, которую мне когда-либо приходилось решать на компьютере, имела какое-то отношение к решению задачи в реальном мире. Таким образом, я научился смотреть на то, как я могу достичь чего-то в реальном мире, и соотносить это с компьютерной проблемой.

Пример:

Мне нужно отслеживать оценки своего ученика и выставлять итоговую оценку. это среднее значение всех оценок за год?

Ну, я бы сохранил оценки в журнале (базе данных), и у меня была бы страница для каждого студента (Field StudentID) и так далее ...

Энди Хант Прагматическое мышление и обучение может многое сказать по этому вопросу.

Карандаш, бумага и доска. Если вам нужно больше организации, используйте такой инструмент, как MindManager .

Логика.

Разбейте проблему на части, используйте свой собственный мозг и знания каждого компонента системы, чтобы точно определить, что происходит и почему; затем на основе этого вы обнаружите, где нет проблемы, и, следовательно, определите, где она должна быть.

Сначала я иду в один магазин велосипедов ; или другой .

Как только я пойму, что никто не изобрел этот конкретный велосипед,

• вычислите соответствующие структуры данных для предметной области и проблемы, а затем сопоставьте необходимые алгоритмы для работы с этими структурами данных так, как вы необходимость.

• Разделяй и властвуй. Решите подмножества задачи

Этот алгоритм меня никогда не подводил:

1. Действуй. Часто просто сидеть и испытывать ужас или раздражение от проблемы не поможет ее решить. Кроме того, зачастую проблема не решается никакими размышлениями. Так что вам придется испачкать руки и взяться за решение проблемы.

2. Тест. При каких именно условиях, входных значениях или состояниях возникает проблема? Создайте мысленную модель того, почему именно эти условия могут вызвать проблему. Проверьте аналогичные условия, которые не вызывают проблемы. Проверьте достаточно, чтобы иметь четкое представление о проблеме.

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

4. Упростите. Удалить или прокомментировать код, вставлять значения в переменные, запускать определенные функции с определенными значениями. Изо всех сил старайтесь добраться до сути проблемы, срезая мякину или вещи, которые не имеют отношения к данной проблеме. Скопируйте код в отдельный проект и при необходимости запустите его, чтобы удалить зависимости.

5. Принять. Великий человек сказал: «все, что остается, каким бы невероятным оно ни было, должно быть правдой». Другими словами, после максимально возможного упрощения проблема должна быть в том, что осталось, как бы странно это ни казалось сначала.

6. Логика. Дважды, трижды проверьте логику задачи. Имеет ли это смысл? Что должно быть правдой, чтобы это имело смысл? Вам что-то не хватает? Вы неправильно понимаете алгоритм? Если все остальное не помогает, устраните проблему заново.

В дополнение к шагу 3, в крайнем случае, я часто использую метод двоичного поиска для поиска своенравного кода. Просто прокомментируйте половину кода и посмотрите, исчезнет ли проблема. Если это так, то он должен быть в этой половине (и наоборот). Половина оставшегося кода и продолжение.

Вопрос: Как съесть слона?

Ответ: По кусочку за раз.

Связанный вопрос, который может быть полезен:

Полезные точки зрения, концепции или способы думать о проблемах, которые должен знать каждый новичок

Я использую научный метод :

1. На основе имеющейся информации о проблеме программирования я выдвинул гипотезу о том, в чем может быть причина.

2. Затем я разрабатываю / придумываю эксперимент, который отвергнет или подтвердит гипотезу. Это может быть наблюдение чего-либо в отладчике или вывод на экран / файл. Или немного изменив программу.

3. Если гипотеза отклоняется, повторите 1. Информация, собранная в 2. может помочь в разработке новой гипотезы.

4. Если гипотеза подтверждается, то гипотеза может быть уточнена / уточнена (повторить 1.). Или уже может быть ясно, в чем проблема.

Этот направленный способ найти проблему намного эффективнее, чем изменение вещей наугад, наблюдение за происходящим и попытка (неуместного) использования статистики.

Я всегда сначала пишу о проблеме в блог. Stackoverflow - хорошее место для начала. Зачем тратить время на изобретение колеса, если кто-то другой, возможно, уже решал подобную проблему в прошлом? Во всяком случае, у вас появятся хорошие идеи, чтобы решить эту проблему самостоятельно.

Один из приемов, который мне нравится использовать для действительно больших проектов, - это попасть в комнату с помощью доски и стопки квадратных стикеров.

Напишите свои задачи на стикерах, затем начните наклеивать их на доску.

По ходу работы вы можете заменять слишком большие задачи несколькими заметками.

Вы можете перемещать заметки, чтобы изменить порядок, в котором они выполняются.

Используйте разные цвета для обозначения различной информации; Иногда я использую другой цвет, чтобы обозначить то, над чем нам нужно провести дополнительные исследования.

Это отличный метод для работы с командой. Каждый может видеть общую картину и может внести свой вклад в интерактивной форме.

I'm interpreting this as fixing a bug, not a design problem.

Isolate the problem. Does it always occur? Does it occur only the first time run on a set of new data? Does it occur with specific values, but not with others?

Is the system generating any error message that appear related to the problem? Verify that the error messages are not generated when the problem does not occur.

Has anything been changed recently? Those are likely places to start looking.

Identify the gap between what I know is working (e.g. I can start up the app and attempt to do a query) and what I know is not working (e.g. it gives me an error instead of the expected results). Find an intermediate point in the code where it seems possible to look for a problem (does this contain valid data at this point?). This allows me to isolate the problem on one side or the other of the point I looked.

Read the stack traces. If you have a stack trace, find the first line that mentions in-house code. The problem is not in your libraries. Maybe it will turn out to be, but just forget about that possibly first. The error is in your code. It's not a bug in java, it's not a bug in apache commons HTTP client, it's in code written in your organization.

Think. Come up with something the system could be doing that can cause the symptoms you see. Find a way to validate whether that is what the system is doing.

No possibility the bug is in your code? Google for anything you can think of related. Maybe it is a bug in the library, or poor documentation leading you to use it wrong.

• Google отлично подходит для поиска сообщения об ошибках и распространенные проблемы. Где-то кто-то обычно сталкивался с вашей проблемой раньше и находил решение.

• Карандаш и бумага. Псевдокод и диаграммы рабочих процессов.

• Поговорите об этом с другими разработчиками. Это действительно помогает, когда нужно заставить себя, чтобы упростить задачу для кто-то еще должен понять. У них также может быть другой угол. Иногда трудно увидеть лес за деревьями.

• Сходи погулять. Убери свою голову эта проблема. Сделай шаг назад и попробуй чтобы увидеть большую картину того, что ты хочу добиться. Убедитесь, что проблема, которую вы «пытаетесь» решить, - это та, которую вам «нужно» решить.

• Большая доска - это замечательно для работы. Используйте его для записи рабочих процессов и отношений. Поговорите о том, что происходит с другим членом команды.

• Двигайтесь дальше. Сделай что-нибудь еще. Позвольте вашему подсознанию работать над проблемой. Позвольте решению прийти к вам.

Ответьте на эти три вопроса в следующем порядке:

Q1: Какой желаемый результат?
Меня не волнует, если это салфетка с каракулями. Я хочу что-то осязаемое, что покажет мне, как должен выглядеть конечный результат. Если я не захожу хотя бы так далеко, я останавливаюсь.

Q2: Что это за ввод?
Я выясняю, какие данные я получаю. Откуда эти данные поступают. Какие формулы мне могут понадобиться. Какие могут быть зависимости от A , происходящие до B . Какие разрешения необходимы для получения этих данных. Затем я задаю вопрос 3.

Q3: Достаточно ли входных данных для создания выходных данных?
Если ответ - Нет , то я возвращаюсь к Q2 и получаю дополнительные данные от того, кто может их передать меня.

Для очень больших проблем я разбиваю их на Фазы и применяю Q1 Q2 и Q3 к каждой фазе.

Мой метод, нечто аналитико-синтетическое:

1. Успокойся. Сделайте глубокий вдох. Сосредоточьте свое внимание на том, что вы собираетесь решить. Это может включать прогулку, чистку доски, заказ бумаги для заметок и карандашей, закуски и т. Д. Избегайте стресса.

2. Понимание проблемы на высоком уровне. Если это ошибка, когда это произошло? при каких обстоятельствах? Если это новая задача, попробуйте разойтись в том, какие результаты нужны. Вспомните данные, доказательства, получите описания приемки, возможно, документацию или поговорите с кем-то, кто знает о проблеме.

3. Установите тестовую площадку. Постарайтесь почувствовать себя счастливым с необходимыми инструментами. Используйте данные, собранные на предыдущем шаге, чтобы что-то автоматизировать, надеюсь, ошибку, если это так, или некоторые неудачные тесты в противном случае.

4. Начните синтезировать, резюмируя то, что вы знаете, отражая это в коде. Выполнение один раз и еще раз. Если вас не устраивают результаты, вернитесь ко второму шагу с обновленными идеями, еще больше расходитесь: возможно, примените инструменты (в порядке стоимости), которые помогали раньше, например, разделяйте и властвуйте, отлаживайте, многопоточность, дизассемблируйте, профилируйте, инструменты статического анализа, показатели и т. д. Продолжайте этот цикл, пока не сможете изолировать проблему и пройти тест по телефону .

5. Теперь пришло время исправить это, но у вас есть все инструменты. Это не так уж и сложно. Начните писать код, примените рефакторинг, наслаждайтесь описанием вашего решения в документации.

6. Попросите кого-нибудь опробовать ваше решение. В конце концов, она сможет довести вас до шага 2, но это нормально. Уточните свое решение и повторно разверните.

Вероятно, грубое упрощение:

Но на самом деле , это на 100% верно.

ПОНЯТЬ

Что ты без идеи? У вас может быть проблема, но сначала вы должны определить ее более подробно. У вас есть замороженная пицца, которую вы хотите съесть. Вам нужно приготовить эту пиццу! В программировании это обычно ваш сеанс мозгового штурма для того, чтобы придумать решение с нуля. Здесь вы решаете, какой у вас подход.

ПЛАН

Ну, конечно, вам нужно приготовить эту пиццу! Но как! Вы воспользуетесь духовкой? № Слишком просто . Вы хотите построить солнечную плиту, чтобы вы могли есть эту замороженную пиццу в любом месте, где солнце дает вам энергию для этого. Это ваша фаза дизайна. Это ваша фаза карандаша и бумаги. Здесь вы начинаете формировать связный, пошаговый метод реализации.

ВЫПОЛНИТЬ

Итак, вы собираетесь построить солнечную печь для приготовления замороженной пиццы; вы решили . СЕЙЧАС СДЕЛАЙТЕ ЭТО . Напишите код. Контрольная работа. Зафиксировать. Рефакторинг. Подтвердить.

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

1. Я думаю об этом. У меня уходит от пары минут до нескольких недель, чтобы обдумать проблему и разработать общий план действий.
2. Найдите исходное решение. Это решение, вероятно, недоработано, и один или несколько аспектов могут не работать.
3. Уточните это решение. Продолжайте работать над проблемой, пока я не найду что-то, что решит проблему.
4. (и это может быть сделано на любом этапе процесса) Задавайте вопросы о переполнении стека, чтобы прояснить любые трудности, с которыми я сталкиваюсь на данный момент. ]

1. запишите проблему
2. подумайте очень хорошо
3. запишите ответ

У одного из моих бывших коллег был уникальный Modus Operandi . Всякий раз, когда он сталкивался с сложной проблемой программирования (например, задача с рюкзаком или какая-то нестандартная задача оптимизации ), он забивал камнями травку, заявляя о своей способности визуализировать сложное состояние (например, рекурсивная функция, выполняющая операции с множеством, переданным в стек) была значительно улучшена. Единственная трудность, на следующий день он не смог понять свой собственный код. В конце концов я показал ему TDD, и он бросил курить ...

Следующее относится к ошибке, а не к созданию проекта с нуля (но даже тогда он может сделать и то, и другое, если немного изменить формулировку):

1. Контекст : В чем проблема? Что он предотвращает, делает неправильно или не делает?

2. Контроль : Какие переменные (в широком смысле слова) задействованы? Можно ли воспроизвести проблему?

3. Гипотеза : Имея достаточно данных о том, что происходит или требуется, можно выдвинуть гипотезу, то есть нарисовать мысленный образ рассматриваемой проблемы.

4. Оцените : Сколько усилий, затрат и т. Д. Потребуется для исправления? Определите, является ли это препятствием для шоу или незначительным раздражителем. На данный момент, возможно, еще рано говорить, но даже это форма оценки. Это позволит расставить приоритеты.

5. План : Как подойти к проблеме? Требуются ли спецификации? Если да, сделайте это в первую очередь.

6. Казнить : А.К.А. Самое интересное.

7. Тест : A.K.A. Не очень забавная часть.

Повторите до удовлетворения. Наконец:

Отзыв : как это случилось? Что привело нас сюда? Можно ли это предотвратить, и если да, то как?

РЕДАКТИРОВАТЬ:

На самом деле резюмируйте, остановитесь, проанализируйте, действуйте.

Никто не упомянул таблицы истинности! Но это, вероятно, потому, что они обычно не очень полезны;) (хотя ваш опыт может отличаться) Я использовал один вчера впервые за 8 лет программирования.

Рисование диаграмм на доске или бумаге всегда было для меня очень полезным.