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