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