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

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Все зависит от того что вы будете тестить. Если вы будете писать E2E тесты то лучше взять простенький динамический язык, и не PHP, хотя конечно можно и его.

    Я бы рекомендовал вам посмотреть в сторону python или javascript (ruby тоже можно, с капибарой какой, просто python универсальнее).

    Так же немаловажно учитывать на чем написан проект который вы собираетесь покрывать тестами. Если у вас есть люди в команде которые помогут вам с программированием то это несомненнно будет плюсом.
    Ответ написан
  • С чего начать изучение написания TDD - тестов?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    нужно писать TDD тесты.

    Нет, нет такой вещи как "TDD тесты". TDD это одна из методик экстремального программирования (XP). Вам уже привели ссылку на книгу Кента Бэка на эту тему (к слову крайне рекомендую)

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

    - Красный - перед тем как написать код, мы должны написать тест который ломается (обычно в консоли сломанные тесты подсвечиваются красным). Согласно этой методологии писать код вы должны строго тогда, когда у вас есть сломанные тесты. Если сломанных тестов нет, то и код писать не нужно.
    - Зеленый - когда вы получили красные тесты, вы должны максимально быстро дописать код так. что бы тесты были зелеными. Скажем если вы написали тест который ожидает от функции, что она вернет строку "foo" то в коде у вас должно быть не больше чем сама функция и вывод строки "foo". Как только мы этого добились мы либо рефакторим, либо добавляем еще красных тестов что бы потом дописать код. Конечно настолько примитивные вещи делать по такому циклу избыточно, и у Кента Бэка описывается понятие "длины шага", то есть сколько работы мы можем делать на каждом этапе. Вы всегда должны подключать здравый смысл словом.
    - Рефакторинг - на предыдущих фазах мы не загонялись о том насколько наш код красив, насколько мы соблюдали принципы DRY и т.д. так что это фаза отчистки кода. Мы можем делать ее на каждой итерации, а можем раз в пару часов, но важно делать это как можно чаще. На этом этапе мы устраняем дублирование как в коде приложения так и в тестах. Важно отметить что хорошей мыслью будет не рефакторить одновременно и код и тесты, ибо у нас должен быть источник правды. Если мы почистили тесты и при этом они начали фэйлиться, то значит мы что-то сломали пока числити. И наоборот. А если менять и то и то между запусками тестов то не понятно кто виноват.

    Обычно TDD практикуют используя unit-тесты (что логично, ибо они выполняются достаточно быстро что бы выполнение тестов не заставляло нас заваривать чай), что подразумевает собой то, что мы тестируем один юнит (один класс или объект), а все его зависимости должны подменяться на моки (фэйковые объекты, которые нужны что бы проверить как наш объект взаимодействует с другими, об этом тоже много написано). Но никто не запрещает использовать интеграционные/функциональные тесты и при этом практиковать TDD (так например делают чуваки практикующие BDD), а Кент Бэк это дело называет ATDD.

    Собственно TDD дает нам следующие преимущества:
    - вы не тратите время на проектирование системы в микроскопических масштабах, это эволюционный подход, архитектура приложения постоянно меняется и эволюционирует вместе с требованиями. Все требования формализуются в виде тестов.
    - код всегда покрыт тестами (пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)
    - если вам становится трудно писать тесты (например много зависимостей, сложно мокать) - то это должно навести вас на мысль о не правильной архитектуре и инициировать более глубокий рефакторинг. А при наличии тестов это не так уж и страшно.
    - необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID и т.д. так как иначе мы начинаем писать тесты очень не эффективно и опять же возвращаемся к тому что с архитектурой что-то не так.

    updated

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

    Минусы TDD проистекают из плюсов. Это эволюционный подход, который хорошо работает когда мы вносим изменения в систему маленькими порциями и всегда рефакторим наш код, что бы он большую часть времени был красивым и удобным к расширению. Если же вам в руки дали легаси проект и сказали отрефакторить, то TDD тут не подходит или подходит плохо. Но опять же такая задача ставится довольно редко, чаще - добавление функционала. И в этом случае мы возвращаемся к внесению изменений маленькими порциями и эволюционному подходу. Просто на это уйдет довольно много времени, но если сравнивать с "рефакторинг + добавление функционала + регрессионное тестирование" то в зависимости от ситуации TDD может дать как профит так и нет. Все зависит от сложности системы. На простых системах в этом нет смысла.

    По поводу области применения... Тут есть несколько точек зрения. Как минимум TDD решает вопрос проектирования архитектуры, а не разработки алгоритмов. Этого мы достигаем тестами. Но опять же через юнит тестирование довольно не удобно разрабатывать определенные типы проектов: комиляторы, трансляторы, различные решения основанные на сложных алгоритмах (например алгоритмы сжатия, шифрования и т.д.), штуки завязанные на сетевом взаимодействии, например клиенты для протоколов. Для этих вещей больше подходят функциональные тесты или же их вовсе сложно покрыть тестами.
    Ответ написан
  • Какие группы или исполнители поют о программировании или о языках программирования?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Бросьте дурное, слушайте эмбиэнт, построк, прогрессив, блэк и прочие штуки.
    Ответ написан
  • Как реализовать звездную карту в расширенной реальности(Android)?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) карта взездного неба не проблема
    2) для определения что сейчас доступно вам нужно:
    - координаты пользователя
    - направления взгляда
    - время
    3) для того что бы сделать все совсем клево нужно научиться искать уровень горизонта, тогда можно будет относительно него уже все делать. То есть придется опять же работать с акселерометром и компасом.

    А про вариант с анализом звезд с камеры можно смело забыть.
    Ответ написан
  • Как правильней сделать быстрое выкатывание в продакшн?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    конфликты мерджей очень сильно тормозят

    1) Дробите задачи, делайте ветки короткоживущими
    2) Хорошая идея делать ребейз принятых веток
    3) Попробуйте адаптировать под себя git-flow, как альтернатива хорошо себя показывает feature-toggles вместо feature-branches

    Да и бд экспорт/импорт постоянно приходится делать.

    1) Миграции
    2) Старайтесь делать миграции так, что бы они не ломали предыдущие релизы. Ну мол если вам надо добавить колонку, хорошей мыслью будет в первом релизе сделать ее nullable что бы старая версия приложения еще могла работать с новой версией базы, и потом уже следующим релизом добивать этот кусок. Основная идея - желательно что бы две последние версии приложеньки могли работать с последней версией базы данных. Если у вас база нормализована нормально, то проблем с этим быть не должно.

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

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

    При таком сценарии даунтайм будет минимальным.

    вопрос с выкатыванием новых релизов

    Вот вам варианты в порядке сложности и мощности (от простого к сложному).
    - capistrano/capifony
    - ansible/puppet/chief/etc
    - docker + docker-machines + docker-compose

    Ну и да, тесты тесты тесты. Все самое критичное должно быть покрыто хотя бы интеграционными/функциональными тестами. В идеале же вся бизнес логика должна быть покрыта быстрыми юнит тестами и UI/инфраструктура функциональными (читать про пирамиду тестирования).
    Ответ написан
  • Сборник примеров по Verilog HDL?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Можете у Texas Instruments понакачать даташитов к каким-нибудь прикольными небольшими железкам (тип там, простенький UART ресивер) и реализовать их.
    Ответ написан
  • Нормализация БД. Зло или добро?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Все зависит от контекста высказывания (задачи разные бывают). Бросаться в крайности это глупо (только ситхи все возводят в абсолют (с) Оби)

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

    p.s. уточните о чем был проект или скиньте ссылку, любопытно посмотреть на безумца или понять его хотя бы.
    Ответ написан
  • Правильно ли я понял механизм авторизации?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Да, а приведенный вами код - аутентификация

    p.s. надеюсь вы используете password api для хэширования паролей а не какой-нибудь там md5.
    Ответ написан
  • Зачем использовать несколько Backend языков в одном проекте?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    в node.js есть то чего нет в PHP

    Все там есть, просто чуть дольше и меньше решений адаптированных под асинхронную работу. Тот же reactphp может использовать libuv + libev что по сути основа ноды.

    Но Python для чего, он ведь мало отличается от PHP по функционалу?

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

    Так же, если разработчик освоил какой-то еще язык хотя бы на базовом уровне, например познакомился с чудестным миром python, это будет влиять и на то как он пишет код. Скажем в python/node.js более сильно развита парадигма функционального программирования, что в PHP мало кто практикует (хотя с каждым днем все больше).
    Ответ написан
  • Какой самый быстрый язык программирования?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    скорость дается за счет:
    - грамотное построение алгоритмов
    - грамотное использование конвееризации процессора (устранение конфликтов по данным в циклах, развертка циклов вручную)
    - грамотное использование векторизации вычислений (SSE, AVX, или же опять же построение циклов таким образом, что бы небыло конфликтов по данным если вы хотите что бы компилятор вам это сам сделал).
    - использование всех доступных ресурсов (например применение GPGPU там где надо быстро посчитать много чего и не требуется высокая точность).
    Ответ написан
  • Что за должность такая, архитектор?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Когда-то, когда ватерфол разработка была в чести, были такие люди как архитекторы. Они проектировани модель предметной области на основе модели предоставляемой им бизнес аналитиками и архитектуру системы в целом, проектировани все это дело через UML и отдавали далее по конвееру девелоперам, которые по этим "чертежам" должны были уже закодить все. Обычно чуваки эти были бородаты и опытны, ибо ошибки на этой стадии могут встать бизнесу в много денег.

    Сейчас, когда Agile методологии и подходы разработки все больше захватывают умы людей, отдельная личность "архитектор" перестала быть необходимой. Все реже мелькает эта должность и скоро совсем их не останется. Теперь эти чуваки стали техлидами или просто девелоперами.
    Ответ написан
  • Переход с C# на C++?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    не закончив изучение шарпа

    Вы про синтаксис? CLR? Или про что?

    В целом большая часть знаний спокойно мигрирует туда-сюда.
    Ответ написан
  • Что такое статическое наследование в ООП?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    статическое наследование - наследование статических членов классов.
    Ответ написан
  • Как оптимальней?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Оптимальнее хранить данные в мэпе и выдавать по ключу.
    Ответ написан
  • Куда податься с ТЗ для разработки MVP (аналоги myheritage.com, geni.com, familyspace.ru)?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    денег на разработку нет

    Вы проиграли в этом месте. Если вы делаете проект просто так, идеи ради, выложите где идею на каком стартаб хабе или еще где тусуются всякие предпримчиые люди. А если же денег ради, то тогда идите в банк и получайте кридит, копите и т.д.

    Есть конечно вариант еще через инкубаторы при университетах попробовать, но шанс того что на выходе получится что-то толковое стримится к нулю. Хотя опять же, с MVP можно потом уже подаватся и искать спонсоров а там уже переписывать.
    Ответ написан