Как приблизиться к чему-то сложному?
Переключатель просто переносится на следующую строку, основываясь на ширине .navbar-brand, и это ожидаемое поведение для его выравнивания по левому краю. Если вы хотите, чтобы переключатель всегда был выровнен по правому краю, добавление класса ml-auto будет работать.
См. https://getbootstrap.com/docs/4.2/utilities/flex/#auto-margins
.
9 ответов
Я расскажу историю случая, в котором это произошло со мной.
Я хотел реализовать новый frametype алгоритм выбора решения для x264, который использовал вперед динамическое программирование (алгоритм Витерби). Но это было сложным, грязным, ужасным и т.д. И я действительно не хотел делать это. Я пытался заложить от проекта на Google Summer of Code, но из своего рода ужасной неудачи, один студент, что нам взяли на поруки это просто на его проекте..., был студентом, который выбрал тот проект.
Таким образом, после двух месяцев жалобы на это и уклонения его, я наконец взялся за работу над алгоритмом. И вот то, как я сделал это.
Во-первых, я говорил с другим разработчиком, у которого, по-видимому, уже были некоторые идеи о том, как сделать это. Мы обсудили его, и он объяснил это мне, пока я полностью не понял процесс с алгоритмической точки зрения. Это - первый шаг любого такого проекта: поймите алгоритм позади него так хорошо, что можно псевдокодировать всю вещь.
Затем я говорил с другим моим коллегой. Мы подошли к электронной доске, и я изобразил схематически ее, пока он не понял это также. Путем объяснения этого кому-то еще я получил понимание меня. Это - второй шаг: объясните алгоритм кому-то еще так хорошо, что они могут псевдокодировать его. Это - эмуляция процесса программирования, так как программирование является формой "объяснения" алгоритма к компьютеру.
Затем я записал простой прототип Java, который использовал произвольные поддельные значения для функции стоимости и только использовался для тестирования поиска Viterbi. Я закончил его и проверил его по исчерпывающему поиску - это соответствовало отлично. Мое динамическое программирование было корректно. Это - третий шаг: запишите самую простую форму алгоритма в самой простой среде.
Затем я портировал его к C, родному языку x264. Это работало снова. Это - четвертый шаг: порт, что простая форма алгоритма к полной среде.
Затем наконец, я заменил поддельную функцию стоимости реальной. После некоторого bughunting и фиксации, это работало. Это - заключительный шаг: интегрируйте алгоритм полностью со средой.
Этот процесс занял едва неделю, но с точки зрения меня в начале проекта, это было абсолютно пугающим, и я не мог заставиться даже начинать - все же путем разламывания его на такой пошаговый процесс, я смог к не, только сделали его, но и получают сделанный намного быстрее, чем я ожидал.
И преимущества пошли далеко вне x264; я теперь понимаю Viterbi так полностью, что я теперь могу объяснить это другим..., и те другие могут извлечь выгоду значительно из него. Например, один из ffmpeg разработчиков использует адаптацию моего алгоритма и кода для оптимального решения несколько другой проблемы: оптимальное размещение заголовка в звуковых файлах.
Разделите и завоюйте, примерно не структурирует код, он также работает подходом для создания проекта концептуально управляемым. Если мне нелегко начинать на проекте он почти всегда, потому что это к большому и страшному. Путем деления на концептуально управляемые части это становится менее страшным.
Я также верю в "трассирующие пули", как описано прагматически настроенными программистами. Уменьшите проект до абсолютно самого простого "подтверждения концепции" базовых частей, например, без UI, особых случаев, обработка ошибок и так далее. Возможно, его всего несколько базовых стандартных программ со связанными модульными тестами. С этим Вы завоевали страшные части и можете создать из ядра.
В основном прием к началу работы (для меня, по крайней мере): не запускайте на целом проекте. Запустите на одном маленьком (предпочтительно ядро) часть и сборку оттуда. Если мне все еще нелегко начинать, Это - потому что небольшая часть, которую я выбрал, все еще к большому, таким образом, я должен разделить и уменьшить его далее.
Обычно я люблю большую, сложную часть. Они - части, которые на самом деле расширяют проблему и вынуждают меня тщательно рассмотреть то, что я делаю. Именно все маленькие, утомительные биты мне не нравится. Однако когда дело доходит до выполнения чего-либо, что я откладывал, я нахожу один простой совет важным:
ПРОСТО СДЕЛАЙТЕ ЭТО!!!
Серьезно, после того как это запустилось, намного легче закончиться. Я всегда нахожу, что отложил вещи, пока я не запускаю их, затем внезапно я нахожу, что, теперь, когда я запустил, это не настолько плохо, как я вообразил, и взгляд, это уже почти сделано!
Я соглашаюсь с Вами, что много больших, важных частей программного обеспечения не являются забавой записать. Я обычно запускаю свой день разработки с некоторых меньших вещей, как добавление опции здесь или исправление ошибки там. Когда время, я запускаю со значительной части, но когда я просто не вижу вещь больше, я делаю что-то другое. Это - весь штраф, если Вы все еще сделали все вовремя. И помните, что это может сделать вещи легче, если Вы говорите с другими людьми о том большом звере перед выполнением его в то время как Вы делаете и после того, как Вы сделаны. Это не только освободит Ваш ум, но Вы также получите мнение других людей с менее субъективной точки зрения. Планирование таких вещей вместе также помогает.
Забавный, я наоборот. Когда я начинаю заниматься проблемой, я иду для больших сначала. Ядро проблемы обычно, что интересует меня.
Если я делаю проект для меня, я обычно не мог бы беспокоиться для реализации всех нечетких битов вокруг краев, таким образом, они никогда не делаются. Если я делаю что-то для реального, я в конечном счете добираюсь до всех нечетких битов, но это не моя любимая часть.
Я думаю, что здесь существует две проблемы.
Сначала на самом деле начинает. Как Вы говорите, который может быть довольно хитрым. Лично я только запускаю на любом бите, только для получения чего-то на бумаге/экране. Это, вероятно, будет неправильно и нуждаться в редактировании, но в целом легче подвергнуть критике, чем создают, даже на Вашей собственной работе.
Затем существует фактический процесс решения тяжелых проблем. Там замечательная книга назвала "Концептуальное Разрушение", которое обсуждает различные способы приблизиться к проблемам. Я узнал много о том, как я приближаюсь к решению задач и моим мертвым зонам с помощью той книги.Очень рекомендуем.
Я пытаюсь установить метафору для того, что система пытается сделать. Я всегда чувствую себя более комфортно, когда я могу описать поведение с точки зрения метафоры.
Я затем приближаюсь к нему с точки зрения разработки через тестирование, т.е. начинаю описывать то, что система должна сделать путем установки тестов, которые проверят корректное поведение.
HTH.
удачи,
Ограбить
Самая трудная часть проекта идет от делания ничто к первой строке. Просто подавление чего-либо на бумаге запустило этот процесс, и удивительно, как быстро остальные могут течь отсюда.
Я - поклонник, "делят и завоевывают" - тип приближается ко мне.
Когда существует конкретная большая задача в системе, нависающей надо мной, я оставляю компьютер, беру перо и бумагу, и выламываю задачу в весь, его - логические компоненты и рабочий процесс.
Затем возьмите каждую из этих задач и повредитесь вниз в наиболее основные функции / требуемые вызовы.
Я могу затем вставить тупиковые методы, что я считаю, что мне будет нужно. и конкретизируйте их один за другим. В этой точке каждая из этих "подзадач" не больше, чем меньшие задачи разработки, вращающиеся вокруг того же проекта, поэтому чувствуйте себя подобно намного менее - обременительная задача, нависающая надо мной.
Я обычно занимаюсь этим видом проблем дома с помощью пера и листка бумаги.. Я воображаю алгоритм и/или логический поток и затем тупик (на бумаге!) классы и тупики метода и когда я добираюсь перед a/the компьютером, я могу сделать это намного легче... Вероятно, это - просто я..