Deerenaros

Во-первых, идея ничего не стоит. Как раз по этой причине.

А во-вторых: причина. Неизвестно, насколько данный сервис был бы удобен.

Причин не так много. Не смотря на кажущееся удобство есть несколько фатальных недостатков. А именно: жёсткое требование интернет подключения, необходимость в браузере для полного функционала и во многом надуманные причины удобства.

Так что для начала подумайте о чём: почему вашим сервисом стоит пользоваться. Полнотекстовый поиск? Эластиксич поднимается в несколько команд, да и банальный egrep творит чудеса. Удалённый доступ? Тьфу, это даже проще - ssh. Резервное копирование и/или агрегация? rsync.

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

Базы данных тут немного не причём.

Ну в общем-то ответов много. Могу кое-что добавить от себя.

Во-первых, голова не бесконечна во всех смыслах. Запихнуть в неё больше чем 10 объектов одновременно вряд ли получится, у многих начинаются огромные проблемы уже с 5. Лично я испытываю ДИКУЮ больше если собственный код становится больше чем большой. Для меня это где-то 15~20 сущностей, причём чем сильнее они связаны, тем сложнее они даются, так как становится сложно абстрагироваться. Что примечательно, при работе с чужим кодом таких проблем практически нет, ну у меня по крайне менее. Всё дело в том, что чужой код изначально воспринимается чёрным ящиком, поэтому если он не представляет из себя дикую лапшу, аккуратная работа с ним с минимальным вмешательством в проект получается легко.

Во-вторых, не стоит делать код пушистым. Однообразность воспринимается лучше. Массивы некоторых объектов надо называть $названием_объекта + 's'. Классы с большой буквы, любой объект стоит называть так же, как класс, но с маленькой буквы. Конечно, если семантически прям просится по другому, то стоит правило нарушить, но в общем случае никаких выдумок не надо. Временная строка - str, временное число - tmp, временный объект - obj. И пробелов не жалей, внутри файла разделяй разные структуры двумя-тремя пробелами, стоит обособлять регионы, например, "глобальные" функции наверху, по середине структуры, потом классы. В C# есть #region.

В-третьих, объём тоже воспринимать сложнее. Делай плоско. В том смысле, что меньше наследований, больше включений. Очень тяжело воспринимать архитектурную лапшу. Суть микросервисов - единственная, максимум две точки связи. То есть контроллер де должен склеивать всё и вся, это задача "простейшего" диспетчера событий, который крутится в своём цикле и распихивает поступившие сообщения. Микросервису надо думать чем меньше, тем лучше. Вообще, микросервисы не всегда хорошо подходят, они очень удобны в сверхраспределённых командах с высокой степенью самодисциплины, когда привычка смотреть в доки сильнее привычки звонить тимлидеру на каждый чих. В случае с самостоятельной разработкой они скорее зло, хотя в web поначалу довольно приятно, заливать чрезвычайно низкую производительность ресурсами, забивая каналы связи под завязку, не лучшая идея. Порой намного лучше сделать монолитно, но аккуратно, особенно когда вся жизнь продукта под ответственностью одного человека.

В-четвёртых, внутри монолита также надо делать максимально растянуто, никаких супер-синглетонов бдящие за всем и вся. Равно как и с микросервисами, внутренние объекты должны иметь минимум точек входа. Они должны быть просты и понятны. Если какой-то класс выполняет слишком много задач, часть из них надо делегировать другим классам, возможно новым. Это по сути цикломатическая сложность, о которой упомянул Ivan Sokolov, но мне не нравится эта формальность. Да и некоторые вещи сложно формализовать ребром на графе.

В-пятых, иерархия должна быть логически правильной, наивной, без выпендрёжа. Тоже самое, что и в третьем, плоское лучше объёмного.
Плохо:

Лучше:

Пример немного утрирован, но суть, навроде, ясна. Не надо наследовать всё и вся от чего угодно, если есть возможность включить внутрь - включай. Всё остальное от лукавого и только в крайних случаях.

