Как понять любую задачу программирования

1656536308 kak ponyat lyubuyu zadachu programmirovaniya

от Джастина Фуллера

feW6Ejqa6pqgNXUImC6JCHOxMRopaY5QZyS7

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

Итак, что делать? Следует ли просто начать и надеяться, что это сработает? Следует ли немедленно сказать своему начальнику, что вы не можете этого делать, потому что не понимаете?

Я думаю, что вы знаете, что ответ нет!

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

Но не переживайте! У меня отличные новости. Вы не только можете решить эту проблему, но это также может быть полезно.

Это означает, что вы определенно расширяете свои навыки и знания за пределы того, что вы делали и знали раньше.

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

О «требованиях»

Может быть, вы заметили, что я использовал слово «требования». Это слово может иметь определенные коннотации в зависимости от того, где вы работаете.

По моему опыту крупные компании любят требования, а маленькие компании иногда «не выполняют требований». Я думаю, что для наших целей это вполне нормально.

Это потому, что в конечном счете все, что мы делаем как инженеры программного обеспечения, – это решение проблем.

Вы можете получить большой отчет на сто страниц о том, как решить эту проблему (когда-то у меня была часовая встреча по тексту для кнопки). Или ваш генеральный директор подойдет к вашему столу и случайно спросит, сможете ли вы решить проблему до пятницы.

В любом случае – вам дали задачу, и вы должны быть уверены, что вы полностью понимаете эту проблему, чтобы правильно ее решить!

О шагах

изображение-57

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

На многие вопросы можно не ответить из-за предъявляемых вам требований или только из-за вашего личного опыта.

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

Но это хорошо. Это означает, что вы будете брать разрозненные знания и сгущать их для размещения в одном месте. Это место у вас, и теперь вы сможете добиться наилучшего результата!

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

На этом шаге вы попытаетесь понять что вас попросили сделать. Вы не пытаетесь понять как сделать это еще!

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

Классифицируйте задачи

Классифицировать задачу означает определить, какую работу вы будете делать для решения этой проблемы. Вот несколько примеров типов задач:

  • Исправление ошибки
  • Новая функция
  • Новая программа
  • Исследовательская задача
  • Повышение производительности

Помните, что это не все возможные варианты.

Цель здесь – определить, что вид работы, которую вы ожидаете выполнить. Это важно, поскольку оно оказывает непосредственное влияние на что работу, которую вы совершаете.

Этот шаг особенно важен для нечетких требований. Пример нечеткого требования: «Нам нужен способ очистить кэш наших клиентов после обновления веб-сайта».

Интерпретаций может быть несколько.

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

На этом этапе, если вы не совсем уверены, какое значение используется, вам следует попросить разъяснения, прежде чем продолжить.

Укажите, что такое задача, одним-двумя простыми предложениями.

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

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

Вот хороший пример итога: «Когда мы обновляем сайт, мы добавляем уникальный номер в файлы, чтобы браузер знал, что ему нужно использовать последний код».

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

Плохой пример может выглядеть так: Когда мы обновляем сайт, мы добавляем уникальный номер в файлы, чтобы браузер знал, что ему нужно использовать последний код. Мы также должны отправить сообщение нашему CDN, чтобы он узнал, что ему нужно обновить файлы. Кроме того, для приложений iOS и Android потребуется отправить обновления в магазин приложений. Также…”

Этот явно провалил тест. Предстоит много работы, и, возможно, ее нужно будет идентифицировать и отследить отдельно.

Обозначите основные части

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

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

Эти должны нет быть пошаговым или подробным руководством по решению проблемы.

Помните, что вы все еще анализируете задание, которое вам дали. Я бы рекомендовал как-нибудь их записать. Я лично записываю их в своем приложении Notes.

Наша задача кэширования очень проста и на самом деле может не нуждаться в структуре. Для этого примера мы рассмотрим более сложную проблему.

Следующая задача — новая функция: «Каждому пользователю должна быть показана целевая реклама внутреннего продукта. Это объявление должно быть приспособлено в соответствии с их индивидуальными потребностями на основе собранных нами данных».

Чтобы определить основные части, вам нужно будет четко подумать о том, что потребует каждая часть требования.

  • Наши текущие рекламные объявления нужно разбить так, чтобы они соотносились с определенными показателями пользователей.
  • Наша маркетинговая команда должна иметь способ сопоставить новую рекламу с частью или частями пользовательских данных (без кодирования!)
  • Системе нужно будет свести показатели пользователя, имеющие отношение к нашей рекламе.
  • Наконец, вам нужно создать систему, получающую идентификатор пользователя и выводящее рекламное объявление.

Прелесть такого списка в том, что его можно использовать для быстрой проверки с вашей командой или боссом! Так что в этом примере, возможно, вы руководили им руководителем вашей команды, и он решил, что должна быть еще одна важная часть:

  • Пользователи должны иметь возможность сообщать нам, когда они не хотят видеть определенные объявления.

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

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

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

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

Определите проблему или проблему, которую вы пытаетесь решить.

Ответьте на вопрос: «Почему кто-то будет использовать это?» или «Какую фактическую или мнимую проблему реального мира я пытаюсь решить?»

Надеюсь, ответ очевиден. Для нашего примера кэша можно сказать: «пользователи будут всегда видеть последние обновления». Например с рекламой: «пользователи будут видеть релевантные объявления вместо объявлений, которые им не интересуют».

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

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

В этот момент вы должны понимать, что вы будете делать и почему вы это делаете.

Вашим следующим шагом будет понимание деталей того, что вы делаете, как от вас ожидают и почему вы это делаете именно так.

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

