Конечно проще. А еще проще написать "Напиши хорошие тесты", потом убедится что все зелененькое и пойти спокойно домой. А чтобы понять что оно там на самом деле тестирует нужно думать, а это как мы все знаем сложно и лениво.
Мой пример именно об этом, не о том что код проще написать, а о том что плохие тесты сложно визуально отличить от хороших. И он том что чтобы написать хорошую инструкцию нужно все равно напрячься. Проще ли написать инструкцию чем код? Ну допустим проще. Но как проверишь что тесты тестируют то что нужно?
Как проверять программу мы вроде понимаем - если запустилась и что-то сделала то считаем что все ок. А как проверить тесты которые что-то делают и возвращают успех? ломать программу? или читать код тестов? И второе и первое уже достаточно сложно, отсюда и мое сомнение в ускорении процесса.
А я например нормально отношусь к их написаю но ненавижу их читать. Потому что написать средний тест куда проще чем понять "что хотел сказать автор". Почему вначале два запроса туда, потом три сюда? Почему не наоборот? А что это за значение мы ждем в ответ, во всех ли случаях?
Проблема тестов в том что легко написать чушь которая будет выглядеть убедительно.
Создаем компанию, а потом проверяем что мы можем ее найти по имени.
Код работает отлично, вот только функция searchCompany() на самом деле игнорирует параметры и просто возвращает первую компанию из базы данных.
При этом база данных по умолчанию просто возвращает последний созданный объект в таблице.
То есть чтобы тест начал ловить эту проблему нам нужно создать несколько компаний и убедится что каждую из их можно найти.
Но чтобы разобраться в этом мало пробежать чужой код глазами, нужно ожидать подвоха, понимать как работает ваша система, какие ошибки могут произойти, как их лучше искать.
Поддерживаю. Много раз замечал что хорошие решения часто даже стоят по времени не то чтобы больше чем плохие. Просто люди
привязываются к своим идеям, и редко готовы их пересмотреть. Потом они реализуют плохую идею, а потом всей команде приходится ее поддерживать, потому что оно уже на проде и так просто не изменить теперь.
не обладают достаточным опытом
упертые ослы ( смотри пункт один )
Когда попадется упертый человек без опыта или с опытом как делать плохо зато быстро, вот тут начинается бесконечная гонка переделываний говнокода.
Ну еще бывает начальство неправильно ставит задачу, или просто "хочет странного". Например не понимают полноценного решения и топят за какое-то но понятное им. Такие понятные и мегапростые решения тоже регулярно выходят боком.
Разница лишь в том, что нейросети и ИИ имеют двоичный код, а ДНК человека состоит из четырех нуклеотидов, а это значит, что в ДНК можно закодировать на порядок больше информации.
Мда.
Вот и уровень статьи.
Но вообще-то нет, можно закодировать одинаково бесконечное количество информации. Более того двоичный код, это лишь условность, способ хранения данных а не сами данные. Для примера можете распечтать программу (или данные нейронки ) в тексте в base64 на бумаге. Теперь о чудо у нас 62 разных символа, значит ли это что мы только что прошли через удивительный эволюционный скачок и теперь программа может содержать больше комбинаций чем оригинальная хранящаяся в битах ?
Да вы правы. Годы идут, поддерживать рабочую линукс систему если и стало проще, но не сказать чтобы намного.
И если раньше я всем родственникам ставил условную Xubuntu то теперь просто рекомендую купить андроид планшет или Chromebook если людям нужна клавиатура. Это полностью закрывает их потребности ( обычных пользователей которым интернет, мессенджеры, фильмы и тд ), и при этом не требует никакой поддержки. Андроид и ХромОС просто работают. Софт ставится из магазина, никаких страшных надписей, поддержка всего железа.
И если честно я не думаю что это плохо. Пока десктопный линукс нишевой продукт, пока он пролетает под радарами крупных игроков на нем можно нормально жить. Меньше малвари, меньше шпионского говна, меньше внимания.
А убогое и глючное ГУИ, ну что делать, за мои 15+ лет с линуксом уже привык и получаю удовольствие. Стокгольмский синдром видимо.
Ну так любой нужный кому-то инструмент делается во множестве вариантов. У всех свои сценарии использования, все фокусируются на своих сильных сторонах.
Ну и учитывайте что курл это огромная куча сетевых протоколов, тогда как почти всем нужно только http/https
затраты есть, но на то это и называется "исключение", они не предназначены для того, чтобы вы кидали их миллионами и просто так.
Ну так а обычные ошибки как раз предназначены чтобы их кидали, и кидали при необходимости много. Тот же strconv может кинуть ошибку, и если моя программа выбирает числа из тонны мусора то и ошибки там будут сыпаться как из рога изобилия.
x, err1 := strconv.Atoi(a)
y, err2 := strconv.Atoi(b)
if err := cmp.Or(err1, err2); err != nil {
return err
}
вот этот пример максимально нердужелюбен к код ревью. Потому в дифе будет например\
x, err1 := strconv.Atoi(a)
y, err2 := strconv.Atoi(b)
и читающему изменения в коде покажется что первая ошибка не обрабатывается, и чтобы проверить так ли это придётся лезть дальше в код. В общем предложение выглядит максимально странно и мне кажется лишь породит больше скрытых проблем.
"дистопией" по-русски мы обычно говорим Антиутопия.
Для тех кто как и я полез гуглить это выглядит так
Lego Millennium Falcon
Конечно проще. А еще проще написать "Напиши хорошие тесты", потом убедится что все зелененькое и пойти спокойно домой. А чтобы понять что оно там на самом деле тестирует нужно думать, а это как мы все знаем сложно и лениво.
Мой пример именно об этом, не о том что код проще написать, а о том что плохие тесты сложно визуально отличить от хороших. И он том что чтобы написать хорошую инструкцию нужно все равно напрячься. Проще ли написать инструкцию чем код? Ну допустим проще. Но как проверишь что тесты тестируют то что нужно?
Как проверять программу мы вроде понимаем - если запустилась и что-то сделала то считаем что все ок. А как проверить тесты которые что-то делают и возвращают успех? ломать программу? или читать код тестов? И второе и первое уже достаточно сложно, отсюда и мое сомнение в ускорении процесса.
А я например нормально отношусь к их написаю но ненавижу их читать. Потому что написать средний тест куда проще чем понять "что хотел сказать автор". Почему вначале два запроса туда, потом три сюда? Почему не наоборот? А что это за значение мы ждем в ответ, во всех ли случаях?
Проблема тестов в том что легко написать чушь которая будет выглядеть убедительно.
Мой любимый пример выглядит так:
Создаем компанию, а потом проверяем что мы можем ее найти по имени.
Код работает отлично, вот только функция
searchCompany()на самом деле игнорирует параметры и просто возвращает первую компанию из базы данных.При этом база данных по умолчанию просто возвращает последний созданный объект в таблице.
То есть чтобы тест начал ловить эту проблему нам нужно создать несколько компаний и убедится что каждую из их можно найти.
Но чтобы разобраться в этом мало пробежать чужой код глазами, нужно ожидать подвоха, понимать как работает ваша система, какие ошибки могут произойти, как их лучше искать.
Как будто человеку не придется убедится что они что-то в принципе тестируют.
Поддерживаю. Много раз замечал что хорошие решения часто даже стоят по времени не то чтобы больше чем плохие. Просто люди
привязываются к своим идеям, и редко готовы их пересмотреть. Потом они реализуют плохую идею, а потом всей команде приходится ее поддерживать, потому что оно уже на проде и так просто не изменить теперь.
не обладают достаточным опытом
упертые ослы ( смотри пункт один )
Когда попадется упертый человек без опыта или с опытом как делать плохо зато быстро, вот тут начинается бесконечная гонка переделываний говнокода.
Ну еще бывает начальство неправильно ставит задачу, или просто "хочет странного". Например не понимают полноценного решения и топят за какое-то но понятное им. Такие понятные и мегапростые решения тоже регулярно выходят боком.
Звучит очень опасно, через пару лет уже появится свой красный степлер.
А может быть даже с отрицательным потреблением!
Зачем мне ноутбук если у меня будет специально обученный человек? Я просто скажу человеку сделать то что сейчас делаю руками на ноуте =)
Ну вот я таскаю ноут с собой каждый день, и хочу сказать что отлично чувствую разницу между 1кг и 1.5кг. Из семилетнего возраста уже давно вышел.
Еще учтите что в рюкзаке кроме ноута могут быть другие вещи, и в какой-то момент каждые лишние полкило ощущаются совсем иначе.
Мда.
Вот и уровень статьи.
Но вообще-то нет, можно закодировать одинаково бесконечное количество информации. Более того двоичный код, это лишь условность, способ хранения данных а не сами данные. Для примера можете распечтать программу (или данные нейронки ) в тексте в base64 на бумаге. Теперь о чудо у нас 62 разных символа, значит ли это что мы только что прошли через удивительный эволюционный скачок и теперь программа может содержать больше комбинаций чем оригинальная хранящаяся в битах ?
Да вы правы. Годы идут, поддерживать рабочую линукс систему если и стало проще, но не сказать чтобы намного.
И если раньше я всем родственникам ставил условную Xubuntu то теперь просто рекомендую купить андроид планшет или Chromebook если людям нужна клавиатура. Это полностью закрывает их потребности ( обычных пользователей которым интернет, мессенджеры, фильмы и тд ), и при этом не требует никакой поддержки. Андроид и ХромОС просто работают. Софт ставится из магазина, никаких страшных надписей, поддержка всего железа.
И если честно я не думаю что это плохо. Пока десктопный линукс нишевой продукт, пока он пролетает под радарами крупных игроков на нем можно нормально жить. Меньше малвари, меньше шпионского говна, меньше внимания.
А убогое и глючное ГУИ, ну что делать, за мои 15+ лет с линуксом уже привык и получаю удовольствие. Стокгольмский синдром видимо.
Автор а теперь пожалуйста тоже самое про Книги/Фильмы/Шахматы
Ну так любой нужный кому-то инструмент делается во множестве вариантов. У всех свои сценарии использования, все фокусируются на своих сильных сторонах.
Ну и учитывайте что курл это огромная куча сетевых протоколов, тогда как почти всем нужно только http/https
И httpie
Ну так а обычные ошибки как раз предназначены чтобы их кидали, и кидали при необходимости много. Тот же strconv может кинуть ошибку, и если моя программа выбирает числа из тонны мусора то и ошибки там будут сыпаться как из рога изобилия.
вот этот пример максимально нердужелюбен к код ревью. Потому в дифе будет например\
и читающему изменения в коде покажется что первая ошибка не обрабатывается, и чтобы проверить так ли это придётся лезть дальше в код. В общем предложение выглядит максимально странно и мне кажется лишь породит больше скрытых проблем.
Йнженера Гарина гипербодойд!
И произносят его тоже через и краткое? Я вот ни разу не слышал что его так произносили в отличие от бойлера и спойлера.
занимающйхся