При решении любой проблемы программирования, каков ваш modus operandi? Как вы исправляете проблему?
Вы пишете все, что можете, о наблюдаемом поведении ошибки или проблемы?
Возьмите меня через ментальный контрольный список действий, которые вы совершаете.
(Как говорится - First, solve the problem. Then, write the code)
Отойдите от компьютера и возьмите бумагу и ручку или карандаш, если хотите.
Если я рядом с компьютером, то я пытаюсь запрограммировать решение прямо тогда и там, и он нормально работает неправильно или просто дерьмо. Ручка и бумага заставляют меня думать немного больше.
Сначала я перехожу в один магазин велосипедов; или другой.
Как только я думаю, никто не изобрел этот велосипед,
Выясните соответствующие структуры данных для домена и проблемы, а затем нарисуйте необходимые алгоритмы для работы с этими структурами данных так, как вам нужно.
Разделите и победите. Решить подмножества задачи
Этот алгоритм мне никогда не подводил:
Принять меры. Часто просто сидеть там и быть в ужасе или недоволен проблемой не поможет его решить. Кроме того, часто, никакое количество мышления не решит проблему. Таким образом, вы должны загрязнять руки и сражаться с проблемой.
Тест. В каких именно условиях, входных значениях или состояниях возникает проблема? Сделайте ментальную модель того, почему эти конкретные условия могут вызвать проблему. Проверьте аналогичные условия, которые не вызывают проблемы. Испытайте достаточно, чтобы у вас было четкое понимание проблемы.
Визуализировать. Поместить код отладки в, содержимое переменной дампа, код одного шага. Делайте все, что точно разъясняет, что происходит там, где - в проблемных условиях.
Упростить. Удалить или прокомментировать код, выставить значения в переменные, запустить определенные функции с определенными значениями. Постарайтесь изо всех сил решить проблему, отрезав мякину или материал, который не имеет отношения к проблеме. Скопируйте код в отдельный проект и запустите его, если потребуется, для удаления зависимостей.
Примите. Великий человек сказал: "все, что остается, каким бы невероятным оно ни было, должно быть правдой". Другими словами, после упрощения, насколько это возможно, все, что осталось, должно быть проблемой, как бы странно это ни казалось.
Логика. Двойная, тройная проверка логики проблемы. Имеет ли это смысл? Что должно быть правдой, чтобы это имело смысл? Вам что-то не хватает? Неправильно ли вы понимаете алгоритм? Если все остальное не удается, переустановите проблему.
В качестве дополнения к шагу 3, в качестве крайней меры, я часто использую метод двоичного поиска для поиска обратного кода. Просто прокомментируйте половину кода и посмотрите, исчезнет ли проблема. Если это так, то это должно быть в этой половине (и наоборот). Половина оставшегося кода и продолжайте.
Google отлично подходит для поиска сообщения об ошибках и общие проблемы. Где-то кто-то обычно сталкивался с вашей проблемой раньше и нашел решение.
Карандаш и бумага. Псевдокод и диаграммы рабочего процесса.
Общайтесь с другими разработчиками. Это действительно помогает, когда вы вынуждены самостоятельно упростите проблему для кому-то еще понять. Они также могут иметь другой угол. Иногда трудно увидеть лес через деревья.
Идите на прогулку. Выньте голову из проблема. Сделайте шаг назад и попробуйте увидеть большую картину того, что вы хочу достичь. Убедитесь, что проблема, которую вы пытаетесь решить, - это та, которая вам нужна.
Большая доска отлично работает. Используйте его для записи рабочих процессов и отношений. Расскажите, что происходит с другим членом команды.
Двигайтесь дальше. Сделайте что-нибудь еще. Пусть ваше подсознание работает над проблемой. Позвольте решению прийти к вам.
Я не могу поверить, что никто не опубликовал это уже:
Запишите свою проблему в StackOverflow, и пусть куча других людей решит ее для вас.
Мой метод, что-то аналитически-синтетическое:
Успокойся. Сделайте глубокий вдох. Сосредоточьте свое внимание на том, что вы собираетесь решать. Это может включать в себя прогулку, чистку доски, получение закачиваемой бумаги и карандашей, некоторые закуски и т.д. Избегайте стресса.
Высокое понимание проблемы. В случае, если это ошибка, когда это произошло? в каких обстоятельствах? Если это новая задача, постарайтесь расходиться с тем, какие результаты необходимы. Вспомните данные, доказательства, получите описания приемки, возможно, документацию или поговорите с кем-то, кто знает о проблеме.
Установите тестовую площадку. Постарайтесь чувствовать себя довольными необходимыми инструментами. Используйте данные, собранные на предыдущем шаге, чтобы автоматизировать что-то, надеюсь, ошибка, если это произойдет, некоторые неудачные тесты в противном случае.
Начните сглаживать, подытоживая то, что вы знаете, что отражается на коде. Выполнение раз и навсегда. Если вы недовольны результатами, вернитесь к шагу два с новыми идеями, расходитесь больше: возможно, применяйте инструменты (в порядке стоимости), которые помогли раньше, то есть делят и обрабатывают, отлаживают, многопотоковые, дизассемблирующие, профильные, статические инструменты анализа, метрики и т.д. Получите этот цикл, пока не сможете изолировать проблему и передать по телефону.
Теперь пришло время исправить это, но у вас есть все инструменты. Это не будет так много неприятностей. Начните писать код, применяйте рефакторинг, наслаждайтесь описанием своего решения в документах.
Попросите кого-нибудь попробовать ваше решение. В конце концов, она может заставить вас сделать шаг 2, но это нормально. Уточните решение и выполните повторное развертывание.
Я интерпретирую это как исправление ошибки, а не проблемы с дизайном.
Изолируйте проблему. Всегда ли это происходит? Это происходит только в первый раз, когда запускается набор новых данных? Это происходит с определенными значениями, но не с другими?
Является ли система генерирующей сообщение об ошибке, которое связано с проблемой? Убедитесь, что сообщения об ошибках не генерируются, когда проблема не возникает.
В последнее время что-то изменилось? Вероятно, это места для начала.
Определите пробел между тем, что я знаю (например, я могу запустить приложение и попытаться выполнить запрос), и то, что я знаю, не работает (например, оно дает мне ошибку вместо ожидаемых результатов). Найдите промежуточную точку в коде, где кажется возможным найти проблему (на данный момент это содержит достоверные данные?). Это позволяет мне изолировать проблему с одной стороны или другой точки, которую я смотрел.
Прочитайте трассировку стека. Если у вас есть трассировка стека, найдите первую строку, в которой упоминается внутренний код. Проблема не в ваших библиотеках. Может быть, это окажется, но просто забудьте об этом, возможно, в первую очередь. Ошибка в коде. Это не ошибка в java, это не ошибка в apache commons HTTP-клиент, она в коде, написанном в вашей организации.
Думать. Придумайте что-то, что может сделать система, которое может вызвать симптомы, которые вы видите. Найдите способ проверки того, что делает система.
Нет ошибки в вашем коде? Google за все, о чем вы можете думать. Возможно, это ошибка в библиотеке или плохая документация, которая приведет вас к неправильному использованию.
Логика.
Прервите проблему, используйте свой собственный мозг и знания о каждом компоненте системы, чтобы точно определить, что происходит и почему; то на основании этого вы обнаружите, где проблема не существует, и, следовательно, определите, где она должна быть.
Я перестаю работать над этим до завтра. На следующий день я обычно решаю свою проблему в душе. Я нахожусь в стороне от этой проблемы и позволяю моему мозгу очистить, дает свежую перспективу в этом вопросе.
Ответьте на эти три вопроса в этом порядке:
Q1: Какой нужный результат?
Мне все равно, если это салфетка с надписью на ней. Я хочу что-то ощутимое, которое покажет мне, как должен выглядеть конечный результат. Если я не получу хотя бы это далеко, я остановлюсь.
Q2: Что такое ввод?
Я узнаю, какие данные у меня есть. Откуда эти данные. Какие формулы мне могут понадобиться. Какие зависимости могут быть на A, которые происходят до B. Какие разрешения необходимы для получения этих данных. Затем я задаю вопрос 3.
Q3: Есть достаточно ввода для создания вывода?
Если ответ Нет, то я возвращаюсь к Q2 и получаю больше информации от того, кто может передать его мне.
Для очень больших проблем я разбиваю их на Фазы и применяю Q1 Q2 и Q3 к каждой фазе.
Перефразируя Дугласа Адамса, программирование легко. Вам нужно только смотреть на пустой экран, пока ваш лб не истечет кровью. Для людей, которые брезгливы об их лбах, мой идеальный архитектор и сборка для больших проблем будет выглядеть примерно так. (Для небольших проблем, таких как George Jempty, я могу рекомендовать алгоритм Фейнмана.)
То, что я пишу, составлено в бизнес-настройках на месте, но есть аналоги в открытых или распределенных командах. И я не могу притворяться, что каждый, или даже самый, проекты выделяются таким образом. Это всего лишь серия событий, о которых я мечтаю, и время от времени происходит.
Получить расширенное, краткое предупреждение о том, что проблема может выглядеть. Это не полная, заключительная встреча, а неофициальная дискуссия. Неопределенность в некоторых спецификациях подробно прекрасна, если клиент (или менеджер) честен. Затем возьмите лист бумаги или текстовый редактор и попытайтесь сконденсировать то, что вы узнали, до пяти важных пунктов, а затем попытайтесь сконденсировать их до одного предложения. Будьте счастливы, что вы можете представить основные проблемы (проблемы), которые необходимо решить, без ссылки на любую вашу документацию.
Подумайте об этом, возможно, через пару часов, возможно, играя с кодом и прототипом, но не с полной архитектурой: вы должны делать другие вещи, если у вас есть время, или пойти на ходить. Это здорово, если вы можете узнать о работе за час до домашнего времени, чтобы принять решение около полудня на следующий день, чтобы вы спали на нем. Проведите время, глядя на потенциальные библиотеки, рамки, стандарты данных. Попытайтесь связать, по крайней мере, два языка или ресурсы (например, Javascript на PHP-сгенерированном HTML или получить Python-заглушку, говорящий RPC с веб-службой). Извлечь основные проблемы; увеличить детали; уменьшите масштаб, чтобы убедиться, что вся форма все еще различна и имеет смысл.
Отправьте любые вопросы клиенту или руководителю задолго до встречи, чтобы обсудить как проблему, так и предлагаемое решение. Пригласите как можно больше заинтересованных сторон и ваших программистов, насколько это удобно (и по мере того, как ваш менеджер доволен.) Объясните проблему им, как вы ее видите, затем предложите свое решение. Объясните как можно больше; отправьте технические детали на свою аудиторию, но также позвольте вашим объяснениям заполнить более подробную информацию в вашей собственной ментальной модели.
Итерации на 2 и 3, пока все не будут счастливы. Счастье является специфичным для домена. Для вашей отрасли могут потребоваться диаграммы UML и цитаты с позициями или, возможно, они будут довольны тем, что помещается на доске с почти невидимым маркером сухости. Убедитесь, что у всех одинаковые ожидания от того, что вы собираетесь построить.
Когда ваш клиент или менеджер счастлив, что вы начнете, очистите все. Закройте Twitter, мессенджер, IRC и электронную почту в течение часа или двух. Начните с общей структуры, как вы ее видите. Отбросьте часть своего кода прототипа и убедитесь, что он прав. Если это не так, измените структуру как можно раньше. Но прежде всего убедитесь, что ваши коллеги предоставят вам пару часов пространства. Старайтесь не бороться с пожарами в это время. Начните с хорошего сердца и приветствия, и интерес к проекту. Когда вы увязнете позже, вы будете рады ясности, которая вышла из этих первых нескольких часов.
Как ваше программирование идет оттуда, зависит от того, что это на самом деле, и какие задачи должен выполнять готовый код. И как вы в конечном счете архитектируете свой код и какие внешние ресурсы вы используете, всегда будет определяться вашим опытом, предпочтениями и знаниями домена. Но дайте вашему проекту и его группе заинтересованных сторон самое обнадеживающее, самое захватывающее и самое активное занятие, которое вы можете сделать.
Карандаш, бумага и доска. Если вам нужна больше организации, используйте инструмент, например MindManager.
Энди Хант Прагматическое мышление и обучение может многое сказать по этому вопросу.
Вопрос: Как вы едите слона?
Ответ: Один укус за раз.
Один из методов, который мне нравится использовать для действительно больших проектов, - это попасть в комнату с доской и кучу квадратов Post-it Notes.
Напишите свои задачи в Post-it Notes, затем начните их прикреплять на доске.
По мере того как вы идете, вы можете заменить слишком большие задачи несколькими заметками.
Вы можете перемещать заметки вокруг, чтобы изменить порядок выполнения задач.
Используйте разные цвета для указания различной информации; Иногда я использую другой цвет, чтобы указать, что нам нужно делать больше исследований.
Это отличный способ работы с командой. Каждый может видеть большую картину и может внести свой вклад в интерактивный способ.
Вероятно, грубое упрощение:
Но на самом деле, это верно на 100%.
зачать
Что ты без идеи? У вас может быть проблема, но сначала вы должны определить ее более четко. У вас есть замороженная пицца, которую вы хотите съесть. Вам нужно приготовить эту пиццу! В программировании это обычно ваш мозговой штурм, чтобы найти решение от бедра. Здесь вы решаете, каков ваш подход.
ПЛАН
Ну, конечно, вам нужно приготовить эту пиццу! Но как! Вы будете использовать духовку? Слишком просто. Вы хотите построить солнечную плиту, чтобы вы могли есть замороженную пиццу в любом месте, где солнце дает вам силы для этого. Это ваша фаза дизайна. Это ваша фаза карандаш и бумага. Именно здесь вы начинаете формировать связный, пошаговый метод реализации.
ВЫПОЛНИТЬ
Ну, вы собираетесь построить солнечную печь для приготовления замороженной пиццы; ты решил СЕЙЧАС ДЕЛАЙТЕ ЭТО. Написать код Тестовое задание. Commit. Рефакторинг. Commit.
У одного из моих бывших коллег был уникальный Modus Operandi. Всякий раз, когда возникает проблема с жестким программированием (например, проблема с рюкзаком или какой-то нестандартный ), он будет забивать камнями на сорняке, заявив, что его способность визуализировать сложное состояние (например, рекурсивную функцию, выполняющую операции над множеством, переданным в стеке) значительно улучшилось. Единственная трудность, на следующий день он не мог понять свой собственный код. Поэтому в конце концов я показал ему TDD, и он бросил курить...
Ниже приведен пример ошибки, а не создания проекта с нуля (но даже тогда он мог бы сделать оба варианта, если он был изменен):
Контекст. В чем проблема? Что это предотвращает, делает неправильно или не делает?
Контроль. Какие переменные (в широком смысле слова) задействованы? Можно ли воспроизвести проблему?
Гипотеза. Имея достаточно данных о том, что происходит или требуется, можно предположить, то есть нарисовать мысленный образ рассматриваемой проблемы.
Оценить. Сколько усилий, затрат и т.д. потребуется для коррекции? Определите, является ли это пробной пробкой или незначительным раздражителем. На данный момент, возможно, еще слишком рано говорить, но даже это форма оценки. Это позволит определить приоритеты.
План. Как будет затронута проблема? Требуется ли спецификация? Если да, сделайте их сначала.
Выполнить: A.K.A. Веселая часть.
Тест: A.K.A. Не очень забавная часть.
Повторите к удовлетворению. Наконец:
Обратная связь: как это получилось? Что привело нас сюда? Может ли это быть предотвращено, и если да, то как?
EDIT:
Реально суммировать, останавливать, анализировать, действовать.
Я пишу его на листе бумаги и начинаю с моей ужасной диаграммы классов или блок-схемы. Затем я пишу это на липких заметках, чтобы разбить его на "TO DO's".
1 липкая заметка = 1 задача. 1 брошенная липкая записка = 1 законченная задача. Это работает для меня до сих пор.
Добавьте проблему в StackOverflow, подождите около 5-10 минут, и у вас обычно есть блестящее решение!:)
Каждая проблема, которую мне когда-либо приходилось решать на компьютере, имела какое-то отношение к решению задачи в реальном мире. Поэтому я научился смотреть, как я должен что-то сделать в реальном мире и сопоставить это с компьютерной проблемой.
Пример:
Мне нужно отслеживать оценки моих учеников и придумывать окончательный класс, который в среднем соответствует всем классам в течение года?
Хорошо, я бы сохранил оценки в журнале (базе данных), и у меня была бы страница для каждого ученика (Field StudentID) и так далее...
Связанный с этим вопрос, который может быть полезен:
Полезные точки зрения, концепции или способы думать о проблемах, которые должен знать каждый новичок
Я сначала беру проблему в блог. Stackoverflow будет хорошим местом для начала. Зачем тратить свое время на повторное изобретательство колеса, когда кто-то еще, возможно, уже решил аналогичную проблему в прошлом? Если что-нибудь, вы получите некоторые хорошие идеи для его решения самостоятельно.
Я использую научный метод:
На основе имеющейся информации о проблеме программирования я придумываю hypothesis о том, что может быть причиной.
Затем я проектирую/придумываю эксперимент, который отклонит или подтвердит гипотезу. Это может наблюдаться в отладчике или выходе экрана/файла. Или немного измените программу.
Если гипотеза отвергнута, повторите 1. Информация, собранная в 2., может помочь придумать новую гипотезу.
Если гипотеза подтверждена, гипотеза может быть уточнена/уточнена (повторение 1). Или уже может быть ясно, в чем проблема.
Этот направленный способ поиска проблемы намного эффективнее, чем случайное изменение вещей, наблюдать, что происходит, и пытаться (неуместно) использовать статистику.
Никто не упомянул таблицы истинности! Но это, вероятно, потому, что они, как правило, только немного полезны;) (хотя ваш пробег может меняться), я использовал один в первый раз вчера за 8 лет программирования.
Диаграммирование на досках или бумаге всегда было очень полезно для меня.
Когда сталкиваются с очень странными ошибками. Пример: JPA перестает работать после перераспределения в стеклянной платке
Я начинаю с нуля. Сделайте новый проект. Это работает? Да. Начните воссоздавать компоненты моего приложения один раз. DB. Проверьте. Развертывание. Проверьте. Пока это не сломается. Продолжайте, пока он не сломается. Если он никогда не сломается. ОК. Вы просто воссоздали все свое приложение. Отбросить старый. Когда он ломается. Вы точно определили проблему.
Это мои приоритетные методы
ЗОЛОТОЙ СОВЕТ
Никогда не сдавайся. Постоянство всегда будет выигрывать