Comments 8
>начали использовать автоматическое устранение таких багов как неисправный поинтер, который указывает на несуществующую ячейку
LOL
Ну а вообще тема довольно известная. Грант как грант, тема как тема. Хотелось бы вайтпепер почитать, но что-то не нагугливается. А вот что забавно, дак это посмотреть на публикации чела и на его соавторов:
Там, как правило, полная дичь в соавторстве с Тормасовым — видимо, улучшают показатели института по статьям, лол
Еще нашел студенческую статью — опросник по студентам и натягивание компьютер саенса на него
И еще статья посерьезнее, но написанная им в Сингапуре. Причем, что самое смешное, у него там числится Попилополис как институт
По итогу мне кажется, что это профанация, деньги уйдут на студенческую нерабочую поделку и зарплату профессору.
LOL
Ну а вообще тема довольно известная. Грант как грант, тема как тема. Хотелось бы вайтпепер почитать, но что-то не нагугливается. А вот что забавно, дак это посмотреть на публикации чела и на его соавторов:
Там, как правило, полная дичь в соавторстве с Тормасовым — видимо, улучшают показатели института по статьям, лол
Еще нашел студенческую статью — опросник по студентам и натягивание компьютер саенса на него
И еще статья посерьезнее, но написанная им в Сингапуре. Причем, что самое смешное, у него там числится Попилополис как институт
По итогу мне кажется, что это профанация, деньги уйдут на студенческую нерабочую поделку и зарплату профессору.
Тоже посмотрел его статьи, есть вполне серьезные работы за последние 2 года, а есть где он числиться 4ым-5ым автором, я бы не стал на них сильно внимание обращать. В целом нормальный чел, хотя тема на мой взгляд не самая интересная. С февраля 2019 он переезжает в Корею кстати.
ПопилополисОх уж эти гранты КВН на оригинальное название города/универа…
Практически любое программное обеспечение содержит ошибки, особенно с появлением непрерывных процессов разработки, тестирования и внедрения
Подскажите, как понимать данное предложение?
Мне читается как: CI/CD и тестирование привело к бОльшему количеству багов.
Я перефразирую: «С появлением скоростных трасс, и хорошего дорожного покрытия количество ДТП увеличилось.» В такой формулировке все логично.
Возвращаясь к изначальной фразе, тут есть как минимум психологический фактор — чем больше ты полагаешься на внешние системы контроля тем меньше контролируешь сам.
Система сборки и ее контроля автоматизирована, можно накидывать код в три раза быстрее. Но код от этого лучше не становится. Цикл разработки становится короче. Увеличивается давление на разработчика (нужно успеть уже не к послезавтра, а к сегодняшнему вечеру), и он больше предпочитает быстрые решения правильным.
А что до тестов — они не делают программу лучше. Они не делают программистов лучше. Они всего лишь выявляют некоторые дисфункции в программе.
Тесты вообще не обеспечивают качество программ (quality assurance) — это делают разработчики. Обеспечение качества это сделать так, чтобы ошибок не возникало. Не ставить радары и штрафовать за превышение скорости, а сделать так чтобы водители не превышали скорость.
Расскажу одну байку. Меня как-то спросили, сколько мне потребуется времени, чтобы автоматизировать набор тестов на подсистему. Я сказал, что это зависит от того, насколько она будет рабочей. Ведь если во время написания теста ты натыкаешься на ошибку в системе, то ее в первую очередь нужно устранить. Тогда мне сказали: «Ну, предположим там все закончено, все работает». На что я ответил, что если «все работает» то тесты уже не нужны. Такой вот «парадокс».
Возвращаясь к изначальной фразе, тут есть как минимум психологический фактор — чем больше ты полагаешься на внешние системы контроля тем меньше контролируешь сам.
Система сборки и ее контроля автоматизирована, можно накидывать код в три раза быстрее. Но код от этого лучше не становится. Цикл разработки становится короче. Увеличивается давление на разработчика (нужно успеть уже не к послезавтра, а к сегодняшнему вечеру), и он больше предпочитает быстрые решения правильным.
А что до тестов — они не делают программу лучше. Они не делают программистов лучше. Они всего лишь выявляют некоторые дисфункции в программе.
Тесты вообще не обеспечивают качество программ (quality assurance) — это делают разработчики. Обеспечение качества это сделать так, чтобы ошибок не возникало. Не ставить радары и штрафовать за превышение скорости, а сделать так чтобы водители не превышали скорость.
Расскажу одну байку. Меня как-то спросили, сколько мне потребуется времени, чтобы автоматизировать набор тестов на подсистему. Я сказал, что это зависит от того, насколько она будет рабочей. Ведь если во время написания теста ты натыкаешься на ошибку в системе, то ее в первую очередь нужно устранить. Тогда мне сказали: «Ну, предположим там все закончено, все работает». На что я ответил, что если «все работает» то тесты уже не нужны. Такой вот «парадокс».
чем больше ты полагаешься на внешние системы контроля тем меньше контролируешь сам.
Так откажитесь от компилятора — и контролируйте все сами. Напишите проект с бинарем в 1 МБ и поделитесь Вашей продуктивностью и количеством ошибок на пути.
Ваша логика в корне не верна, Вы не принимаете во внимание ограниченнойсть ресурсов человеческого мозга. Автоматизация позволяет повысить уровень абстракции и производить более сложные продукты.
Все так. Но автоматизация как таковая не улучшает качество конечных продуктов.
Взять какой-нибудь продвинутый станок с ЧПУ. Качество производимых деталей будет конечно лучше, детали будут производится быстрее. Но появится брак другого типа. Ошибки человека программирущего машину, и ошибки при проектировании детали. Увеличилось количество фабриката, появились проблемы с хранением. Появился брак из-за неправильного хранения.
И как Вы верно сказали, мы можем быстрее делать более сложные системы, но брак полностью не устраняется, он скорее переходит на другой уровень.
Появились фреймворки для javascript, разработка сложных систем ускоррилась, но стало необходимым тонкое понимание устройства фреймворка и его неправильное использование приводит к браку.
У меня есть стойкое ощущение того, что эволюция систем производства не улучшает качества конечной продукции. Она только позволяет производить более сложные системы в более короткие сроки. А ошибки как были так и есть, только другие.
Что касается изначальной фразы, скажу честно, у меня нет цифр для сравнения, и вряд ли такое сравнение можно провести. Думаю даже оно не имеет смысла, как сравнение современного автомобиля, и квадроцикла Форда. Так что это чисто мое «ощущение» основанное на личном опыте в проекте. Я бы сказал, что качество производимых продуктов не уменьшилось и не увеличилось. Но это ничем не подкрепленная гипотеза.
Взять какой-нибудь продвинутый станок с ЧПУ. Качество производимых деталей будет конечно лучше, детали будут производится быстрее. Но появится брак другого типа. Ошибки человека программирущего машину, и ошибки при проектировании детали. Увеличилось количество фабриката, появились проблемы с хранением. Появился брак из-за неправильного хранения.
И как Вы верно сказали, мы можем быстрее делать более сложные системы, но брак полностью не устраняется, он скорее переходит на другой уровень.
Появились фреймворки для javascript, разработка сложных систем ускоррилась, но стало необходимым тонкое понимание устройства фреймворка и его неправильное использование приводит к браку.
У меня есть стойкое ощущение того, что эволюция систем производства не улучшает качества конечной продукции. Она только позволяет производить более сложные системы в более короткие сроки. А ошибки как были так и есть, только другие.
Что касается изначальной фразы, скажу честно, у меня нет цифр для сравнения, и вряд ли такое сравнение можно провести. Думаю даже оно не имеет смысла, как сравнение современного автомобиля, и квадроцикла Форда. Так что это чисто мое «ощущение» основанное на личном опыте в проекте. Я бы сказал, что качество производимых продуктов не уменьшилось и не увеличилось. Но это ничем не подкрепленная гипотеза.
del
Sign up to leave a comment.
Сотрудник Университета Иннополис получил грант Facebook