Термины могут быть деловыми терминами, такими как названия продуктов, клиентов или процессов. Они также могут быть терминами разработки, такими как названия инструментов, программ, моделей, служб или библиотек.

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

Возможно, вы понимаете, что вам нужно создать способ доступа к агрегированной информации пользователя, но понимаете ли вы, что значит добавить ее в «dao»?

Возможно, вы понимаете, что вам нужно отформатировать рекламные данные, но понимаете ли вы, что такое MADF (канал данных о маркировке)?

Я тоже.

Вот почему вы должны определить и определить все важные термины. У вас есть больший шанс неправильно реализовать задачу, если вы неправильно определяете.

Определите, как нужно выполнить задание

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

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

Другие подробно расскажут о каждом вашем шаге.

Скорее всего, ваш опыт попадает где-нибудь посередине.

Если ваша команда не дала вам инструкций, вы не можете сделать многое на этом этапе. Если вам дали инструкции, на этом этапе вы захотите начать знакомство с шагами, которые вам нужно сделать.

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

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

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

Определите, были ли решены проблемы

Именно здесь объединяются этап анализа и этап интерпретации. На этапе анализа вы сосредоточились на общих целях и результатах что и почему.

На шаге интерпретации вы сосредоточились на деталях, как.

Причина, по которой это называется интерпретацией и оценкой, заключается в том, что вы теперь будете сравнивать «как», «что» и «почему». Вы интерпретируете детали, рассматривая общую картину. Вы оцените детали и определите, была ли решена первоначальная проблема.

Спросите себя: приведут ли предпринятые мне шаги к результату, который ваша задача должна была создать? Действительно ли этот результат решит первоначальную проблему?

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

На этом этапе вы должны с уверенностью заявить, что понимаете проблему и ее решение. Последний шаг – убедиться, что у вас есть правильно решение.

Чтобы создать лучший продукт, мы все должны чувствовать, что мы должны говорить, когда что-то просто не имеет смысла.

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

Давайте установим некоторые основные правила по разногласиям.

Знайте, когда не согласиться

  • Не спорьте, пока не поймете полностью.

Никогда не говорите, что не так, пока не будете абсолютно уверены, что понимаете, с чем вы не согласны.

Если вы не можете сформулировать проблему и намеченное решение, вы не должны не соглашаться. Если вы не подтвердили свое понимание, вы не должны соглашаться. Только тогда, когда вы знаете, что имеете наиболее полное понимание, вы должны начинать не соглашаться.

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

  • Не соглашайтесь в субъективных вопросах. Сосредоточьтесь на реальных потенциальных проблемах.

«Мне не нравится, как это делается» – это субъективно. «Это повлечет за собой проблемы с производительностью из-за количества задействованных операций». является объективной причиной. Другие примеры субъективных причин могут включать: «Это не так, как я делал это в других местах» и «Я бы спроектировал это решение несколько иначе, но только из-за личных предпочтений».

  • Подготовьте для представления хорошо аргументированные пояснения ваших разногласий.

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

Кроме того, если у вас нет решения, чтобы исправить это, ясно скажите в начале, что вы не знаете.

Будьте осторожны, если вы не согласны с другими. Большую часть своего времени следует тратить на понимание и выслушивание, прежде чем вы не соглашаетесь.

Если вы проделали все шаги к этому моменту, то, скорее всего, вы хорошо понимаете. Но будьте очень осторожны, чтобы не думать, что вы могли что-нибудь пропустить!

Мне нравится начинать разговор со слова: «Я не согласен с вами, я просто не понимаю». Позже приходит расхождение, если это необходимо, но, надеюсь, никогда раньше понимание.

Знайте, как не согласиться

Чтобы убедиться, что мы не соглашаемся объективно, вот несколько мер, которые помогут вам определить, действительно ли ваше несогласие.

Объективные разногласия приводят к одному или нескольким из следующего:

  • Покажите, что решение неинформировано.
  • Покажите, что решение дезинформировано.
  • Покажите, что проблема или решение нелогично.
  • Покажите, что решение является неполным.

Быть неинформированным – это не оскорбление, а это означает, что информации не хватало, когда было создано решение. Возможно, они не знали о системе, которая сейчас существует и может выполнять необходимые действия.

Быть дезинформированным означает, что решение пришло из неверной информации.

В этом случае они могут подумать, что существующая система делает то, чего она действительно не делает. К примеру, возможно, команда SEO (поисковая оптимизация) попросила вас проиндексировать Google страницу входа в вашем приложении. Google не может этого сделать. Их дезинформировали о том, что делает веб-сканер Google.

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

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

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

Помните, не преувеличивайте этот процесс. Это должно быть быстрым и, вероятно, состоять из записи нескольких мнений в вашем приложении Notes. Тогда это может привести к разговорам с вашими коллегами, чтобы прояснить, что вы должны делать. Это все!

Вот упрощенный список шагов:

Шаг 1 — Анализ

  • Классифицировать
  • Резюме
  • Контур
  • Определите проблему

Шаг 2 — Интерпретация и оценка

  • Уточняйте условия
  • Определите задачу
  • Определите, будет ли проблема решена

Шаг 3 – подумайте критически

  • Знайте, когда не согласиться
  • Знайте, как не согласиться

Привет, я Джастин Фуллер. Я очень рада, что ты прочел мой пост! Я хочу сообщить вам, что все, что я здесь написал, является моим собственным мнением и не имеет цели представлять моего работодателя любой способ. Все образцы кода мои и совершенно не связаны с кодом Bank Of America.

Я также хотел бы услышать от вас, пожалуйста, свяжитесь со мной на LinkedIn, Github или Medium. Еще раз спасибо за прочтение!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *