Новость про массовые увольнения не вызывает доверия. Фактов нет, одни ничем не подтверждённые тезисы - без ссылок. Вероятно, её и удалили потому, что фейком оказалась.
VK и ВКонтакте - разные организации. Поэтому тег не правильный.
Очень занятно наблюдать в комментах отдельных многословных и эмоциональных любителей ПРАВДЫ. Прям лакмусовая бумажка.
Писать тесты – дело сложное. Граница между модульными и интеграционными тестами куда более расплывчатая, чем может казаться.
Да вообще-то нет, вполне себе чёткая.
Юнит-тест покрывает одну единицу кода - класс, например. Логика всего, что лежит за его пределами (за исключением совсем уж тривиальных вещей), эту единицу кода не волнует от слова совсем и на её внутреннюю логику не влияет. Её волнуют лишь входы/выходы этого запредельного. Соответственно, запредельное мокируется.
Интеграционный тест покрывает систему, частично или полностью. Вот там классические моки не нужны. Возможны более низкоуровневые заглушки - тестовые источники данных, контейнеры и т.п.
Не совсем так. Ветка не состоит из коммитов, она - указатель на коммит. А родственные отношения между коммитами (т.е. те самые цепочки) с ветками никак не связаны.
Тут вся соль в том, что единственность определяется контекстом применения.
При проектировании апи метода мы, например, хотим, чтобы он возвращал список мух и не стремимся в этот же набор напихать ещё и котлет. Однако, при получении мух производится множество операций разными акторами со своей ответственностью. Но при этом мы не выделяем эти операции в разные апи методы.
При создании класса получения записей мы не замешиваем в него работу с базой и сериализацию на фронт. Мы создаём два класса для этих двух задач. Однако же, мы не разделяем ответственность по записи и чтению на разные классы.
При написании функции сохранения поста на форуме мы не пишем там же обновление профиля. Однако, в ту же функцию мы можем запихнуть обработку низкоуровневых исключений.
Всё это проявления SRP, но в зависимости от контекста, они проявляются несколько по-разному. Но многие холиварщики продолжают топить за лишь одно из проявлений - у каждого разное.
Кстати, у Эванса в DDD есть прекрасный термин - ограниченный контекст. Рекурсивно применяя его на кодовую и архитектурную базу и соответствующим образом масштабируя, можно без труда увидеть применимость SRP в конкретном контексте.
Перевод не правильный. У терминов "единый" и "единственный" разное значение в словаре.
Любители похоливарить обожают понадругаться над SRP, даже не понимая, о чём писал Мартин. В CC и CA смысл SRP различен, потому как книги написаны про разные концептуальные уровни. CA - про построение архитектуры, а не про код. А CC - про код, а не про архитектуру.
Инкапсуляция в программировании является объединением данных и кода, работающего с этими данными, в большинстве случае это сводится к тому, чтобы не давать доступа к важным данным напрямую.
Не в ограничении доступа к данным суть инкапсуляции, а в том, чтобы оградить клиентский код от ненужных деталей. Объект есть чёрный ящик с заданным интерфейсом - в этом суть.
Учитывая то, что мощность - это количество заряда за единицу времени под каким-то напряжением, мощность - это как раз таки эквивалент скорости зарядки.
Ага, снова 12й - про php прям актуалочка, там же в комментах это и подсветили кстати
Забейте. Как я написал несколькими постами выше, человечек как раз и живёт в начале прошлого десятилетия, с нерелевантным опытом оттуда же. До него бессмысленно доводить знания о современном мире разработки, ибо полный сосуд более не наполнить.
Такому персонажу только и остаётся, что с пеной у рта пытаться показать, как он прошедшее десятилетие не сидел, растрачивая свои былые знания и упуская новые. Когда как, всем окружающим очевидно, что занимался он только тем, что упражнялся в словоблудии, наполнял свои внутренние резервуары помоями (чтобы было, что выплёскивать на собеседников) и пестовал своё эго в слепой вере в своё всезнание и в собственное превосходство над окружающими. :D
При чём тут личность? Я аппелирую к нерелевантному опыту.
Вы можете иметь сколь угодно большой стаж, вы даже можете иметь огромный опыт в разработке (что, на секундочку, не равно стажу). Вы можете иметь акк на гитхабе, даже со сколь-нибудь просматриваемыми репозиториями.
Но пока в гитхабе нет ни одного Вашего проекта на php современной версии и с современными же инструментами, пока Вы не подтвердили, что можете профессионально, объективно и со знанием дела рассуждать на тему php - Ваш опыт не релевантен данной тематике. И все потуги что-то доказать выглядят, мягко говоря, смехотворно.
Частенько подобные рассказы про "20 лет опыта" и "насмотрелись" идут из частных производственно-цеховых лавочек, где 1-2 балбеса годами врастают в офисные кресла, набирая говнокод за 30К/мес. Иногда это делают даже на каком-нибудь фреймворке 5-летней давности.
В отличие же от них, современные конторы, в которых об IT не только слышали, но и занимаются им, понимают что и как устроено в современной разработке. И используют современные инструменты и методики.
Поэтому оставьте свои 15 лет опыта там, где им место - в первой половине прошлого десятилетия, откуда они и есть. И не загаживайте своим нерелевантным опытом то, в чём не разбираетесь.
PHP сейчас топчик вакансий куча, hr'ы сами пишут в больших количествах, а с достаточным уровнем синьорити на 3-5К можно претендовать без особых сложностей
Артур Вартанян, дорогой, нельзя ли подводить итоги вместо "Заключения" с краткой выжимкой этих самых итогов статьи? Чисто для ленивых жоп, которым статью целиком читать влом.
P.S. Не сочтите обращение за национальный контекст, но просто как-то бросилось в глаза сочетание имени автора и название статьи.
P.P.S. Ни в коем случае не считать комментарий осуждающим/критикующим - статья не была прочитана, т.к. в условиях современной нехватки времени раздел "Выводы" - это один из немногих компонентов статьи (наравне с названием и содержанием), которые могут побудить прочесть целиком. Соответственно, претензия не к содержанию статьи, а к структуре.
Забыли упомянуть, что далеко не всегда выбирать вообще нужно. Фреймворк — штука громоздкая и часто можно обойтись чистым PHP + компонентами при необходимости.
Спасибо за дайджест, пошёл брать слона.
Ссылка на опрос явно лишняя, опрос на момент 8 января уже завершён.
Новость про массовые увольнения не вызывает доверия. Фактов нет, одни ничем не подтверждённые тезисы - без ссылок. Вероятно, её и удалили потому, что фейком оказалась.
VK и ВКонтакте - разные организации. Поэтому тег не правильный.
Очень занятно наблюдать в комментах отдельных многословных и эмоциональных любителей ПРАВДЫ. Прям лакмусовая бумажка.
Говорит про "эмоций over9000", хотя у самого целая простыня эмоциональной воды в ответ на жалкие пару предложений. Забавный поциент.
Да вообще-то нет, вполне себе чёткая.
Юнит-тест покрывает одну единицу кода - класс, например. Логика всего, что лежит за его пределами (за исключением совсем уж тривиальных вещей), эту единицу кода не волнует от слова совсем и на её внутреннюю логику не влияет. Её волнуют лишь входы/выходы этого запредельного. Соответственно, запредельное мокируется.
Интеграционный тест покрывает систему, частично или полностью. Вот там классические моки не нужны. Возможны более низкоуровневые заглушки - тестовые источники данных, контейнеры и т.п.
Либо в голове не пароль, а алгоритм его генерации.
Не совсем так. Ветка не состоит из коммитов, она - указатель на коммит. А родственные отношения между коммитами (т.е. те самые цепочки) с ветками никак не связаны.
Тут вся соль в том, что единственность определяется контекстом применения.
При проектировании апи метода мы, например, хотим, чтобы он возвращал список мух и не стремимся в этот же набор напихать ещё и котлет. Однако, при получении мух производится множество операций разными акторами со своей ответственностью. Но при этом мы не выделяем эти операции в разные апи методы.
При создании класса получения записей мы не замешиваем в него работу с базой и сериализацию на фронт. Мы создаём два класса для этих двух задач. Однако же, мы не разделяем ответственность по записи и чтению на разные классы.
При написании функции сохранения поста на форуме мы не пишем там же обновление профиля. Однако, в ту же функцию мы можем запихнуть обработку низкоуровневых исключений.
Всё это проявления SRP, но в зависимости от контекста, они проявляются несколько по-разному. Но многие холиварщики продолжают топить за лишь одно из проявлений - у каждого разное.
Кстати, у Эванса в DDD есть прекрасный термин - ограниченный контекст. Рекурсивно применяя его на кодовую и архитектурную базу и соответствующим образом масштабируя, можно без труда увидеть применимость SRP в конкретном контексте.
Перевод не правильный. У терминов "единый" и "единственный" разное значение в словаре.
Любители похоливарить обожают понадругаться над SRP, даже не понимая, о чём писал Мартин. В CC и CA смысл SRP различен, потому как книги написаны про разные концептуальные уровни. CA - про построение архитектуры, а не про код. А CC - про код, а не про архитектуру.
Специально для Вас придумали DDD - там как раз во главе угла стоит бизнес-логика и то, как её видит и что от неё хочет эксперт.
Верное - это то, которое выражает суть и полноту механизма. Если не выражает, то оно не верное, а вредное.
Не в ограничении доступа к данным суть инкапсуляции, а в том, чтобы оградить клиентский код от ненужных деталей. Объект есть чёрный ящик с заданным интерфейсом - в этом суть.
Любой программист будет на публике хвалить свой продукт. Уверен, в кулуарах они сами плюются с того, как задолбало это легаси решение. :)
Учитывая то, что мощность - это количество заряда за единицу времени под каким-то напряжением, мощность - это как раз таки эквивалент скорости зарядки.
Забейте. Как я написал несколькими постами выше, человечек как раз и живёт в начале прошлого десятилетия, с нерелевантным опытом оттуда же. До него бессмысленно доводить знания о современном мире разработки, ибо полный сосуд более не наполнить.
Такому персонажу только и остаётся, что с пеной у рта пытаться показать, как он прошедшее десятилетие не сидел, растрачивая свои былые знания и упуская новые. Когда как, всем окружающим очевидно, что занимался он только тем, что упражнялся в словоблудии, наполнял свои внутренние резервуары помоями (чтобы было, что выплёскивать на собеседников) и пестовал своё эго в слепой вере в своё всезнание и в собственное превосходство над окружающими. :D
При чём тут личность? Я аппелирую к нерелевантному опыту.
Вы можете иметь сколь угодно большой стаж, вы даже можете иметь огромный опыт в разработке (что, на секундочку, не равно стажу). Вы можете иметь акк на гитхабе, даже со сколь-нибудь просматриваемыми репозиториями.
Но пока в гитхабе нет ни одного Вашего проекта на php современной версии и с современными же инструментами, пока Вы не подтвердили, что можете профессионально, объективно и со знанием дела рассуждать на тему php - Ваш опыт не релевантен данной тематике. И все потуги что-то доказать выглядят, мягко говоря, смехотворно.
Частенько подобные рассказы про "20 лет опыта" и "насмотрелись" идут из частных производственно-цеховых лавочек, где 1-2 балбеса годами врастают в офисные кресла, набирая говнокод за 30К/мес. Иногда это делают даже на каком-нибудь фреймворке 5-летней давности.
В отличие же от них, современные конторы, в которых об IT не только слышали, но и занимаются им, понимают что и как устроено в современной разработке. И используют современные инструменты и методики.
Поэтому оставьте свои 15 лет опыта там, где им место - в первой половине прошлого десятилетия, откуда они и есть. И не загаживайте своим нерелевантным опытом то, в чём не разбираетесь.
Успехов!
Исповедь неудачника.
PHP сейчас топчик вакансий куча, hr'ы сами пишут в больших количествах, а с достаточным уровнем синьорити на 3-5К можно претендовать без особых сложностей
Артур Вартанян, дорогой, нельзя ли подводить итоги вместо "Заключения" с краткой выжимкой этих самых итогов статьи? Чисто для ленивых жоп, которым статью целиком читать влом.
P.S. Не сочтите обращение за национальный контекст, но просто как-то бросилось в глаза сочетание имени автора и название статьи.
P.P.S. Ни в коем случае не считать комментарий осуждающим/критикующим - статья не была прочитана, т.к. в условиях современной нехватки времени раздел "Выводы" - это один из немногих компонентов статьи (наравне с названием и содержанием), которые могут побудить прочесть целиком. Соответственно, претензия не к содержанию статьи, а к структуре.
Забыли упомянуть, что далеко не всегда выбирать вообще нужно. Фреймворк — штука громоздкая и часто можно обойтись чистым PHP + компонентами при необходимости.