Про реверс, тестирование и неудобные вопросы
Посмотрела документальный фильм о реверс-инжиниринге. Классный, суть простая - чуть больше часа про людей, которые разбирают железо, читают чужой код и пытаются понять, что у системы внутри. Но по факту фильм вообще не только про реверс - он, как мне показалось, про нежелание останавливаться на ответе «оно просто так работает».
И тут невозможно не увидеть параллель с QA. Для реверс-инженера отсутствие документации не конец исследования, а его начало. Устройство само становится источником правды. Да и в QA примерно так же: требования описывают (если они вдруг есть), как система должна работать, а сам продукт показывает, как она работает на самом деле, и вот расхождение между этими двумя версиями обычно самое интересное.
По сути, мы постоянно занимаемся маленьким реверсом, когда спрашиваем:
• что здесь происходит на самом деле?
• какие предположения зашиты внутрь?
• что будет, если пользователь сделает «неправильно»?
• где заканчивается ожидаемое поведение и начинается случайность?
• сможем ли мы починить систему, если её автор завтра исчезнет?
Последний вопрос особенно хорош. В фильме есть мысль о том, что реверс помогает восстанавливать знания, когда документация потеряна, а люди, которые всё создавали, давно ушли. И вот тут я понимаю, что это похоже не только на разработку, но и вообще на любые рабочие процессы.
Если на вопрос «почему мы делаем именно так?» отвечают «исторически сложилось», перед нами уже не процесс, а объект для реверс-инжиниринга. Остаётся изучать логи, зависимости, исключения и людей, которые знают тот самый секретный порядок действий, но нигде его не записали - у меня в операционке такое каждый день, реально!
Отдельно подумала про ИИ и вайбкодинг. Мы и так живём среди огромного количества чёрных ящиков, а теперь научились очень быстро производить новые, и если один чёрный ящик написал код, а другой его проверил, это ещё не обязательно качество. Точнее это точно вообще не про качество, часто это просто два очень уверенных чёрных ящика, которые одинаково не поняли задачу.
Поэтому чем быстрее появляются решения, тем важнее человек, который захочет снять крышку и спросить: «А мы вообще понимаем, что здесь происходит?»
Кажется, хороший тестировщик, реверс-инженер и операционщикв этом очень похожи. Они разбирают системы не ради удовольствия что-нибудь сломать, а чтобы система перестала быть магией. Неудобные вопросы здесь не придирка и не недоверие, а способ позаботиться о пользователе и о тех, кому придётся разбираться со всем этим после нас. А таких вопросов у меня много!
Посмотрела документальный фильм о реверс-инжиниринге. Классный, суть простая - чуть больше часа про людей, которые разбирают железо, читают чужой код и пытаются понять, что у системы внутри. Но по факту фильм вообще не только про реверс - он, как мне показалось, про нежелание останавливаться на ответе «оно просто так работает».
И тут невозможно не увидеть параллель с QA. Для реверс-инженера отсутствие документации не конец исследования, а его начало. Устройство само становится источником правды. Да и в QA примерно так же: требования описывают (если они вдруг есть), как система должна работать, а сам продукт показывает, как она работает на самом деле, и вот расхождение между этими двумя версиями обычно самое интересное.
По сути, мы постоянно занимаемся маленьким реверсом, когда спрашиваем:
• что здесь происходит на самом деле?
• какие предположения зашиты внутрь?
• что будет, если пользователь сделает «неправильно»?
• где заканчивается ожидаемое поведение и начинается случайность?
• сможем ли мы починить систему, если её автор завтра исчезнет?
Последний вопрос особенно хорош. В фильме есть мысль о том, что реверс помогает восстанавливать знания, когда документация потеряна, а люди, которые всё создавали, давно ушли. И вот тут я понимаю, что это похоже не только на разработку, но и вообще на любые рабочие процессы.
Если на вопрос «почему мы делаем именно так?» отвечают «исторически сложилось», перед нами уже не процесс, а объект для реверс-инжиниринга. Остаётся изучать логи, зависимости, исключения и людей, которые знают тот самый секретный порядок действий, но нигде его не записали - у меня в операционке такое каждый день, реально!
Отдельно подумала про ИИ и вайбкодинг. Мы и так живём среди огромного количества чёрных ящиков, а теперь научились очень быстро производить новые, и если один чёрный ящик написал код, а другой его проверил, это ещё не обязательно качество. Точнее это точно вообще не про качество, часто это просто два очень уверенных чёрных ящика, которые одинаково не поняли задачу.
Поэтому чем быстрее появляются решения, тем важнее человек, который захочет снять крышку и спросить: «А мы вообще понимаем, что здесь происходит?»
Кажется, хороший тестировщик, реверс-инженер и операционщикв этом очень похожи. Они разбирают системы не ради удовольствия что-нибудь сломать, а чтобы система перестала быть магией. Неудобные вопросы здесь не придирка и не недоверие, а способ позаботиться о пользователе и о тех, кому придётся разбираться со всем этим после нас. А таких вопросов у меня много!