leks325

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов

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

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

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

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

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

Теперь справа нарисуйте несколько длинных прямоугольников снизу доверху и написшите в них: логирование, конфигурация, мониторинг производительности, обработка исключений и что-то ещё, что является общей инфраструктурой (или сквозной функциональностью) для всех слоёв вашей программы.

Получите логическую архитектуру. Разбросайте слои по серверам - получите физическую архитектуру.

А дальше - детально прорабатывайте каждый маленький квадратик. Всё.

1. Создаю каталог для проекта
   
2. Инициализирую Bower
   
3. Устанавливаю нужные пакеты, например, Twitter Bootstrap, Angular, jQuery и т.д.
   
4. Ставлю Grunt, плагины для него и т.д.
   
5. Запускаю EMACS и создаю index.html
   
6. С помощью Emmet создаю шаблон, который уже начинаю заполнять.
   
7. В каталоге src создаю папки less, js и т.д.
   
8. Попутно пишу задачи для Grunt
   
9. Если в выбранном фреймворке не хватает какого-либо класса для стилизации элемента, сначала описываю стили прямо в шаблоне, в свойстве style. Затем при необходимости выношу их оттуда в LESS в виде одного или нескольких классов.
   
10. ??????????
    
11. PROFIT!!!
    

vodkabears.github.io/vide

Написать алгоритм нечеткого поиска самому или использовать существующие.

Попробуйте составить хеши так:
Пример: Познавательное
Hash: онаепзвтль:14
[по-порядку максимально часто встречающийся символ][и т.д. из оставшихся]:[общее кол-во символов]

Ввод: познаватильное
hash: онапзвтилье:14
При несовпадении - отодвигаете влево на 1 символ на каждой итерации:
1. онаепзвтль:14 == онапзвтилье:14 - не найдено
2. онаепзвтль == онапзвтилье - не найдено
3. онаепзвтл == онапзвтиль- не найдено
....
N. она == она - НАЙДЕНО (кроме этого может быть еще что-то найдено).
Смотрим из результатов самые близкие по кол-ву символов. В примере: к 14-и.
Выводим первые N-совпадений... Например, первые 5 похожих...

Половина ответа в вопросе, но дьявол в мелочах.
Действительно, для относительно продуктивной backend-разработки практически на любом языке программирования необходимо знать несколько базовых фреймворков и тулов, которые решают большинство задач. Это скелет ~90% приложений сложнее hello world. Хотя и этот скелет меняется и развивается, пусть и не так быстро как хотелось бы, как разнообразные отростки (не консервативность, но более долгий жизненный цикл). Суммарный вес технологий и инструментов не меньше, и уж точно не менее динамично изменяющийся, чем у frontend-разработчиков.
Далее личный опыт на примере Java.
Лет 7-8 тому достаточно было знать Spring, Struts, Hibernate да Apache Commons в довесок для разработки большинства решений. Ну и J2EE-стек для задач Enterprise-уровня.
В году 2014 Spring, Hibernate все также в арсенале программиста, но появилась куча абсолютно новых вещей вроде AMPQ, Hadoop, Netty, Scala с функциональной парадигмой, мультиязычные окружения с Clojure/Groovy/JRuby; стали чаще встречаться альтернативные реализации популярных библиотек (например Guice / Guava); старые технологии вроде J2EE стали использоваться несколько реже. А одних только Key-Value хранилищ, кэшей и прочих NoSQL как грязи. Изменился даже сам подход к построению приложений – мало кто в 2005 слышал про asynchronous event-driven модели и отталкивался при проектировании от REST-стиля (собственно, там и корни frontend-девелопера как отдельной специализации). Про эволюцию систем сборок, VCS, бенчмарков и прочих "микро"-элементов можно расписывать не одну простыню.
И да простят меня frontend-товарищи за, возможно, чванливый тон, но раскурить тонкости работы async IO в зависимости от ОС-специфики вроде epoll/kqueue или учитывать CAP-теорему при построении middleware-кэша это уровнем сложности повыше, чем новый CSS-препроцессор и CoffeeScript c очередным MVC / MVVM-фреймворком. Некоторые задачи, вроде синхронизации потоков, так и вообще лежат большей частью в области математики.
Уверен, что и в frontend-разработке существуют задачи сложнее и интереснее поехавшей на пиксель верстки и обновления полей после парсинга JSON, но ИМХО backend-разработка ближе к системному программированию старой школы, в то время как frontend суть прикладное программирование с примесями дизайна.
Frontend-инструментов больше, backend-инструменты сложнее.