Что делать, если у меня нет хороших идей для реализации функции? [закрыто]


32

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

Мне нужно двигаться дальше, но я хочу знать, что лучше:

  • Думай больше, жди больше и продолжай искать лучший подход
  • Хватит тратить время и начните с плохого дизайна, покрывая все тестами

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



12
@gnat: Эти другие вопросы касаются ситуаций, когда спрашивающие уже знают, как правильно реализовать некоторые функции, но, возможно, захотят пожертвовать хорошим дизайном, чтобы быть «быстрым и грязным». Этот вопрос, однако, описывает другую ситуацию, речь идет о решении проблем в целом, когда вы вообще не находите подходящую точку для начала, поэтому ИМХО не является дубликатом.
Док Браун

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

Ответы:


41

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

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

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


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

1
Другой недостаток этого подхода иногда приводит вас к: «Я могу решить проблему X. Осталось только сделать Y». когда в действительности Y неосуществим, и реальное решение - Z.
Brian

@RichSmith, Брайан: Это случается, хотя редко, если вы спрашиваете меня. Это поможет вам лучше понять, почему недостающая часть настолько сложна, что улучшает ваши оценки. И я бы не советовал вкладывать в недели работы, основанные на умозрительном и произвольном разделении обязанностей.
JDV-Ян де Ваан

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

14

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

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

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


1
Кажется, это предполагается в этом посте, но я хотел бы добавить, что очень важно, чтобы вы писали свой код таким образом, чтобы его было легко перефакторировать.
c_maker

@c_maker Да, конечно. В противном случае нет смысла переписывать все позже с нуля. Я добавлю это к ответу. спасибо
BЈовић

10

Как насчет того, чтобы спросить другого человека? Например, вы могли бы описать вашу проблему здесь или, если это больше проблема реализации, на stackoverflow.com, и попросить идеи. Иногда это уже поможет вам, если вы начнете записывать проблему, даже если вы не получите хороших ответов.


Если проблема связана
Роб Черч

если вы спросите SO, то ответы будут защищены авторским правом Creative Commons, и в зависимости от проекта этот код может оказаться непригодным для использования.
smcg

2
Советы могут быть защищены авторским правом? Конечно, автор будет использовать его как учебник, а не копировать / вставить?
grizwako

@smcg: тема обсуждалась здесь: meta.stackexchange.com/questions/12527/… - Если честно, если это действительно становится проблемой, я думаю, что можно обойти это, предложив GrizzLy.
Док Браун

@DocBrown IANAL, так что я не могу точно сказать, будет ли это продолжаться, но иногда полезно быть осторожнее.
smcg

2

Несколько идей:

  • Мозговой штурм
    Запишите все свои глупые идеи (на бумаге или на доске). Вычеркните те, которые, как вы уверены, не сработают. Продолжайте писать. Включите решения потенциально связанных проблем реального мира. Например, смешивание краски, нанесение гвоздя на стену или замена масла - это реальное сравнение?
  • Обратитесь за помощью в
    Google, спросите здесь, спросите друзей-гиков и т. Д.
  • Решить родственную задачу
    Вы не можете решить на проблему, но вы можете решить гораздо проще один? Или столь же сложный, связанный? Сделай это. Затем внесите небольшие индивидуальные изменения, чтобы приблизить ваше решение к желаемому решению.
  • Просто начните писать извне в
    Независимо от того, является ли ваш интерфейс веб-службой, веб-страницей, нативной формой, камерой, клавиатурой, монитором или чем-то еще , есть интерфейс. Напишите несколько строк кода / псевдокода, чтобы интерфейс работал. Используйте магические методы, которые еще не существуют. Рекурсивно делайте то же самое для каждого несуществующего магического метода. Оптимизируй позже.

2

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


1

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

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

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


Круто, потому что я из Москвы :)
user21974

Там вы идете его знак!
Мрк Флдиг

1

Мое мнение таково: никогда не пишите код, который просто работает! Рефакторинг в будущем должен быть очень сложным.

Это действительно распространенный подход для разработчиков (и, конечно, PM или боссов). Я слышал много времени «просто заставь это работать» или «я исправлю позже» (позже, когда ??? никогда!), Но я думаю, что качество - это не то, чего ты не можешь получить в середине проекта.

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.