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

Question

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

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

Answer 1

Я расскажу историю о случае, когда это случилось со мной.

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

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

НТН.

ура

Rob

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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