Комментарии
15
Читая эту статью можно подумать будто в проектах покрытами тестами не копится тех долг. А сопровождение тестов тоже бесплатно и не затрачивает времени на разработку, когда тесты реагируют на каждое изменение и ломаются.
И чрезмерное размазывание архитектуры по слоям не тратит времени ни на проектирование, ни на сопровождение, если у вас нет четкой договоренностей, регламентов что за что отвечает .)
Ставить под сомнение что-то тоже нормально. Это можно выработать новый правильный, хороший подход, который подходит вашей компании — проекту.
А вот быть идиалистом и перфекционистом оч спорно, можно тратить кучу времени на то, что не будет нужно или вообще выкинут. Оч зависит от компании и целей ее разработки, что вам нужно? Быстрый mvp или оч качественный продукт без сбоев.
Ну и закреплять то, что у вас в компании надо внутренним регламентом компании, а не статьями на хабре.
И чрезмерное размазывание архитектуры по слоям не тратит времени ни на проектирование, ни на сопровождение, если у вас нет четкой договоренностей, регламентов что за что отвечает .)
Ставить под сомнение что-то тоже нормально. Это можно выработать новый правильный, хороший подход, который подходит вашей компании — проекту.
А вот быть идиалистом и перфекционистом оч спорно, можно тратить кучу времени на то, что не будет нужно или вообще выкинут. Оч зависит от компании и целей ее разработки, что вам нужно? Быстрый mvp или оч качественный продукт без сбоев.
Ну и закреплять то, что у вас в компании надо внутренним регламентом компании, а не статьями на хабре.
Вы как будто с самим собой поспорили и с самим собой согласились =)
Регламенты и документация это как правильно про решение «делаем» и меньше всего про ответы на вопросы «зачем» и «почему» именно так делаем. Вы как будто не встречались с людьми когда говорите про одно и тоже, но у каждого свой взгляд. Как результат вы друг друга не понимаете и снова и снова возвращаетесь к одному и тому же вопросу:
(PR: code review)
— «Нужно исправить и написать нормальное название метода»
— «Оно и так нормальное»
— «testFileSerializer это ненормальное название»
— «А какое нормальное? Вроде бы ок, меня устраивает. Мы же сериализатор файла протестировали там»
… (немая сцена и занавес)…
Как объяснить свой взгляд другому человеку? Добавить чуть больше воды, объяснений, привести пример с вымышленным сотрудником… Так статья и получилась.
Регламенты и документация это как правильно про решение «делаем» и меньше всего про ответы на вопросы «зачем» и «почему» именно так делаем. Вы как будто не встречались с людьми когда говорите про одно и тоже, но у каждого свой взгляд. Как результат вы друг друга не понимаете и снова и снова возвращаетесь к одному и тому же вопросу:
(PR: code review)
— «Нужно исправить и написать нормальное название метода»
— «Оно и так нормальное»
— «testFileSerializer это ненормальное название»
— «А какое нормальное? Вроде бы ок, меня устраивает. Мы же сериализатор файла протестировали там»
… (немая сцена и занавес)…
Как объяснить свой взгляд другому человеку? Добавить чуть больше воды, объяснений, привести пример с вымышленным сотрудником… Так статья и получилась.
Если у вас есть более хорошее название для класса, метода, то надо в пул реквесте сразу и предложить его, а не заставлять человека угадывать, что вы от него хотите. Он к вам в голову не залезет и на работу ходит не в загадки играть.)
Токсичное поведение похоже уже норма в айти.
Токсичное поведение похоже уже норма в айти.
Конечно я предложу свой вариант, а ещё объясню, что прочитав такое название понять «что делает тест и зачем он это делает» гораздо быстрее чем тратить время на переходы в основной код. Это помогает не тратить время в будущем, угадывая мысль автора каждый раз.
Сопровождение обходится дорого, посколькуПотому-что здесь сравнивается стоимость разработки, которая по сути является первым MVP-решением продукта (читай — «первые несколько спринтов»). А в сопровождение вкладывается всё последующее развитие продукта (читай — все все «будущие спринты»).
Все мы понимаем, что ПО — это не «сделал и забыл». Это чаще всего долгоживущий продукт, который требует постоянных изменений.
ПО должно быть спроектировано так, чтобы уменьшалась его общая стоимость. Она делится на начальную стоимость разработки и стоимость сопровождения:Непонятно откуда взявшийся постулат, от которого идут все последующие заблуждения. Можно по-разному оценивать стоимость ПО, но для меня, стоимость ПО = стоимость всех вложенных в него ресурсов — как людских, так и материальных. Она по дефолту не может уменьшаться. Мы можем только всеми правдами и неправдами замедлять рост затрат на её поддержку.
В идеале всегда нужно искать баланс между стоимостью капитальной разработки — со всеми тестами, и скоростью (читай — без тестов). Ведь завтра вполне может оказаться что определенная фича оказалась никому не нужной фичей, от которой нет никакого толку. И бизнесу важнее будет быстро по тестировать её, понять что она не выстрелит, и перейти к следующей, чем тратить x2 ресурсов на то же самое, но с тестами.
А если фича выстреливает — выделяем время на рефакторинг и приведение к хорошему виду, с тестами итд. Везде нужно соблюдать баланс и гибкость. И здесь нет правильного ответа — когда надо сразу делать капитально. Здесь поможет только ваш опыт, или дар предвиденья)
Можно по-разному оценивать стоимость ПО, но для меня, стоимость ПО = стоимость всех вложенных в него ресурсов — как людских, так и материальных. Она по дефолту не может уменьшаться.
Я где-то читал что за последние 10 лет стоимость разработки ПО уменьшилась (не помню на сколько но цифра впечатляла)
И что это значит? Все разработанное ПО вдруг подешевело? Или стоимость разработки первого MVP стало ниже? Или что в целом всем программистам урезали зарплаты и снизили расходы? Я могу написать, что стоимость выросла, тк как минимум зарплаты регулярно везде из за инфляции растут. Так что теперь можете писать, что где-то читали, что стоимость разработки ПО увеличилась ))д
Вы как-то очень категорично пишите про null, не надо так :) Не принято возвращать null вместо коллекций и массивов (и передавать в параметрах тоже нежелательно).
wiki.sei.cmu.edu/confluence/display/java/MET55-J.+Return+an+empty+array+or+collection+instead+of+a+null+value+for+methods+that+return+an+array+or+collection
wiki.sei.cmu.edu/confluence/display/java/MET55-J.+Return+an+empty+array+or+collection+instead+of+a+null+value+for+methods+that+return+an+array+or+collection
Я такой код встречал и наверное буду встречать, поэтому и написал. Моя задача поделиться опытом, дать информацию почему так делать не стоит.
Люди, которые такой код пишут, после этой статьи ничего не поймут в лучшем случае. В худшем они сочинят каких-нибудь NullPerson-ов потому что нельзя же null использовать :)
Аккуратнее было бы не писать «Не используйте null», а ограничиться только упоминанием антипаттеров и их объяснением (null вместо коллекций и массивов уже умоминали, но есть еще например «if (param == null) return null»).
Аккуратнее было бы не писать «Не используйте null», а ограничиться только упоминанием антипаттеров и их объяснением (null вместо коллекций и массивов уже умоминали, но есть еще например «if (param == null) return null»).
Разве из слов это не становится понятным? =)
я не хотел увеличивать словами текст статьи, всё-таки фокус на тестах.
старайтесь отказываться, где это возможно, от использования null, чтобы он не пронизывал, как игла, весь ваш код
я не хотел увеличивать словами текст статьи, всё-таки фокус на тестах.
CI Pipeline картинка в Вашей статье описывает 4 шага включая run integration tests, при этом дальше вы пишете: "при желании, можно провести и интеграционное тестирование." Это как? От чего зависит это желание? На мой взгляд, CI на то и дан, чтобы программисты не задумывались о запуске всех тестов всех уровней, а это бы делалось автоматически.
Изменил на: «выполнить интеграционные тесты если они являются частью вашего проекта». Так же дополнил описание в статье:
Интеграционные тесты могут быть или частью вашего проекта, или вынесены в отдельный проект, или оба варианта вместе. В первом варианте вы работаете с локально поднятыми службами (message queue, database) + используете HTTP Mocks, эмитируя ответы сторонних сервисов. Во втором варианте вы проверяете работу вашего сервиса и его взаимодействие с другими сервисами в окружениях QA/Stage.
Спасибо за дополнение и правку.
Еще опечатка наверно: если Крис скачивает репозиторий на рабочий комп, тогда команда git clone, а не git pull
Ага, исправил.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Тесты, деньги и техдолг (сказ из жизни одного Java-проекта)