В-шестых, используй UML, mind maps, блокнот и таск менеджеры. Эти инструменты словно манна небесная спасают дедлайны от полного уничтожения. Хотя UML спорен, им очень удобно следить за структурой проекта, представлять картину с высока, рисовать его стоит самому, учитывая неявные связи и убирая рудиментарные. Mind maps помогут собрать мысли в кучу. Блокнот банально запишит то, что постоянно забывается. Таск менеджеры сформируют привычный график, отобразят прогресс, помогут фокусироваться на текущих задачах, не растекаясь по проекту.

В-седьмых, изучи декларативное программирование. Шикарная вещь, которая позволяет сконцентрироваться на задаче, а не на решении. Из коробки в функциональных (erlang) и логических (prolog) языках, однако многие элементы существуют и в монстрах вроде C#/Java, Python, особенно JavaScript. Насчёт Go не знаю, но на первый взгляд весьма декларативный.

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

Ещё пара абзацев. Ну про вредные советы: методы надо делать ровно такими, какие они должны быть. 20 строк - это что-то вроде лакмусовой бумажки, однако это лишь один из параметров. Очень часто требуется сделать громадную функцию для работы со сложным API или подробить много разных чисел в циклах. Поэтому ориентироваться на это плохая идея. Равно как и папки-подпапки-подпапками погоняемы, максимум - два уровня в чрезвычайно сложных проектах. Иначе будет очень сложно ориентироваться. Ещё происходит странный возврат к комментариям. На мой взгляд, если это не продаваемая за большие деньги библиотека - нах*й надо. Документация в комментариях - рудимент кода, он нигде не используется, зато требует поддержки, на что приходится распылять внимание. Если нет условного рефлекса править комментарий после кода - выбрасывайте и не жалейте. Везде! Без исключений. Ещё есть много "архитектурных" паттернов. Снова вред, если вы не работаете в Google, где вашу зарплату надо оправдать умными словами. Самый эффективный способ - программировать наивно. Чем проще для вас сейчас, тем лучше для вас потом. Если думаете больше десяти минут - плохо думаете... Но об этом позже. Паттерны это некая систематизация неких знаний, причём совершенно не понимаю, зачем её вообще сделали. Да, архитектура в некотором роде нужна, но постоянно искать какой паттерн здесь надо использовать, если это не проект на 100500 лет вперёд - нельзя. Почти всегда будет дешевле в случае неуспеха отрефакторить всё и вся, чем переписывать с нуля или тратить месяцы на продумывание архитектуры... В которой также могут быть ошибки.

И последнее. Отдыхайте. Если чувствуете, что задыхайтесь - пройдитесь, подышите. Если чувствуете, что мозги плывут - отвлекитесь, подумайте о другом. 8 часов в день для программиста - это дикость, но это реальность. Для разных людей наибольшая эффективность поддерживается где-то 3~6 часов, причём некоторым требуются перерывы каждые пол часа, другому хватит обеденного перерыва, а третьему вообще нельзя сегодня никаких отвлекающих факторов, ибо "волна". На самом деле, человек существо динамичное, так что будут разные дни. Но если не получается сейчас - не бесите самого себя. Отдохните, перекусите, пробежитесь, покурите, проверьте почту, послушайте музыку, почитайте статью. Не тратьте время бездарно и, что интересно, проблемы будут решаться, усилия будут прикладываться аналогичные, но вот ощущения от работы станут совершенно другими.

Не пишите чушь! Серверные языки? WTF?!? Ду ю спик инглиш, блджад!?

Во-первых, любой, совершенно любой язык программирования может быть использован в качестве генератора html-вёрстки. Да тут и на brainfuck можно делать, да на чём угодно можно, что умеет делать вывод в stdout: пихаем на cgi и всё работает. Вопрос в юзабельности пролога на cgi остаётся открытым, но техническая возможность такая есть.

Во-вторых, сравнивать фреймворк с языком программирования общего назначения... Ну убейте меня лучше. C# vs RoR? Ну ясень зуй - C#. На нём можно хоть игры писать, хоть на GPU считать, хоть странички рендерить (не совсем корректно, но можно посчитать и небольшой погрешностью на фоне безобразия в вопросе) и всё это на кроссплатформе (visual/mono). Тогда как на RoR можно... Только странички рендерить. Нет, конечно некоторым и на потолке спать удобно, но Rails - это фреймворк для Ruby, то есть набор библиотек, предназначенных для быстрого и удобного поднятия интернет-магазинов ;) А шарп - язык общего назначения.

