Александр Зубарев

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

P.S. К тому же, если использовать jade \ slim при разработке, второй способ может стать серьезным препятствием.

Я всегда делаю полную верстку сначала, с адаптивностью (если требуется).
При этом сразу применяю какие-то вещи, с которыми будет удобно работать в дальнейшем при интеграции (если знаю, на какую систему надо интегрировать).
Потом, в ходе интеграции уже не отвлекаюсь на стили, а занимаюсь только backend / front JS.

Бегло посмотрел код и что бросилось в глаза - это названия методов, пишите в стиле camelCase, а не almost_Camel_Case

insertCSS (можно и Css как вам удобнее)
appendContent
etc.

Меня особенно волнует правильно ли я наполняю переменные для return-на - лучше минимизировать return , чтоб он возвращал какой-нибудь примитивный тип(boolean, array, int etc.), но не HTML текст(прочтите про MVC).

И зачем префиксы my*? без не лучше?
set_h1- это не айс, а что если потом захотите h1 поменять на div#title? абстрагируйтесь, пишите setTitle или как-то по другому.

В остальном - учитесь и практикуйтесь, смотрите код на github и сравнивайте, а то ваш вопрос какой-то некорректный что ли

нет, вы не правильно поняли MVC.

Попробуйте подойти к проблеме чуть с другой стороны. Реализуйте ваше приложение так, что бы оно ничегошеньки не знало о HTTP, внутри него небыло ни единого echo, оно ничего не знало о сессиях и вообще ничего не знал о таких вещах. Проще всего этого добиться - ваше приложение можно запускать через CLI. Грубо говоря как-то так:

<?php
// run.php - просто скрипт для разового теста

require __DIR__ . '/vendor/autoload.php'; // вы же уже используете composer?

$app = new App();
$app->getService('login_handler')->login('user@example.com', 'password');

Что-то типа такого. То есть на каждый "юз кейс", то есть то что приложение должно делать, у вас должен быть метод. Типа "сделай то-то" и "сделай еще что-то".

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

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

То есть что бы сказать "я сделал MVC" у вас приложение не должно зависить от UI. Если вы хоть где-то в приложении используете суперглобальные массивы, и т.д. вы проиграли. Ну либо просто не называйте это MVC, скажите что вы просто шаблоны отдельно ложите ну и роутер еще есть. Но это не MVC, это smartui, то есть наше приложение вкурсе что у него есть UI и они сильно связаны.

MVC нужно далеко не всем, и smartui сойдет для простых проектов. Но вы должны понимать разницу, и знать когда стоит загоняться а когда можно логику в контроллеры выносить.

Надо ли было создавать глобальные переменные в модели

Это вы еще не уяснили значит что такое ООП, почему глобальное состояние плохо и что такое побочные эффекты (погуглите в контексте состояния).

делать сеттеры и геттеры?

А этим мы нарушаем инкапсуляцию. Внешний мир должен знать только что можно делать с моделью, но никак не ее структуру. То есть вместо setSomething у вас должно быть осмысленное название, типа updateSomething, changeSomething и т.д. Типа "user should be able to change password" и у вас появляется метод "changePassword". Или "User should be able to update profile details" и у вас появляется один единственный метод "updateProfileDetails()". А что оно как состояние меняет - это консерн исключительно объекта. Ему рашеть менять чего или нет. Мы таким образом изолируем побочные эффекты и уменьшаем вероятность багов. Ну и нам не нужно валидировать при таком раскладе ничего так как нет промежуточного невалидного состояния.

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

более легкий и эффективный способ обучения

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

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

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

Если вы задаетесь такими вопросами, значит у вас уже есть потенциал.

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

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

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

Чтобы перестать делать лучше то, что ещё не сделано до конца, нужно понять одну простую истину: Запущенный проект лучше, чем не запущенный.

Давайте потренируемся:

• Что лучше: запущенный проект с несжатыми стилями или незапущенный со сжатыми?
  
• Что лучше: не запущенный проект с десятью страницами или запущенный с тремя?
  
• Что лучше: запущенный проект c jQuery или не запущенный без jQuery?
  

Надеюсь, вы смогли выбрать! Как узнать, что пора запустить проект? (Под запуском я имею в виду «показать людям». Например, если вы решили написать библиотеку, давайте считать «проект запущенным», если вы выложили её на гитхаб) Нужно прикинуть, сколько времени вам надо на разработку и умножить на два. Если получилось больше двух недель, то стоит разбить проект на части и прикинуть так про каждую часть. Соответственно, ставите дедлайны.

Промежуточные дедлайны помогают успеть к последнему. Старайтесь сначала реализовать основную функциональность, а потом дополнительную. Если не успеете к дедлайну доделать дополнительное — сначала запустите основное, а потом видно будет, надо ли вообще доделывать дополнительное.

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

Удачи!

fideloper/fideloper.com
jasonlewis/website
Блоги на Laravel.

yhbyun/laravel-bookmark
Менеджер закладок на Laravel.

DotPlant 2
CMS для интернет-магазинов на Yii 2 (примеры сайтов).

Piwik
Система аналитики, альтернатива Google Analytics.

Magento 2
CMS для интернет-магазинов на Zend Framework 2 (примеры сайтов).

