Утверждения годные, но без конкретных примеров спорить почти не о чем
Что происходит с юнит-тестами при рефакторинге?
Зачем нужен тест, которому я заранее говорю, что будет на выходе, а потом проверяю, что на выходе именно это?
Большая часть юнит-тестов проверяет только количество вызовов при разных вызовов, а не данные.
Интеграционные делают всю основную работу тестирования и служат гораздо более яркими лампочками - и в гораздо меньших количествах, не перегружая мозг, - чем юнит.
Большое количество юнит-тестов сильно замедляет деплой, сиди и жди, пока они все пробегут.
Еще раз, Паскаль единственный нормальный вводный язык для понимания алгоритмов. Для возраста 10-14 лет вообще самое то. Писать на нем конечно нечего, но развивать мышление очень даже. Он и создан был именно как учебный язык программирования. Осваивается за день, структурный, и очень-очень простой. Для обучения с нуля нельзя использовать "сложные" языки, у которых много особенностей, как тот же Си, Си++, Java, Python и прочее из топа популярных. По той простой причине, что вместо изучения алгоритмов начинается изучение собственно языка, что отвлекает внимание от алгоритмов. А если изучать алгоритмы на тех же сях или жаве, не особо упирая на специфику языка, можно приобрести ряд нехороших привычек, которые в серьезных проектах будут вредны.
Я в программировании чуть больше тридцати лет и все больше убеждаюсь, глядя на молодых программистов и их "код", что начинать надо с языков специально созданных для изучения алгоритмов, в первую очередь, это Паскаль. Потом двигаться в сторону Си, можно и одновременно, для изучения хранения структур данных в памяти и вообще работы с памятью. А дальше уже брать ООП язык, и тут конечно рулит Java.
Мы работаем спринтами по три недели, с предпланированием, распределением ресурсов аналитик-разработчик-тестировщик, по каждой задаче дается три срока (оптимистик, средний, пессимистик), задачам может назначаться метка "риска переноса" и прочее.
То, что говорится здесь, о чем говорится здесь, это какой-то конец 90ых, начало нулевых. Маленькие команды, когда задачу надо решить реально вот прям за два часа. Прошлый век. Когда жава жила без лямбд. Просто не могу проверить, что кто-то еще где-то сталкивается с этими допотопными проблемами.
Рахрабам часто советуют книжки по психологии)
Утверждения годные, но без конкретных примеров спорить почти не о чем
Что происходит с юнит-тестами при рефакторинге?
Зачем нужен тест, которому я заранее говорю, что будет на выходе, а потом проверяю, что на выходе именно это?
Большая часть юнит-тестов проверяет только количество вызовов при разных вызовов, а не данные.
Интеграционные делают всю основную работу тестирования и служат гораздо более яркими лампочками - и в гораздо меньших количествах, не перегружая мозг, - чем юнит.
Большое количество юнит-тестов сильно замедляет деплой, сиди и жди, пока они все пробегут.
Еще раз, Паскаль единственный нормальный вводный язык для понимания алгоритмов. Для возраста 10-14 лет вообще самое то. Писать на нем конечно нечего, но развивать мышление очень даже. Он и создан был именно как учебный язык программирования. Осваивается за день, структурный, и очень-очень простой.
Для обучения с нуля нельзя использовать "сложные" языки, у которых много особенностей, как тот же Си, Си++, Java, Python и прочее из топа популярных. По той простой причине, что вместо изучения алгоритмов начинается изучение собственно языка, что отвлекает внимание от алгоритмов. А если изучать алгоритмы на тех же сях или жаве, не особо упирая на специфику языка, можно приобрести ряд нехороших привычек, которые в серьезных проектах будут вредны.
Я в программировании чуть больше тридцати лет и все больше убеждаюсь, глядя на молодых программистов и их "код", что начинать надо с языков специально созданных для изучения алгоритмов, в первую очередь, это Паскаль. Потом двигаться в сторону Си, можно и одновременно, для изучения хранения структур данных в памяти и вообще работы с памятью.
А дальше уже брать ООП язык, и тут конечно рулит Java.
Мы работаем спринтами по три недели, с предпланированием, распределением ресурсов аналитик-разработчик-тестировщик, по каждой задаче дается три срока (оптимистик, средний, пессимистик), задачам может назначаться метка "риска переноса" и прочее.
То, что говорится здесь, о чем говорится здесь, это какой-то конец 90ых, начало нулевых. Маленькие команды, когда задачу надо решить реально вот прям за два часа. Прошлый век. Когда жава жила без лямбд. Просто не могу проверить, что кто-то еще где-то сталкивается с этими допотопными проблемами.
Да в ИИ такая математика, любой с гвузду двинется. Бедный инженер. Надеюсь вылечат.
Ваш Лиант.