• Попросили проверить код, на что смотреть нужно?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Смотря зачем)). Я когда делаю 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
    Ответ написан
    55 комментариев
  • SEO-специалисты, вы сами проставляете крауд или заказываете за бюджет проекта?

    vpetrov
    @vpetrov
    частный SEO-специалист, textarget.ru
    Не вижу никакого смысла в крауд-ссылках сейчас.
    Единственный расклад - лидген, но его никакой аутсорс не сделает, тут нужна реально хорошая площадка, реально прокачанная учётка и реальный продукт, чтобы продавать.
    Но точно не ссылочное.
    Ответ написан
    Комментировать
  • SEO-специалисты, вы сами проставляете крауд или заказываете за бюджет проекта?

    pro100taa
    @pro100taa
    Сам работал в нескольких агентствах. Всё зависит от агентства или фрилансера. Где-то вы сами должны проставлять, где-то на аутсорс отдают, а где-то вообще не считают краудмаркетинг чем-то важным для продвижения. Здесь всё от вашей ситуации зависит. Я сейчас отдаю человеку, который давно проставляет для меня, крауд по своей базе. некоторые ссылки сам проставляю.
    Ответ написан
    Комментировать
  • Альтернативные варианты реализации корзины в DRF?

    EtherDaler
    @EtherDaler
    Еще зеленый
    Создаете модель корзины, связываете ее с моделью пользователя. Потом создаете модель товары корзины и связываете ее с моделью корзины. Важно указать в ForeignKey полях аргумент related_name, чтобы можно было обращаться из родительской модели к дочерней.
    class Basket(models.Model):
        user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='basket')
    
    class BasketProducts(models.Model):
        basket= models.ForeignKey(Basket, on_delete=models.CASCADE, related_name='basket_products')
        products = models.ManyToManyField(Products, on_delete=models.CASCADE, related_name="basket_products")
    
    class Products(models.Model):
        name = models.CharField(max_length=255)
       '''''

    Потом сериализируете модели
    class ProductsSerializer(serializers.ModelSerializer):
        class Meta:
            model = Products
            fields = ("__all__")
    
    
    class BsketProductsSerializer(serializers.HyperlinkedModelSerializer):
        products = ProductsSerializer(many=True)
        class Meta:
            model = BasketProducts
            fields = ('basket','products')
    
    class BasketSerializer(serializers.HyperlinkedModelSerializer):
        basket_products = BsketProductsSerializer(many=True)
        class Meta:
            model = Basket
            fields = ('user' , 'basket_products ')
    
    class UserSerializer(serializers.HyperlinkedModelSerializer):
        basket = BasketSerializer(many=True)
        class Meta:
            model = User
            fields = ('id', 'phone','email' ,'basket')


    Далее во вьюхе в вашей функции API указываете permission_class как isAuthenticated, потом получаете корзину пользователя командой request.user.basket . В запросе в хедере указываете Authorization и токен.
    Ответ написан
    Комментировать
  • Как заказывать приложение на андроид?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Что просить программиста, чтобы я мог потом отдельно просить дизайнера "натянуть" дизайн не обращаясь к первому разработчику?

    Так это не работает. Сначала дизайн, потом приложение. Это не лендинг на вордпрессе.

    Что просить программиста, чтобы можно было потом другого программиста просить добавить функционал, не повторяя работу с нуля?

    Исходный код. В идеале с хорошей архитектурой.

    Сколько примерно это может стоить?

    От нуля до бесконечности.
    Ответ написан
    3 комментария
  • Какой роутер взять домой чтоб был гибкий к настройке?

    borisdenis
    @borisdenis
    Ленив и вреден...
    Удобный и гибкий - Кинетик
    Непривычный в настройке но супер гибкий - микротик
    Ответ написан
    5 комментариев
  • Какой дистрибутив выбрать для инфбеза?

    @Everything_is_bad
    Любой, который тебе больше понравится или который используют знакомые
    Ответ написан
    Комментировать
  • Заказчик сует доработки очень маленькими порциями, как брать оплату?

    sim3x
    @sim3x
    Собирать правки в блок на 15-25 минут (те просто сказать, если в письме не указано "срочно", то фиксы будут делаться после пятого-шестого письма)
    Когда просить оплату за блок: внутри большого проекта +1-2 часа, как за поддержку
    или после: как отдельный блок
    стоит оговорить с клиентом заранее

    Акцент тут на том, что задачи на 5 минут - ето вспомнить о чем проект, запустить все тесты, понять как решать, решить (вот тут 5 минут), запушить, задеплоить, написать ответ
    И в совокупности 5-минутная задача сожрет пол часа и более
    Ответ написан
    Комментировать
  • Заказчик сует доработки очень маленькими порциями, как брать оплату?

    alex-1917
    @alex-1917
    Если ответ помог, отметь решением
    В чем проблема потребовать оплату за то, что:
    1. Уже сделано.
    2. Стоимость уже сделанного была проговорена ранее.

    Мягкотелость автора вопроса зашкаливает, ппц.
    Зачем сунулся в фриланс? Если нет силы воли администрировать))) клиента, отдай это дело разбирающемуся в этом нелегком деле! Работай в офисе!

    Выше (или ниже) правильно посоветовали:
    1. Минималка час (полчаса тоже ниочем, слабохарактерная уступка)
    2. Время реагирования на задачу - минимум 12 часов.
    3. Ну и самое главное - не бойтесь ставить нормальное время на выполнение, коэффициент два-три это как минимум))) Т.е. если по факту вы тратите два часа на доработку - ставим ШЕСТЬ! и т.д. Иначе вы будете пахать без остановки, а жизнь будет проходить мимо вас....

    ППЦ! мне показалось поначалу, что вы админ и работаете на окладе, судя по тому, как вы мгновенно бросаетесь на доделки))))

    а если за 2-5 минутную правку брать как за пол часа, то может уйти и к другому специалисту.

    по 15летнему опыту - никуда он не уйдет

    судя по всему, вы человек-оркестр - это тупиковая ветвь развития!!! Делайте то, что делаете отлично, а мелочевку типа наполнить текстом или поправить заголовок - это пусть делают рукунабивающие)))) Судя по 2-5 минутные правки - это именно и есть задание по текстам)))
    Ответ написан
    8 комментариев
  • Заказчик сует доработки очень маленькими порциями, как брать оплату?

    opium
    @opium
    Просто люблю качественно работать
    Тут просто надо вложить это изначально в стоимость и не надо его отучать.
    Например у меня есть заказчик который никогда не заказывает без скидки, хоть убейся ему нужна скидка, всегда наценяю ему двадцать процентов, потом даю скидку двадцать процентов, он раз как ребенок, и понятное дело что его тут вопрос денег не сильно волнует, но убеждения какие то толкают на обязательное получение скидки
    Ответ написан
    10 комментариев
  • Заказчик сует доработки очень маленькими порциями, как брать оплату?

    mindtester
    @mindtester
    http://iczin.su/hexagram_48
    требуйте доплату маленькими порциям*

    даже если доработка реально на 5 минут.. все дело в специфике работы программиста..
    1 - у вас похоже каждый раз типа окончания
    2 - .. и вы с чистой совестью взяли другую задачу (и клиента это не касается)
    3 - в итоге - его запрос на 5минут - ломает вашу текущую ситуацию - вам надо переключаться между контекстами.. мало того - сохранить олимпийское спокойствие... и это всегда дороже чем 5 минут (даже если в этот период ни хрена не делаете на самом деле)

    ps * - ну а если все перечитать.. то даже и не маленькими.. ))

    удачи!
    Ответ написан
    Комментировать
  • Заказчик сует доработки очень маленькими порциями, как брать оплату?

    402d
    @402d
    начинал с бейсика на УКНЦ в 1988
    поставить минимальную стоимость как за полчаса работы.
    объяснять, что вы сейчас заняты и поправите через 1-23 часа.
    Брать деньги за все время от прихода первого сообщения до сдачи последней правки.
    так как вы в режиме оперативного сопровождения.
    Ответ написан
    20 комментариев
  • Настройка nginx для нескольких статич сайтов (прилоджений реакт)?

    VoidVolker
    @VoidVolker
    Dark side eye. А у нас печеньки! А у вас?
    1. Выкидываете из основного конфига /etc/nginx/conf.d все ваши настройки текущего сайта
    2. Пишите отдельно конфиг каждого сайта в файлы вида /etc/nginx/sites-available/site.domain
    3. В конфигурацию сервера добавляете домен сайта: server_name site.domain;
    4. Добавляете симлинки для каждого сайта в каталог sites-enabled: /etc/nginx/sites-available/site.domain -> /etc/nginx/sites-enabled/site.domain
    Ответ написан
    5 комментариев
  • Как сделать страничку браузера прозрачной?

    FeST1VaL
    @FeST1VaL
    Тихий
    Невозможно.
    Это как я тут недавно читал веселые задачки от клиентов... на сайте помоему студии красоты просили сделать зеркало на заднем фоне сайта, чтобы посетители себя видели в нем.

    Алло! Ваш дизайнер ещё на месте? Нужно на нашем сайте сделать фон зеркальным, чтобы пользователь заходил и видел своё отражение
    Ответ написан
    3 комментария
  • Как найти VLAN с помощью wireshark?

    @asmelnik
    Смотрим пакет типа PVST+

    6734eab267d1a641983134.png
    Итого VLAN 3140
    (это в вашем конкретном случае)
    Ответ написан
    Комментировать
  • Как фильтровать результаты поиска роликов в Youtube в браузере?

    @SVR987
    я вот так сделал,получилось.
    Ответ написан
    Комментировать
  • Как поймать, что дает высокий Load Average?

    shambler81
    @shambler81 Куратор тега Linux
    1. поставь munin с плагинами на веб сервер -там будет 99% видно где кто и когда дешево и сердито.
    2. iotop -oka тоже даст понимания особенно если это I-O проблема.
    3 Поздравляю вас ддосят, можно проверить по аксесс логу апача или по подключениям
    netstat -ntu | awk '{print $5}' | grep -vE "(Address|servers|77.37.156.60|79.137.175.245|192.168.5.201|95.163.251.234|127.0.0.1|8.8.8.8|8.8.4.4)" | cut -d: -f1 | sort | uniq -c | sort -n| sed 's/^[ \t]*//'

    смотрим если там все плохо вас ддосят, плохо это по факту если больше 5 подключений на ip или этих подключений целая куча.
    Ответ написан
    5 комментариев
  • Почему на сайтах в js коде используются непонятные однобуквенные переменные и что они значат?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Потому что для рабочей версии сайта чаще всего используют минифицированные версии файлов.
    Ответ написан
    1 комментарий
  • Когда каскадное обновление это плохо?

    @Akina
    Сетевой и системный админ, SQL-программист.
    Когда каскадное обновление это плохо?

    Каскадное обновление - в большинстве случаев это... глупо.

    Вспомним, что это вообще такое.

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

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

    Что же есть каскадное обновление? Это изменение связанного значения в подчинённой таблице, если изменяется значение основной таблицы. Ну то есть если изменяется (вспоминаем сказанное выше) значение первичного ключа или поля, объявленного уникальным. В основной таблице. Ага...

    Ну то, что изменение/корректировка значения поля первичного ключа есть bad practice (читай - дурь голимая), хорошо известно, обосновано и весьма логично. Нет, реально возможны ситуации, когда такая операция оправдана и имеет смысл - но такая ситуация абсолютно всегда одноразовая, и есть составная часть административного обслуживания. А если подобная надобность возникла на уровне пользователя, в рабочем процессе - то это гарантия наличия серьёзной ошибки в проектировании БД.

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

    Резюмирую. Если каскадное обновление необходимо, оно скорее всего маскирует недостатки и ошибки проектирования. А плохо это или хорошо - прикрывать дырку костылём,- решайте сами.
    Ответ написан
    Комментировать