И наконец, смысла браться за все направления - конкретно вам - нет никакого. Более того, смысла вообще браться за программирования - конкретно вам - невелик. Покуда задаются такие вопросы... Не, бросьте эту идею. Лучше идите в колледж фрезеровщиков, а потом за станок. ЗП 50к (2015 год) стабильно, но самое главное - жуткий дефицит кадров, ибо старые токари уже давно без пальцев, а протезов из Китая ещё не завезли. Там сразу после колледжа через выходную дверь открывается магический портал на завод, едва ли не в прямом смысле слова.

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

Внесу свою небольшую лепту.

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

Во-вторых, на фриланс биржах жуткий демпинг. Так что первые два месяца скорее всего придётся поработать на зп дворника. Вооще, сейчас фриланс сообщество относительно стабильно именно из-за высокого входного порога. Первые серьёзные деньги раньше второго месяца увидеть очень сложно. Здесь придётся работать на престиж, то есть зарабатывать контакты. Очень часто бывает, что довольный клиент вернётся, а бывает даже не уходит - оставляет проект на сопровождение. Причём делать скорее всего ничего не придётся, а лишняя копейка никогда не помешает. Набрав 10-15 проектов на сопровождение можно вообще не работать и получать пару зарплат дворника.

В-третьих, время, требуемое на проект, что вы привели, это не средней руки вэб-мастера. Это начинающего вэб-мастера. К тому же вэб-мастера вымирают как вид. Идеально, когда со временем вы специализируетесь на чём-нибудь узком - разработка дизайна, вёрстка с дизайна или программирование бэк-энда, найдя других надёжных дизайнеров или даже скооперировавшись в вэб-студию. Многие "фрилансеры" есть никто иные, как клиент-менеджеры вэб-студий. То есть менеджер формирует ТЗ - пара часов (или дней) общения в скайпе, передаёт дизайнеру, который формирует дизайн - ещё пара часов (или дней), а верстальщик с программистом верстают и программируют - последние пара часов (или дней) =) По моему очевидно, что специализируясь на узком профиле можно значительно ускорить свою работу: знакомство с инструментами, доскональное знание области, проще следить за трендами... Когда знаешь, что делаешь, количество работы можно свести к минимому, к тому же постоянное использование уже готовых наработок...

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

Вам нужен немного другой подход.

Во-первых, обязательна регистрация как "центра сбыта произведений искусства". Тогда Вы получите любовь и защиту нашего любимого Михалкова.
Во-вторых, нет универсальной формулы "read than burn", как минимум потому, что в памяти человека останется отпечаток, а на печатной машинке его можно будет набрать. Именно поэтому искусство никогда не умрёт. Равно как и цифровое пиратство - нельзя не заметить, что оно идёт теми же путями, что и раньше всевозможные обходные пути цензуры.
В-третьих, можно таки попытаться защитить. Но это расходы, и большие.

А вот про защиту. Это называется стеганография. Нужно в текст добавлять ватермарки. Причём такие, чтобы их практически невозможно было обнаружить. А вот вопрос, как их делать остаётся открытым. Например, можно все 'ё' менять на 'е', если нуль и оставлять 'ё', если единица. Хоть метод и дубовый, и с очень низкой ёмкостью, таки он работает, и работает довольно не плохо. До тех пор, пока пират не попытается "нормализовать", заменив все 'ё' на 'е'. Но это один из дубовых методов. Творческий процесс остаётся за вами.

Вам нужен компактный mechanize или огромный selenium. К тому же, можно извернуться и заюзать qt с его webkit.

А в чём проблемы с локальным проектом? А вообще, git workflow и Heroku вам в помощь.

В зависимости от стека технологий, запускать сервер на локалхосте можно из cmd.exe с помощью команд, описанных в документации.