Crash

Я понимаю, что уже год прошёл. Впишу своё мнение.

Стек технологий для backend и frontend одинаково сложный. Много решений, много тонкостей. Как fullstack
я знаю, о чём говорю.

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

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

С другой стороны, портфолио фронтенд-разработчиков полно красивых скриншотов из готовых проектов, иногда даже ссылками на работающие проекты. Backend такой красотой похвастаться не могут - sphinx, memcache, mongo/redis, mysql/postgre, php/python/ruby - ну или ещё что-нибудь - я имею в виду, что приходится только стек технологий упоминать. А если в портфолио и будут скриншоты, то только с целью сказать позже: там, в тени красивого интерфейса, стабильно и быстро работает мой код.

а какая разницы какой там логин то ? Все равно везде фамилия и имя участвует, а логин только при регистрации.

codewars.com

1) самоорганизованность
2) невозможность быстро получить фидбек/нужную информацию от коллег
хотя и то и то лечится выстраиванием расписания skype-call ов

Мой опыт говорит о том, что возможно работать и без высшего образования, но с высшим образованием проще.

Есть стандартный путь: 11 классов, ВУЗ, работа - он не требует жесткой самодисциплины и прочих развлечений для любителей хардкора.

Если же вы сходите с этого пути, то придется прокладывать себе путь по целине.

Лично я жалею о том, что в свое время не получил высшее образование, но в том возрасте оно бы и не вошло в голову нормально.

Сейчас планирую поступать в ШАД, для этого приходится изучать математику за свой счет (ориентировочно ~35к в месяц на протяжении двух лет).
Изучить нужно матанализ, линейную алгебру, теорию вероятностей, комбинаторику, дискретную математику и курс алгоритмов. Это необходимый минимум для работы настоящим разработчиком, а не "красильщиком заборов", как метко выразился bobuk.

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

PS: Высшего образования нет, работаю в Яндексе.

Кроме гос. контор, корпораций и заграничной работы (рабочую визу не дадут без вышки) - по сути никому это не надо.

Но Яндекс и Мейл будут смотреть уже на репутацию, опыт, познания реальные, вряд ли на диплом.

Да, возраст может смутить. Первое время только шарашкины конторы будут тебе рады.
Но образование - значения не имеет.

P.S.:
Я помню, меня тоже пёрло, когда моя примитивная программа на принтер 2 слова вывела.
И очень ЧСВ поднимает когда тебе все кругом в рот глядят когда ты Винду ставишь.

Но это еще не мастер.

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

P.S.:
При прочих равных диплом всегда плюс. Хотя в реальности я его не показывал.

Laravel 5.2+

Хорошая админка на Laravel 5 - adminarchitect.com

• 1. Сделайте копию для тестовой базы (или баз) и "копайте в ней"
  
• 2. Составьте схему объектов и субъектов СУБД :
  • дерево таблиц и внешних ключей между ними
    
  • представления (view) и их построение
    
  • хранимых процедур/функций (укажите с какими таблицами работают)
    
  • триггеров (на какие таблицы и пр и каких действиях действуют)
    
  • периодических работ (job-ы и т.п.) - с какими объектами работают и что делают.
    
  • права и пользователи (кому и что доступно в БД).
    
  • внешние источники (файлы, импорт/экспорт).
    
  • и т.п.
    
  
  
• 3. Найдите монитор запросов (tracer текущих запросов к БД или хотя бы анализатор логов).
  
• 4. Настройте проект на работу с данной тестовой СУБД,
  
• 5. Начните со справочников (обычно таблицы на которые имеются внешние ссылки и имеющие обычно простую структуру по типу id и name ). Например, справочник групп товаров. Измените через интерфейс наименование, добавьте новое, удалите его. Смотрите какие запросы возникают, какие триггеры отрабатывают (возможно, но маловероятно вызываются хранимые процедуры - проанализируйте и их вызовы) - таким образом выделите в схеме СУБД таблицы справочники и назначение их полей.
  
• 6. Далее приступайте ко сложным объектом. Схема та же (но результат может быть отражен на большем количестве объектов СУБД) - выполняете основные действия (например, добавить товары в корзину и т.п.) -> ловите возникающие с ними действия к СУБД (команды, вызов процедур и т.п.) -> отслеживаете изменения СУБД -> документируете объекты и их составляющие (например, таблицы и их поля)
  
• 7. Попробуйте выполнить отчеты через интерфейс (если есть). Анализируйте команды к СУБД для их построения аналогично шагам 6-7.
  
• 8. Надеюсь к этому шагу часть вопросов по схеме СУБД снимется.
  
• 9. Очень рекомендую во время наименьшей нагрузки периодически (например, раз в сутки в полночь) делать копию боевой СУБД и разворачивать ее на тестовой для дальнейшего изучения и экспериментов.
  

P.S. При анализе используйте названия таблиц и полей на предмет повторяемости. Например, изучаете работу с клиентом и таблица имеет название User. Поищите среди всех таблиц те, которые имеют поле User и анализируйте их назначение и т.п.

В целом - создать несколько схем. Обычно работает примерно такая последовательность действий:

0. Начать с пустой глобальной схемы.

1. Внести в неё только названия таблиц. Разделить таблицы на основные бизнес-сущности, элементы агрегатов, справочники, таблицы связи и т. п. Чёткого алгоритма нет, интуитивно всё, глядя не только на схемы таблиц, но и на сами данные (если за пять лет работы в таблице 10 значений, то скорее всего это справочник), приложение, статистику СУБД и т. д.

2. Добавить в таблицы на схеме первичные и внешние ключи. Очень поможет, если есть основания полагать, что все внешние ключи реализованы средствами СУБД.

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

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

5. Детализировать по мере необходимости, если анализ делается для себя. Сразу, если для внешнего потребления.

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

Составляем список чего не понимаем
Задаем вопрос что база должна выполнять и как проект вообще должен работать.

Начинаем с пользователей дальше с сущностями както связываем, не понимаем смотрим код.
Подымаем контакты прошлых разработчиков, спрашиваем.

MySQL Workbench позволяет построить диаграмму БД из готовой схемы.