Нормально ли думать о проблеме дизайна в течение нескольких дней без написания кода? [закрыто]

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

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

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

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

Это обычно называют «параличом анализа»

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

Рекомендуется прочитать прагматичный программист, в частности главу 2, раздел «Трассировка пуль»

Это совершенно обычное дело. Однако, если вы выберете подход «Сначала тестируй» или TDD, он встречается реже и может помочь тебе лучше сформулировать свои идеи.

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

Это зависит от того, что привело вас к этому и вашим причинам. Вот некоторые из них:

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

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

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

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

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

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

На мой взгляд, существует три подхода, каждый из которых подходит для конкретной ситуации кодирования

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

   => Используйте BDD / TDD, начиная с нужных решений и работая с кодом. (Хорошо, иногда я обманываю и пишу немного кода, а затем тестирую - своего рода вложенный подход 2. -> 1.).

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

   => Прототип, чтобы увидеть, какие интересные вещи появляются. Переходите к 1. когда я выясняю, какие интересные вещи желательны.

3. Я не уверен, какие шаблоны применять.

   => Подумайте о проблеме и о том, как различные способы решения этой проблемы влияют на код. Перейдите к 2) или 1) в зависимости от результата этого упражнения.

Другими словами, ответ любимый инженером: это зависит.

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

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

• Создавайте дизайнерские артефакты. Так что, если вы не пишете код? Может быть, вы просто запишите журнал своих мыслей. Или набросок общего решения. Или даже просто действительно краткое изложение проблемы, которую вы со временем уточняете. Поскольку вы рассматриваете идеи и принимаете / отклоняете их, ведите журнал ваших рассуждений на эту тему. Таким образом, в конце дня вы все еще можете указать на реальные результаты в качестве доказательства вашего труда.

• Поговори с людьми! Нет ничего лучше, чем иметь живого, дышащего человека, с которым можно обсуждать идеи. Если вы думаете, что застряли, обсудите это с кем-то. Хватай кого-нибудь - кого угодно! - и объясни им проблему. Набросайте свои мысли о том, как решить проблему. Даже если все, что они делают, это вдыхают, выдыхают и мигают в течение десяти минут, пока вы болтаете, скорее всего, вы обнаружите новое понимание только в процессе объяснения проблемы .

Как сказал Сатчел Пейдж: «Иногда я сижу и думаю, а иногда просто сижу».

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

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

Программа = Алгоритм + Структура данных

ИМХО, процесс проектирования (решения проблем) полностью правилен. Детали реализации (технические проблемы) следуют и решаются естественным образом.

Вот мой случай мысли.

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

2. Устранение проблемы с существующим кодом Прежде всего, отследите проблему. Это может потребовать некоторого времени не написания реального кода (может быть написан некоторый отладочный код, но обычно это не сохраняется). Как только вы обнаружите проблему, в зависимости от сложности, начните писать код, чтобы попытаться исправить ее. Нужно немного подумать, как только ошибка станет известна. Если проблема окажется серьезным недостатком дизайна, см. Следующий раздел.

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

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

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

Это зависит от того, что вы подразумеваете под «нормальным» . Говоря о себе, я думаю, что код является отличным инструментом обучения. Поэтому, когда я сталкиваюсь со сложной проблемой, я делаю наброски на бумаге, но я также делаю кодирование, основанное на тестировании. Код говорит мне, что думает, что белая доска не может сказать и наоборот, и, возможно, результатом является понимание или необходимость задать еще пару вопросов эксперту по предметной области.

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

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