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

    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
    Ответ написан
  • Что почитать по архитектуре или правильном программировании?

    Jeer
    @Jeer
    уверенный пользователь
    О, я так и думал, что будет много советов читать книги по архитектуре. С ними такая подстава, на уровне джуна ты не будешь понимать, о чём вообще говорится в этих книгах. Или будешь понимать, и такой, даа, автор жжёт, правильные вещи говорит, а вот что делать с этим дальше - не в курсе, так как практики нет. А вот когда дорастёшь до какого-нибудь ведущего, тогда будешь перечитывать еще раз с мыслью "аа, так вот что он имел в виду". И вот именно из-за этого, многие на начальном этапе не осиливают такие книги, поэтому, если есть лишнее время, можно почитать.
    Что нужно делать: идёшь в энтерпрайз. Да или просто в компанию, которая пилит 1-4 продукта с разными командами. В команде должно быть по нескольку человек. И постоянно достаёшь более опытных разрабов с вопросами почему сделано именно так. Плюс должно быть код ревью, чтобы более опытные тебе постоянно указывали на твои ошибки, что вот так делать не надо.
    Через год меняешь контору, но чтоб тоже сложные проекты были и были команды, и так же достаёшь вопросами почему сделано так, а не иначе.
    Тогда и придёт понимание как делать удобнее и правильнее. Вот тогда и можешь почитать книги по архитектуре, чтобы еще больше пришло познание.
    Избегай контор, в которых будешь работать один или двое, это болото, которое не даст тебе такого мощного проф развития.
    Касательно написания более понятного и чистого кода, этот вопрос не относится к архитектуре. Это всё тоже придёт с практикой и с код ревью. Как вариант, чтобы усилить, можно посмотреть паттерны, вот есть крутой сайтец с приятными картинками, лёгкое чтиво (естественно, достаточно того, что в открытом доступе):
    https://refactoring.guru/
    Ответ написан
  • Tomcat и Java на флешке, возможно ли?

    sergey-gornostaev
    @sergey-gornostaev Куратор тега Java
    Седой и строгий
    Да никаких проблем:
    1. Скачиваете архив JDK
    2. Распаковывайте его на флешку
    3. Скачиваете архив Tomcat
    4. Распаковывайте его на флешку
    5. Скачиваете архив Eclipse
    6. Распаковывайте его на флешку

    Остаётся создать в корне флешки батник, устанавливающий переменные окружения
    @echo off
    
    set "JAVA_HOME=%CD%\jdk-10.0.1"
    set "PATH=%JAVA_HOME%\bin;%PATH%"
    Ответ написан
  • Стоит ли выкладывать свои мини-проекты на гитхаб?

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

    XFly
    @XFly
    Человек
    Если упрощенно - спринт нужен для поддержания ритма работы.

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

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

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

    И не забывайте, что спринт завершается двумя важными событиями:

    1. Ревью (или demo-day), когда команда демонстрирует продакт-оунеру выполненные задачи и реализованный функционал продукта
    2. Ретроспектива, на которой каждый член команды высказывается по трем пунктам:
    - Что мы делали хорошо
    - Что стоит улучшить/усилить
    - Что стоит не делать
    Ретроспектива очень важна для оптимизации работы всей команды и получения обратной связи друг от друга. И после нее команда создает одну или более задач по оптимизации своей работы, которые тоже попадают на общую канбан-доску и реализуются на следующем спринте.

    Без этих скрам-событий итерация (т.е. спринт), на мой взгляд, не имеет смысла. И тогда ваш коллега, конечно же будет прав - будет двигать карточки на канбан-доске и говорить "что-то не работают эти ваши скрамы" © =)
    Ответ написан
  • Развеете мои стереотипы по ubuntu, linux mint?

    GavriKos
    @GavriKos
    г-цо типа Виндовоза

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

    @Codebaker
    Всё умею, всё могу!
    Вам стоит почитать про задачи, которые решает теория расписаний.
    Ответ написан
  • А почему все блоки питания с разным значение вольт не делают с максимальным значением ампер?

    Jump
    @Jump
    Системный администратор со стажем.
    А почему все блоки питания с разным значение вольт не делают с максимальным значением ампер?
    Потому что -
    1)Дорого.
    2)Тяжело.
    Кому нужен блок питания стоимостью четверть миллиона рублей, и весом в сотню килограмм?

    В чем именно различия блоков одних вольт, но разных амперов?
    Разница как ни странно в токе который они могут выдерживать.
    А чтобы выдержать ток 100A нужны медные провода в палец толщиной. А кроме того в блоке питания кроме трансформатора есть еще и полупроводники - посмотрите сколько стоят тиристоры, диоды, и прочая обвязка способная выдерживать такие токи.
    Ответ написан
  • Существует ли формула вычисления количества скачков на графике?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    1. Выравниваем график через скользящее среднее: тут
    2. Находим все экстремумы функции (точки "перелома"/смены направления): тут
    Ответ написан
  • Как лучше всего выполнить задание на должность Junior QA?

    @azShoo
    1) Почитать про теорию тестирования. Вам нужно понять, как происходит процесс тестирования, какая у него цель и пр.
    2) Прочитать про основные практики тест-дизайна: Вы должны примерно представлять, какие проверки нужны и в каких случаях.
    3) Применить полученные знания в выданному вам продукту и составить условный набор тест-кейсов.

    Я бы ожидал от джуниора, что он понимает:
    а) Какие проверки необходимо провести для оценки общей работоспособности игры, и что стоит проверять после того, как общая работоспособность проверена.
    б) Понимает, какими способами можно свести к минимуму эти самые проверки (применение тест-дизайна на практике).
    в) Понимает, что такое приоритеты в тестировании - какие проверки стоит проводить раньше, какие позже.
    Ответ написан
  • Болезнь творца или как создать свой виртуальный мир?

    @xCyber
    История одного искусственного виртуального мира: https://geektimes.ru/post/90571/
    Реализовать можно на javascript и canvas
    5a58717ee25db142273485.png
    Ответ написан
  • Болезнь творца или как создать свой виртуальный мир?

    sim3x
    @sim3x
    будет жить своей жизнью, независимо от меня
    ага и кофе сам варить будет. Так не бывает. Потребуется балансировка и множество прогонов симуляции, чтоб понять как сделать стабильное окружение, которое будет интресно изменять пользователю

    3D графику позволить себе не могу
    поищите начинающих художников

    в виде обычных графиков и цифр
    их еще сложнее придумать

    Город будет иметь небольшие окрестности, в которых необходимо реализовать рост растительности и активность некой фауны.
    и как она буде симулироваться? Есть уже соотношения, сколько нужно вырастить деревьев и живности за один тик?

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

    Начать вам стоит с создания своей версии игры Life
    Там поймете в чем суть и проблематика вашей затеи
    Сразу определитесь, как будут взаимоействовать между собой игроки и будут ли
    Несколько серверов не понадобится - для обсчета симуляции много ресурсов не требуется (если не написать фигни вместо кода)

    Фреймворк в данной задаче не сильно поможет, если только не сумеете спроектировать все так, чтоб валидации и сохранение через него проходили
    Ответ написан
  • Насколько полезен опыт работы тестером в программировании 3д или игр?

    saboteur_kiev
    @saboteur_kiev Куратор тега Разработка игр
    software engineer
    В любом случае это не стояние на месте, но насколько полезно - зависит от нюансов.

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

    Если это автоматизация тестирования - то даже весьма полезный опыт, скриптинг на LUA тот же. А если это просто тыкание мышкой и заполнение дефектов - то тратить на это время жалко.

    В общем зависит от.
    Ответ написан
  • Почему персонаж так быстро двигается?

    Просто возьми и используй PointJS.
    Зачем ты сам возишься со всеми этими мелочами?

    Если системно - у тебя изначально подход не правильный. Цикл игры должен крутится непрерывно, а не запускать по нажатию. По нажатию должны только меняться векторы объекта, а в цикле игры ты должен измерять задержку между кадрами и пересчитывать смещение по вектору в зависимости от этой задержки.
    Ответ написан
  • Как распознавать абзацы в тексте?

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

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

    А дальше вы просто ставите абзац после тех предложений с высокой вероятность "хвоста", за которым идёт предложение с высокой вероятностью "головы".
    Ответ написан