Как подойти к чему-то сложному?

Question

Вы знаете ту конкретную часть вашего кода, которая важна для проекта, но, вероятно, ее выполнение займет много времени?У вас когда-нибудь возникало ощущение, что вы предпочитаете работать над чем-то другим (возможно, менее важным) или вообще не писать код, а не работать над этой частью?Тот зверь, которого вы так стараетесь избегать и используете все известные вам ленивые уловки, чтобы отсрочить его неизбежное воплощение?

Возможно, я просто ленив, но мне всегда приходилось иметь дело с таким кодом.Напишите что-нибудь, что мне не хочется писать (и еще хуже, если вы делаете это ради удовольствия и не получаете денег!).Большая система, которая потребует много времени, чтобы довести ее до стадии, когда вы получите какие-либо полезные результаты или признаки ее работы.Как начать кодировать что-то подобное?Большинство людей, вероятно, предложили бы разделяй и властвуй и подобные архитектурные приемы, но дело не в том, как вы это делаете;речь идет о том, как вы начнете это делать.Какие самые первые шаги вы бы предприняли?

Answer 1

Расскажу историю случая, когда это произошло со мной.

Я хотел реализовать новый алгоритм определения типа кадра для x264, который использовал бы прямое динамическое программирование (алгоритм Витерби).Но это должно было быть сложно, запутанно, некрасиво и так далее.И мне очень не хотелось этого делать.Я пытался заложить проект в пользу Google Summer of Code, но из-за какого-то ужасного невезения один студент, который у нас был, просто отказался от своего проекта...был студентом, выбравшим этот проект.

Итак, после двух месяцев жалоб и уклонений от этого я наконец приступил к работе над алгоритмом.И вот как я это сделал.

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

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

Затем я написал простой прототип Java, который использовал произвольные поддельные значения для функции стоимости и использовался исключительно для тестирования поиска Витерби.Я закончил его и проверил с помощью исчерпывающего поиска — оно идеально совпало.Мое динамическое программирование было правильным.Это третий шаг:напишите простейшую возможную форму алгоритма в простейшей возможной среде.

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

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

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

И преимущества выходят далеко за рамки x264;Я теперь настолько хорошо понимаю Витерби, что могу теперь объяснить это другим...и эти другие могут получить от этого большую пользу.Например, один из разработчиков ffmpeg использует адаптацию моего алгоритма и кода для оптимального решения несколько иной задачи:оптимальное размещение заголовков в аудиофайлах.

Answer 2

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

ПРОСТО СДЕЛАЙ ЭТО!!!

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

Answer 3

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

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

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

Answer 4

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

Answer 5

Забавно, я наоборот.Когда я начинаю решать проблему, я сначала решаю самые большие.Суть проблемы обычно в том, что меня интересует.

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

Answer 6

Я думаю, здесь есть две проблемы.

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

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

Answer 7

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

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

ХТХ.

ваше здоровье,

Роб

Answer 8

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

Я фанат "разделяй и властвуй"-типа подойди сам.

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

Затем возьмите каждую из этих задач и разбейте ее на самые основные необходимые функции/вызовы.

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

Answer 9

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