И ещё кучу популярных сайтов с открытым исходным кодом можно найти на GitHub:
https://github.com/search?l=PHP&o=desc&q=website&r...
(laravel-tricks.com, packagist.org, elementary.io, joind.in...)

Поставьте себя на место заказчика:
1. CMS с богатым опытом (уже более 10 лет на рынке)
2. Имеет самую большую в России долю по eccommerce
3. Имеет бесплатную качественную поддержку
4. Имеет широкую документацию
5. Во всех регионах от малых до самых топовых студий можно найти специалистов без труда.
6. Обратная совместимость. Полная и безоговорочная. Вы всегда получите доступ к новым фичам и вам не придется доплачивать дохрена программистам чтобы перейти на новую версию движка т.к. старый уже не поддерживают и он кишмя кишит дырами.
7. Уже готова большая часть функционала которая вам нужна, и оттестирована годами. Только шаблон по сути натяни + немного кастомизируй логику под свои БП.
8. Есть штатная интеграция с 1с, у нас весь бизнес в России почти на ней.

Ключевое: "бизнес не любит риски", и потому в большинстве случаев bitrix самая удобная и выгодная система для заказчика как минимум в России.

За 6 летний опыт работы в направлении веб-студий, столько компаний повидал которые писались на каких нибудь:
а) Самописных движках
б) Бесплатных движках к которым прибили гвоздями функционал который в них не заложен
в) Или вовсе на питоне/руби
... которых не хотели брать ни одна из топ 10-20 региональных студий (РнД) на поддержку, и они потом переписывали заново проекты... на bitrix.

Bitrix это стандарт отрасли по ecommerce в России. Сейчас глобальный тренд на рынке - работы по поддержке и развитию проектов становится все больше чем работы по созданию новых.

И когда вы пишите на bitrix framework, у вас будет всегда много работы, т.к. bitrix не только популярен, но становится все популярнее, следите за вектором. Сейчас он входит в топ 8 CMS в мире, за последние годы прибавил 5 позиций и продолжает увеличивать свою долю.

А на счет качества... Мне порой приходит на ум ассоциация с PHP. PHP издавна отвоевала огромную долю рынка, но потом у нее появился некоторый период застоя. А тут сбоку питоны, руби. И все ругали PHP, говорили что у него не самая лучшая поддержка ООП (немного улучшившаяся с первыми 5х релизами), но в сети были модны статьи в духе PHP не круто, "PHP все", сейчас его долю на рынке веба по откусывают.
Но вот нифига, за счет большого сообщества и богатой инерции просто PHP стал улучшаться, преодолели кризис PHP6 и разногласий, и вуаля, уже php7 который уже "более-менее", и php пошел в гору.

Так и с битрикс думаю. Скорее он уже до-перепишет свое ядро на человеческий код, чем его сместят с рынка.
Работы по новому ядру активно ведутся, и оно уже 4 год живет параллельно со старым. От релиза к релизу переписывается все большая часть модулей, компонентов, структуры базы, что немаловажно с поддержкой миграции кода и данных.

Ну и что немаловажно это те люди которые пишут этот код. Если вы в топовой веб-студии с хорошими архитекторами и ведущими программистами - код на bitrix Framework будет написан качественно, и грамотно на новом ядре в традициях ООП, использования паттернов, грамотно собраны в модули и компоненты. Если же вы фрилансер или в мелкой студии, скорей всего ваши проекты будут "дурно" пахнуть, вся логика будет в шаблонах, или вообще в 1 шаблоне который будет напрочь состоять из сплошного роутинга.

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

Из правил:

1. Дизайн не должен мешать пользователю. Чем меньше шума, тем лучше. В идеале - ничего лишнего на экране. И как можно меньше анимации.
   
2. Функциональность превыше эффектов - сначала содержимое, только потом украшения
   
3. Мыслить от абстрактного к конкретному, мыслить модульно - чистый холст делим на части (в пропорциях), потом добавляем компоненты в виде сплошных фигур, потом детализируем компоненты. Так мыслит и верстальщик, и программист. Хранить компоненты в отдельных файлах.
   
4. Красивый дизайн - логичный дизайн. Все должно быть упорядоченно, иметь обоснованные размеры, отступы, цвета и эффекты
   
5. Постоянство - одна цветовая схема, пропорции, типографика, элементы
   
6. Стандарты и традиции. Поведение предсказуемо. Стрелка вниз на панели означает, что панель развернется вниз, а не вверх. Красный - опасное действие, зеленый - безопасное. Используйте стандартные иконки, вместо никому не знакомых.
   
7. Смотрите на дизайн чужими глазами - наложите черно-белый фильтр или размытие и убедитесь, что содержимое не растворилось, акценты на месте. Продумайте, что случится с колонкой или меню, если текста будет слишком много или мало.
   
8. Растровая графика для фотографий и многоцветных изображений. Все что может быть описано в векторе - делается в векторе.
   
9. На каждое правило бывают исключения
   

Книги и материлаы

1. Design for Hackers: Reverse Engineering Beauty - технический взгляд на элементы дизайна
   
2. Прочие книги по UX и web-design в списках бестселлеров amazon / ozon
   
3. behance и dribbble - для анализа лучших практик
   
4. Руководства по стилям: Google Material Design, Modern UI, Apple Human Interface Guidelines, ibm design. Тоже для анализа практик и правил для конкретной платформы.