techkuz

Примеры:
https://github.com/pepelsbey
https://github.com/Samdark
https://github.com/mdo

Как заинтересовать работодателя:
1. Аватарка. Да, она должна быть. Ещё лучше, если это будет ваша фотография. Если видишь в профиле дефолтную аватарку, возникает ощущение, что GitHub у человека всего лишь для галочки.
2. Контактный email.
3. Полоска активности должна быть зеленой (см. примеры выше), но в меру — не нужно стремиться окрасить каждую клеточку, отдыхать тоже нужно. Если заходишь в профиль, а салатовые клеточки изредка были год назад или наоборот появились только две недели назад, то страница работодателя не заинтересует.
4. Ссылка на персональный сайт.
5. Наличие собственных public репозиториев. Работодатель хочет увидеть ваш код, поэтому очень желательно наличие в них свежих коммитов. Каким должен быть отличный репозиторий на GitHub — тема для отдельного вопроса, тут напишу кратко: README, понятная структура, тесты, звезды.
6. Наличие вклада в Open Source проекты. Мне доводилось встречать профили, в которых были выполнены все пункты выше, но тем не менее их владельцы были очень слабыми разработчиками. Наличие вклада в крупные проекты с открытым исходным кодом — это однозначно вин. Очень желательно, чтобы он у вас был.
7. Stars, Followers, Following. Всё это тоже было бы неплохо завести. Если у вас много фолловеров на GitHub, значит скорее всего вы из себя что-то представляете в мире Open Source, раз другим интересно следить за вами.

P.S.: Хороший профиль на github сам может выступать в роли резюме. Очень часто хедхантеры через него и выходят на тебя.

7-е место на Тостере с более чем 1500 ответами (22% решений) и в Мск джуниором)) Ну вы даете) Неужели ваши знания и опыт так мало стоят?

1. ИТ есть во всех крупных городах и найти работу реально.
2. Некоторые московские фирмы работают по принципу "менеджмент в Мск, разработка в ...", среди городов знаю НН, Екб, Новосиб, Уфа etc (извините но про Казань мало знаю в этом плане)
3. В Казани сейчас развивается ИТ, посмотрите какой там ИТ парк открыли + второй в челнах, да и иннаполис пиарят во всю, думаю не с пустого места и вроде как республиканская программа предусматривает развитие ИТ сектора.
4. Я не из Казани но мне периодически предлагали ремоут на фирмы из Казани (фирмы не помню, активно удаленку икал в прошлом году)

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

На счет образования я ни чего не могу сказать, но возможно мой опыт вам поможет))

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

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

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

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

Я 6 лет свой проект развиваю, коммерчески выхлоп никакой, но интересно же всё равно. Кроме того этот свой проект помог мне увеличить свою зарплату в 3 раза. Этот проект как портфолио говорит о том насколько я крут. Так что ради портфолио делать стоит однозначно, а вот ожидать миллионов долларов и всемирной славы не стоит.

Пользу от тестов замечаешь только тогда, когда начинаешь писать что-то сложнее hello world'ов. Особенно хорошо их видно, когда приложение разрабатывается уже несколько лет и более, чем десятком разработчиков. Изменяешь какую-то часть кода, запускаешь тестирование и видишь, что теперь другой участок кода тестирование не проходит, так как в прошлом году у разработчика, которого ты даже не встречал, протекла абстракция.

Делаете ветку master, ветку dev и отдельные ветки под отдельные фичи.
Делаете 2 сайта - один сам проект (основной) - на него выкатываете master, второй сайт тестовый - на него выкатываете ветку dev. Остальные ветки разрабатываете, сливаете с dev выкатываете на тест, если там всё нормально то dev сливаете с мастером. За ноут просто когда садитесь если мастер новый есть делаете git pull и стягиваете новую версию

Switch

public enum DamageType { Melee, Range, Magic }
public class Monster
{
    public double Health { get; private set; }
    public double MeleeDamage { get; private set; }
    public double RangeDamage { get; private set; }
    public double MagicDamage { get; private set; }
    public DamageType FavoriteDamageType { get; private set; }

    public Monster(double health, double meleeDamage, double rangeDamage, double magicDamage, DamageType favoriteDamageType)
    {
        Health = health;
        MeleeDamage = meleeDamage;
        RangeDamage = rangeDamage;
        MagicDamage = magicDamage;
        FavoriteDamageType = favoriteDamageType;
    }

    public void AttackTo(Monster monster, DamageType damageType)
    {
        switch (damageType) // используется switch
        {
            case MonsterType.Melee: monster.Health -= MeleeDamage; break;
            case MonsterType.Range: monster.Health -= RangeDamage; break;
            case MonsterType.Magic: monster.Health -= MagicDamage; break;
        }
    }

    public void AttackTo(Monster monster)
    {
        AttackTo(monster, FavoriteDamageType);
    }
}

То же самое, но со стратегией

public class Monster
{
    public double Health { get; set; }
    public double MeleeDamage { get; private set; }
    public double RangeDamage { get; private set; }
    public double MagicDamage { get; private set; }
    public IDamageStrategy FavoriteDamageStrategy { get; private set; }

    public Monster(double health, double meleeDamage, double rangeDamage, double magicDamage, IDamageStrategy favoriteDamageStrategy)
    {
        Health = health;
        MeleeDamage = meleeDamage;
        RangeDamage = rangeDamage;
        MagicDamage = magicDamage;
        FavoriteDamageStrategy = favoriteDamageStrategy;
    }

    public void AttackTo(Monster monster, IDamageStrategy damageStrategy)
    {
        damageStrategy.Attack(this, monster); // не используется switch
    }

    public void AttackTo(Monster monster)
    {
        AttackTo(monster, FavoriteDamageStrategy);
    }
}


public interface IDamageStrategy
{
    void Attack(Monster attacker, Monster defender);
}
public class MeleeDamageStrategy : IDamageStrategy 
{
    public void Attack(Monster attacker, Monster defender)
    {
        defender.Health -= attacker.MeleeDamage;
    }
}
public class RangeDamageStrategy : IDamageStrategy 
{
    public void Attack(Monster attacker, Monster defender)
    {
        defender.Health -= attacker.RangeDamage;
    }
}
public class MagicDamageStrategy : IDamageStrategy 
{
    public void Attack(Monster attacker, Monster defender)
    {
        defender.Health -= attacker.MagicDamage;
    }
}

Отличие класса Monster только в коде первого метода AttackTo. Ну и свойства FavoriteDamageType или FavoriteDamageStrategy.

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

Было такое. Проблема решилась бональным перечитыванием и конспектированием учебника, по которому я учился. Ваше состояние - следствие неполучения ожидаемого результата + осознование того, что Вас тащют. Вас не должен никто тащить.
У меня чуть ли не депрессия была когда я думал о том, что все зря. Дело в том, что наш мозг считает все бессмысленным то, от чего мало пользы, тем более, когда на это ушло куча врмени. У Вас, к тому же, наверное, просто нету мотивации и прчины это все изучать.