• Радикальный перфекционизм в коде
    +2

    Суть поста 'Заставь дурака богу молиться...' Конечная цель нашей работы работающее приложение удовлетворяющее требованиям заказчика. Если правила упрощают эту задачу ОК. Есть правила усложняющие задачу (например англоязычное наименование всех без исключения сущностей).

  • Что лучше выбрать в 2020 году — React или Vue?
    0
    1) для этой задачи Vue в функциях не нуждается!
    2) Приведите пример React кода где обрабатывается биндинг объекта со сложной вложенностью типа
    user.Name
    user.Document.Number
    user.Document.Type
    И очень желательно что бы функция не была заточена под конкретный объект. На самом деле мне это надо, ибо на работе принято решение использовать React.
  • Два способа сделать надежные юнит-тесты
    +5

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

  • Что лучше выбрать в 2020 году — React или Vue?
    0
    ну нафига козе баян.
    А и это вы только считываете изменение значений их еще установить надо.
    то есть начитать объект. a потом его сохранить отредактированный и свойства не простые только простыe. а и вложенные ( типа user.documetn.Num).
    При работе с React на пустом месте создается гора трудно читаемого кода.
  • Что лучше выбрать в 2020 году — React или Vue?
    +1
    Если по возможностям Vue и React приблизительно одинаковы. То следующим критериям выбора должны быть:
    1) Краткость.

    ОДНОЗНАЧНО Vue.
    Простой пример: Надо отобразить на экране форму в которой к примеру редактируемых 40 полей
    Для React это 40 функций прописанных в коде (Или замудрых выражений в шаблоне )
    Для Vue функций 0.
    Аргумент убедительный?
    И еще синтаксис функций React как бы чрезмерно избыточен. особенно если надо прописать биндинг на вложенное свойство (типа user.docment.Number.

  • Всё, что нужно для начала работы с Vue.js
    0
    Это следует читать так так?
    Реальное приложение где Vue подключается через скрипт никто не пишет
    .Не уверен в этом. Скорее правильно сказать так?
    Новое приложение с где Vue подключается через скрипт никто не пишет.
    Тут согласен. Хотя дело еще в квалификации разработчиков.
  • Всё, что нужно для начала работы с Vue.js
    0
    В документации реакта сказано, что это только в качестве песочницы. Реальное приложение так не пишут. А вот в Vue Это вполне работающий вариант.
  • Всё, что нужно для начала работы с Vue.js
    +3

    Полностью согласен
    Хорошо разложили по полочкам

  • VueJs + MVC минимум кода максимум функциональности
    –1
    К сожалению мои знания js и vue далеки от идеала я его только изучаю.
    Учитывая, что расширения штата что бы иметь отдельного программиста для фронта у нас не предвидится хочется предложить коллегам работающий и простой шаблон с которого можно начать делать для начала хоть простые формы.
    А так у вас с одной стороны «Зато всю «отрисовку» можно делать используя Vue», а с другой «При каждом изменении формы Vue отправляет на сервер все изменения». Очень странное сочетание.

    Мне не кажется странным. Vue строит выпадающие списки в том числе связанные, динамически подключает нужный CSS и прочее. А на сервер отправляет для валидации (что бы не грузить сервер можно использовать «ленивый биндинг» отправляющий поля при потере фокуса.)
    Это разные задачи, но они обе важны.
    Шаблон у вас написан на html + razor + байндинг модели от Vue.js

    Razor здесь занимает минимум места, только для передачи констант.
    На Html написан шаблон vue. Это стандарт в данном случае.
    Как я уже писал Vue в данном примере кроме биндинга строит выпадающие списки и подключает CSS по условию. Может естественно больше. Просто хотелось продемонстрировать базовые часто встречающиеся задачи.

  • VueJs + MVC минимум кода максимум функциональности
    0
    Зачем люди придумали Vue(angular, react) когда то же можно сделать на jquery?
    Для простой формы, да может быть у вас кода будет меньше.
    Если форма будет иметь много полей, таблицы и какую то элементарную логику типа скрыть часть полей по условию и все такое не уверен.
    В моем примере дальнейшее наращивание количества полей не добавит много кода.
    Зато всю «отрисовку» можно делать используя Vue, что поверьте значительно удобнее (он для того и создан). Короче пример минимизирован для показа элементарных возможностей.
    Когда же надо будет нарисовать действительно сложную и навороченную форму можно и компонентов добавить и webpack подключить и роутер ну короче использовать всю мощь Vue.
    Зачем лезть в Vue.js? Что бы узнать его на должном уровне.
    Ну кроме всего прочего следующий проект надеюсь мы будет Single Page Application.
  • VueJs + MVC минимум кода максимум функциональности
    –1
    Да именно так.
    И полагаю, что при минимальной оптимизации нагрузка на сервер не сильно возрастет ибо json с данными как не крути на порядок меньше Html формы отображающей эти данные.
  • VueJs + MVC минимум кода максимум функциональности
    –1
    Я рассматривал такой подход для стандартных случаев когда валидация заключаться в проверке длины и тп. Только кода получится больше. И он будет на много сложнее.
    Да чем собственно клиент может быть не доволен.
    Сейчас он жмет на кнопку сохранить и получает список ошибок через минуту например.
    В данном случае он успеет нажать кнопку сохранить не дожидаясь валидации и так же через минуту, а то и раньше увидит красные рамки вокруг невалидных полей.
  • VueJs + MVC минимум кода максимум функциональности
    –1
    Сама модель не мешает, просто классический подход в том что нужно отправить форму на сервер, что бы увидеть ошибки валидации, а перезагрузка формы сжирает трафика в разы больше чем валидация.
    В том то и удобство Single Page Application что сайт загружается один раз, а далее вся работа идет через Ajax асинхронно. К сожалению такой подход не возможен в моем случае. Поэтому приходится использовать загрузку каждой страницы отдельно. Но далее страница работает без перезагрузок используя возможности VueJs. Вполне стандартным для этого фреймвока способом.
    Такой подход получается чуть проще (нет ни каких сборщиков роутеров и пр. ) достаточно подгрузить базовую библиотеку через cdn
  • VueJs + MVC минимум кода максимум функциональности
    +1
    Поверьте умею. Но тогда я должен настраивать валидацию два раза. Первый раз на уровне Entity а второй на клиенте. Eсли валидация завязана на длину полей в базе, или пустое значения, то конечно перетащить не сложно, а если логика более сложная и требует обращения к базе?
    Здесь все единообразно и настраивается в одном месте.
  • Тестировать только через public-методы плохо
    0
    1) Методики TDD и BDD предполагают что вы сами пишете код и в таком случае код получается тестируемый (как я понимаю в данном случае не так).
    2) Лично я всегда следую принципу с минимальными усилиями получить максимальный результат. Исходя из этого считаю допустимым в тесте через рефлексию установить значение приватного поля. Но это скорее исключение чем общее правило.
  • 3 греха программиста: Хардкодинг, Говнокодинг и Шизокодинг
    +3
    Из нормальных языков вы еще C# не указали.
    По поводу PHP. Это инструмент который позволяет относительно быстро (быстрее чем Perl) обучиться и начать писать работающий код. Качество кода напрямую зависит от самого программиста и культуры разработки в коллективе где он работает. Можно и на строго типизированном языке говнокод написать.
    Вообще же выбор языка как инструмента очень важен.
  • 3 греха программиста: Хардкодинг, Говнокодинг и Шизокодинг
    +1
    Чем же вам PHP не угодил? Он ведь создан для Web разработки.
    И список нормальных языков для Web.
  • 3 греха программиста: Хардкодинг, Говнокодинг и Шизокодинг
    0
    1)Не очень согласен с разделением кода на категории.
    Стиль написания какой бы он ни был в моем понятии не делает код Говнокодом.
    А вот излившее усложнение кода очень даже.
    Но кроме усложнения могут быть наверное еще признаки говнокода (тут надо подумать).
    2) Есть такой принцип Кiss.(делай это как можно проще). В википедии при описании его приведены цитаты нескольких известных людей и они тоже подходят как илюстрация к теме данной статьи. При этом идея несколько шире чем принцип Оккамы( Не плоди лишних сущностей).
  • Сопротивления автоматизации тестирования
    +1
    Если тесты написаны правильно и покрывают все возможные сценарии (А именно так и должно быть при подходе через ТDD), то вероятность внесения ошибки ничтожно мала.
  • Сопротивления автоматизации тестирования
    0
    Ответ только один включить голову и почитать «умные» книжки и статьи.
    Как вариант предложить эксперимент
    Сделать серьезные изменения в сложном коде коде
    1) который был покрыт тестами.
    2) который не был.
    Делать должен тот кто этот код не писал.(или писал очень давно).
    Вероятность внести ошибку во втором случае заставит разбираться как все работает досконально ( или положиться на авось).
    В первом же случае проще разобраться в том что написано и есть ГАРАНТИЯ что я ни чего не сломал.
  • Сопротивления автоматизации тестирования
    +1
    Далее результат может быть отрицательный потому что.
    1) Разработчики изначально учились что замедляет процесс.
    2) Разработчики пробовали писать тесты на то что не стоит тестировать. Простой код, или GUI (овчинка выделки не стоит).
    3) Результат может появится когда кому ни будь приведется переписать функционал А это далеко не 2 месяца.
    У меня тесты 5- 6 летней давности работают себе без проблем а стоит полезть в этот код, что то ломается ( не было бы тестов и не узнал бы что внес ошибку) и ее словили бы в продакшене возможно с воем и с претензиями денежными.

  • Сопротивления автоматизации тестирования
    +1
    Если кто то проводил такие исследования то выложите их в открытый доступ пож
  • Сопротивления автоматизации тестирования
    0
    По поводу уверенности.
    Она может быть есть если ты работаешь один, а вот по мере увеличения количества работающих увеличиваются шансы что тебя кто ни будь «сломает».
    Не говоря уш о том, что если придется дорабатывать свой же функционал пару лет спустя тесты помогут.
    И главное тесты это инструмент и пользоваться им должен уметь каждый программист.
    Как каждый столяр должен пользоваться лобзиком, топором, бензопилой и прочим. Каждому инструменту свое место.
  • Сопротивления автоматизации тестирования
    +1
    1) В том то и дело что не Не пробовали может кто то и сделал пару тестов из под палки чисто для галочки но большинство не пробовало.
    2) Я люблю писать тесты. Но есть ситуации когда я то же не пишу тесты потому что понимаю что овчинка не стоит выделки.Понимаю на основании опыта написания тестов.
    И наоборот есть ситуации когда ОТЛАДКА через тесты экономит время.
    Ну а когда с помощью теста кусочек кода отлажен, я просто пишу асерт начинаю отлаживать следующий кусочек кода в другом тесте.
    Таким образом я экономлю время а тесты остаются как полезный артефакт от разработки.
  • Сопротивления автоматизации тестирования
    0
    Культура программирования это конечно важно, но дело столько в культуре как таковой.
    Отсутствие автоматического тестирования свидетельство, что программистам ведущим по крайней мере НЕ ИНТЕРЕСНО ПРОГРАММИРОВАНИЕ. Они привыкли делать свою работу определенным образом. Книги и статьи о программировании перестали читать много лет назад. И они ни чего не хочет менять, они искренне уверены, что тесты просто пустая трата времени. Продумывайте интерфейс, не совершайте ошибок и все будет ок.
    Нормальному программисту как минимум должно быть интересно, что за тесты такие и действительно ли они помогают. А начальник программистов просто ОБЯЗАН изучать практики помогающие улучшить работу своих подчиненных и соответственно внедрять их.
    Рядовые же программисты просто серая масса которой однозначно пофигу все. Пока деньги платят.
  • Экосистема разработки в 2018 году: чем живут программисты в России и мире
    0
    Да именно это и имел в виду Спасибо
  • Экосистема разработки в 2018 году: чем живут программисты в России и мире
    +1
    Ну как бы кроме собственно использования языка есть как бы способ разработки в общем наверное похожие в любом языке.
    к примеру скрам(канбан), юнит тест, tdd.
    Интересно узнать как много компаний это используют.И как аргумент в убеждении начальства в том что работа идет про правилам прошлого века.

  • Экосистема разработки в 2018 году: чем живут программисты в России и мире
    0

    Интересно бы узнать соотношение по категориям. Использует скрам.
    Юнит тесты и т п.

  • Практика написания тестов. Лекция Яндекса
    0
    НЕ согласен по всем пунктам.
    1 и 2 Как уже писалось в обсуждении этой статьи тесты при правильном использовании экономят время даже во время разработки.
    3 Если изменилось API. Нарушение от принципа открытости закрытости. Ну как бы бывает конечно такая необходимость но сравнительно редко. И тогда новое API Надо тестировать.
    4 Да не бесплатно за все надо платить
    Тесты гоняются на сервере и жрут сволочи электричество ( посчитайте сколько интереса ради) Ну и иногда находят ошибки которые увы надо править. Что то же занимает время и иногда раздражает. Ну вроде бы все сделал а тут ошибка за ошибкой.

    А вот про авто написание тестов это интересная мысль. Хотя и не понял толком что там происходит.
    по Вашим словам я понял что вы ухитрились так написать Лог что бы он имитировал вызов функции с параметрами которые были преданы.
    Это должно быть сделано автоматически Вызвал в начале каждого метода функцию типа Log.AutoTraiсe и готово
    Если это на Net то Если можно дайте образец кода
  • Практика написания тестов. Лекция Яндекса
    0
    Так то оно так но есть к сожалению троглодиты которые книжек ни читают и тесты не пишут
  • Практика написания тестов. Лекция Яндекса
    0
    Главная задача для меня — получать удовольствие от программирования.

    Как бы это… тут мы как представители древнейшей профессии (приятно, да еще и деньги платят не малые).
    А по поводу высоком уровне. В Зависимости от задачи отвечаю на вопросы
    Что должно произойти в системе?
    Как это может быть исполнено?
    Ну и пишу соответствующие тесты и интерфейсы которые пока мокаются.
    в дальнейшем заменяю моки реализацией.
    В общем BDD
  • Практика написания тестов. Лекция Яндекса
    0
    К стати я тоже стараюсь сначала писать тесты только мотивация у меня совсем не такая.
    Я работаю скорее по BDD начинаю проектировать на каком то достаточно высоком уровне и постепенно спускаюсь к более низкоуровневым конструкциям, но до тестов одного класса доходит редко обычно в случае если там какая то особо заумная функция есть.
    И мотивация только одна сделать свою работу как можно лучше. А все что Вы перечислили это только дополнительные стимулы.
  • Практика написания тестов. Лекция Яндекса
    0
    Юнит тесты тестируют именно поведение классов. Модули, состоящие из множества классов тестируют интеграционными тестами.

    Вот именно с этим я и спорю Интереса ради почитайте искусство автономного тестирования автор Рой Ошероув
    Вот определение UnitTest которое он дает

    Единица работы
    — это совокупность действий от момента вызова какого-то
    открытого метода в системе до единственного конечного результата, замет-
    ного тесту системы. Этот конечный результат можно наблюдать, не исследуя
    внутреннее состояние системы, а только с помощью открытых API и поведе-
    ния.
    Автономный тест – это часть кода, которая
    вызывает единицу работы и затем проверяет ее конечный результат. Если
    предположения о конечном результате не подтверждаются, считается, что
    автономный тест завершился неудачно. Объектом автономного тестиро-
    вания может быть как единственный метод, так и совокупность нескольких
    классов.

    Баги часто встречаются именно при взаимодействии классов. Если несколько классов предоставляют некую сущность которую можно протестировать вместе то лучше так и делать. И если вы считаете этот тест интеграционным, ну это ваше дело.
    Цель За меньшее время написать тесты имеющие наибольшее покрытие.
    вот к стати статья в которой автор рассуждает об интеграционных и юнит тестов https://habrahabr.ru/post/275249/
  • Практика написания тестов. Лекция Яндекса
    0
    В общем все правильно но пару маленьких замечаний.
    1) Статья некая обзорная лекция о тестировании применимая думаю на любой платформе и любом языке.
    Зачем в заглавии слово Android?
    2) Скорее вопрос. Я согласен с определениием юнит тестов.
    Но скажите пожалуйста у Вас в фирме при написании тестов действительно «Чаще всего в качестве юнита выбирается какой-либо класс».
    Думаю, что это скорее исключениие. Реально выбирается модуль состоящий обычно из множества классов.
    Ну для примера можно скачать с GitHab нескольно приложений в который есть тесты.
    Специально я не исследовал, но на вскидку не нашел ни одного в котором тестировался бы каждый класс отдельно.
    Почему я на это обратил внимание?
    В фирме где я работаю начитались таких утверждений и считают это образцом.
    Ну а так как классов у нас тысячи (порядка 5 000) и в каждом классе минимум пять функций,
    то написание Юнит тестов это хотя и надо, но непозволительно долго.
    3) Утверждение что Написание тестов значительно увеличивает время разработки справедливо в первую очередь если UnitTest пишется на объекты низкого уровня.
    Если разработчик не парится по поводу размера юнита, а пишет тесты исходя из здравого смысла, то возможно даже и сокращает.
  • Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо
    –1
    1)Смысл в том что мои «считалки» идут в разрез с общей терминологией. И общая практика вроде бы как раз писать больше чистых Unit тестов.
    2) Наши базы это эталонные базы соответствующих версий. Так как я тесты провожу в одной транзакции с последующим откатом, то насрать туда нереально.
    Единственный мой мок базы в том, что я использую всегда один коннект и начинаю транзакцию перед тестом.
    (Система построена так, что все внутренние транзакции в таком случае создают savePoint)

  • Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо
    –1
    У каждого естественно своя ситуация и он сам может определить для себя СТОИМОСТЬ-ЭФФЕКТИВНОСТЬ.
  • Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо
    0
    1) Да система то же Unit (только очень большой)
    2) Да я для себя считаю все тесты Unit хотя на самом деле почти все мои тесты интеграционные.
    3)Базу я не мокаю потому, что по очень долго заполнять все свойства из параметров теста и прочее
    реально встречаются очень сложные объекты с десятками свойств и вложенных свойств.
    их в моем конкретном случае проще начитать из базы.
    Вообще где то в планах сделать для теста кешируемое обращение к базе.
  • Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо
    0
    я для себя сделал такое определение Unit для юнит теста это класс или группа классов имеющих какое то законченное поведение.
    И в тесте я проверяю именно соответствие этому поведению.
    Про взаимодействие с базой.
    Естественно взаимодействие с базой у нас через интерфейсы и при желании их можно подменить но
    1. При любом раскладе я должен проверить корректность «Маппинга» полей в базе на свойства класса
    2. Откуда брать корректурные значения для заполнения свойств классов?
    3. То же самое и про метаданные

    И учитывая, что тестов пока не запредельно много я не мокаю базу.
  • Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо
    0
    Как я уже говорил время хождения тестов не столь критично.


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

    Увы во всей компании только я один использую тесты
    Тесты разбиты по категориям 'дневной' и 'ночной' и TeemCity гоняет их после каждого комита (не только моего) дневные тесты ходят обычно минут 5 и это сопоставимо с временем сборки всех проектов.
    А на своем компе я гоняю обычно тесты того что я разрабатываю и опять время выполнения тестов не на много больше времени сборки. Так что быстродействие тестов пока для меня не критично.
  • Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо
    0
    Но мой опыт говорит, что в отдельном классе даже тестировать зачастую нечего и классов таких достаточно много.

    Ну так не тестируйте, никто ж не заставляет.

    Да не заставляет, но концепция UnitTest именно в том, что бы тестировать классы по отдельности.

    Вместе они образуют некий Unit который я и тестирую

    А вот это уже странно.
    Много классов, в которых тестировать нечего, вместе не могут образовывать нечто, где есть, что тестировать.
    Ну или вы умалчиваете, что у вас есть что-то, что объединяет эти классы, что вы на самом деле и тестируете.

    Тут уже словоблудие, естевственно я тестирую именно взаимодействие классов.

    При этом я не мокую базу ибо это долго

    Почему долго-то? В коде с корректно разделенными ответственностями это быстро.

    Потому что наш код тесно переплетен с базой.
    Все объекты берут свои метаданные из базы и… в общем случае корректно создать класс без обращения к базе весьма и весьма долгона
    На самом деле я давно думаю написать какую ни будь заглушку, что бы кешировать обращение к базе.

    да он ходит относительно долго но его быстро написать

    Быстро ли? У меня есть жизненный пример, когда интеграционные тесты пишутся намного медленнее, чем юнит (именно потому, что надо много всего учитывать).

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

    скорее покажет что возникла ошибка.

    Почему «скорее»? Выполняется он медленнее, и вариантов тоже покрывает меньше.

    Мне не критично сколько по времени ходят тесты на сервере непрерывнои интеграции. А вот вероятность поймать ошибку выше потому, что косвенным образом тестируют еще много чего.

    Кроме того он не устареет если к примеру изменится название поля в базе

    Правда? А откуда у вас берется БД с актуальными названиями полей (да еще и доступная с CI-сервера)?
    А представьте, что у вас одновременно пошли тесты по трем версиям, у каждой из которых своя БД?

    Ну естевственно нужная база должна быть доступна с сервера. И у каждой версии своя база.

    И да, мои юнит-тесты тоже не устаревают, когда меняется название поля в БД. Им вообще плевать на названия полей в БД.

    Но вы все равно вынуждены писать тесты на корректную работу с базой.

    Писать тесты на каждый класс на самом деле безумно долго

    Не надо писать на каждый. Надо писать на те, где это оправданно.

    Что я и делаю.

    Тесты будут зачастую простые до идиотизма

    Это же прекрасно. Простой тест — меньше ошибок в самом тесте, меньше ложных срабатываний, проще сетап.

    Ответ в вы сами дали в пункте выше.

    и любое изменение потребует переписать кучу тестов.

    Почему вдруг?

    Изменив один класс я должен переписать все моки этого класса. И хорошо еще если ни чего не забуду.

    А общий интеграционный тест все равно необходим.

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

    Как я уже говорил время хождения тестов не столь критично.

    РЕЗЮМЕ:
    Писать тесты нужно исходя из критерия СТОИМОСТЬ-ЭФФЕКТИВНОСТЬ.
    Стомость-время затраченное на написание (Поддержку).
    Эффективность — шанс найти ошибки.
    И я нахожу, что по этому критерию большая часть должна быть именно интеграционных тестов.