Во многих мошеннических схемах используется очень простая и действенная идея: когда человек вкладывается во что-то, это что-то обретает для него ценность, даже если по факту это пустышка. Например, всякие фейковые опросы, где человек тратит 2 часа времени, чтобы ответить на 500 вопросов, потом в личный кабинет падает 300кк рублей, но нужно заплатить 500р "комиссии" за вывод средств. Никто никогда бы не поверил в эту чушь, но когда потрачено 2 часа и кажется, что от награды отделяет самая малость... Или же человек играет в покер и проиграл уже все деньги, дом и кота, но нужно продолжать, потому что "столько проиграно, нужно отыграть".
Вчера я чуть не попался на это. Не на мошенничество, нет - я чуть не попал в упомянутую психологическую ловушку "слишком много вложил, чтобы бросить", которую сам себе и построил. Но моя история совсем не уникальна, поэтому помимо неё я собрал тут коллекцию историй и применил ORDER BY scale ASC, чтобы вы оценили: эта ловушка живёт на всех масштабах - от маленьких сиюминутных решений до целых жизней.
5 минут
Когда я устраивался на работу, там был скрининг-тест на 5 вопросов. И один вопрос был "напишите регулярное выражение для ip-адреса". Там не было никакого подвоха, можно было хоть со stackoverflow скопировать (если найдёте хорошее решение). Недавно мы обсуждали это задание с СЕО и я рассказал, как решал его.
Я подумал, что ip-адрес - это повторяющаяся группа вида xxx.. Понятно, что на число xxx есть ограничения, но в целом это 4 группы, только последняя без точки. Поэтому я пытался написать эту группу и указать, что у неё 4 повторения, но вот тут в конце есть исключение.
И я залип. Написать правило в регекспе достаточно легко, а вот добавить исключение - сложно, по крайней мере для меня. Я пробовал так и этак, а потом просто плюнул и написал самый тупой вариант, какой приходил мне в голову, без попыток что-то сгруппировать и быть умнее, чем я есть на самом деле.
Тест я прошёл.
Эта история очень понравилась СЕО и он даже попросил записать её, а я недоумевал: что прикольного в том, что я написал тупейшую, постыдную регулярку, когда шёл на senior позицию?
Сейчас я вижу. Я потратил минут 5 на этот групповой секс вариант с группами, но мне хватило мозгов отказаться от этой затеи и потом сразу написать решение за 10 секунд. Это было не сложно, ведь 5 минут размышлений - не такая уж и большая потеря. Давайте что-нибудь помасштабнее.
6 часов
Случилось прям на днях и послужило причиной для статьи.
Клиент попросил добавить с десяток полей в ORM модель (== добавить колонок в одну табличку БД). Я слабо разбирался в кодовой базе и не видел всей картины, и я знал, что когда-нибудь потом клиент опять захочет добавить ещё колонок, а потом ещё. Поэтому я решил сделать небольшой рефакторинг и дать клиенту возможность самому добавлять колонки, этакий Entity-Attribute-Value замутить. Это надо было сделать так с самого начала, но не сделали, и я решил, что сейчас слегка отрефакторю всё это.
Я успешно переделал схему БД. Потом мне пришлось менять код бэкенда, забирающий данные из БД. Потом я пошёл на фронт и поменял javascript код, чтобы он правильно отправлял и принимал новый тип данных. Это было примерно в моих планах, и я укладывался в свой график. Но потом что-то пошло не так.
Я увидел, что часть данных забираются не через ORM запросы: в базе данных был специальный view, который агрегировал данные (считал какую-то статистику, возвращал самые актуальные данные). Пришлось перелопачивать и его.
А потом я увидел, что есть ещё функция вывода статистики, которая достаточно большая, и так как она не была заточена под новую структуру данных, то нужно было рефакторить и её тоже.
И я бы отрефакторил. По моим оценкам, оставалось работы на 1-2 часа, но я посмотрел, что у меня получилось: я потратил кучу времени, в трёх местах костыли, а я не уверен на 100%, что не всплывёт что-то ещё. И хотя конец задачи был уже виден и я вот уже почти всё сделал, но звоночки были - я уже несколько часов "вот уже почти всё сделал". Ну и я бросил эту идею. Сделал git checkout master && git checkout -b second-attempt и начал заново.
Теперь я знал код, знал, что меня ждёт, и я сделал так тупо, как только мог: я просто добавил колонки в базу данных и копипастом добавил их во все места кода. Рефакторинг провалился, но это был контролируемый провал: я променял гипотетическое улучшение кода на вовремя закрытую задачу, пусть даже решение было не самым красивым.
2 недели
Эх, Фил... Человек тоже начал с рефакторинга, но плюнул на все звоночки и решил биться до победного, отрефакторив вообще всё, до чего мог дотянуться. В итоге 2 недели кранча и выгорания, хотя где-то в конце первой нужно было плюнуть на всё и начать заново, как бы ни жалко было потраченного времени. Хотя бы в барах смог посидеть.
В итоге ему повезло, и почти ничего не сломалось после рефакторинга, но это больше похоже на чудо. В битве "неконтролируемая победа" vs "контролируемое поражение" я бы выбрал последнее.
2 месяца
Был у меня клиент, мы пилили приложение с нуля. Сначала ему просто нужно было автоматизировать рутину, этому я ему сказал "окей, запустим забесплатно на AWS lambda", что мы и сделали. Потом клиенту понадобилось хранить состояние, и я присобачил dynamodb. Потом понадобилось выводить таблички и формочки в html, и я добавил туда какой-то шаблонизатор и самодельную админку.
А потом я сказал, что если мы сейчас не сожжём это всё к чертям и не перепишем всё с нуля, то это превратится в неуправляемое адище. К чести клиента, он полностью осознал это. Проект рос, требования менялись, и то, что подходило нам в начале пути, совершенно не годилось теперь.
Мы выкинули весь код и начали заново.
И оно получилось. Да, мне пришлось всё переписывать, но я уже знал, что нужно бизнесу, и писал именно под новые требования. Мы потеряли время на этот "откат", но зато стали двигаться вперёд быстрее.
3 года
На одного работодателя я работал около 1.5 года. Это был стартап, что-то, что не делал почти никто, так что мы в какой-то степени были первооткрывателями. У работодателя были какие-то соображения по поводу того, какие использовать алгоритмы, чтобы всё заработало, а потом и я привнёс свои идеи. Мы всё реализовали, но оно работало недостаточно хорошо. Потом мы с полгода делали всякие улучшения, экспериментировали, тестировали идеи, устраивали мозговые штурмы... Оно не взлетало, ну прям никак не дотягивало до нужных значений. И тогда я сказал:
А босс туда вложил 2 года жизни и туеву хучу денег. Он просто не мог это бросить, потому что это уже стало частью его жизни. И хотя у него были и другие проекты в зачаточной стадии, но он их даже не рассматривал. Он стал частью корабля, если вы понимаете, о чём я. Я ушёл оттуда, и вот спустя год я радуюсь хорошей работе, а на старой всё ещё продолжается какая-то вялая движуха, с затишьями в пару месяцев.
40 лет
А бывают и большие сроки, к сожалению.
Бывает, что кто-то изобретает вещь, как ему кажется, революционную, и вкладывает в неё душу - этакий крестраж. Он развивает идею и 40 лет примеряет её то здесь, то там, и даже обучает ей других по воскресеньям в 10 утра. Потом он постит её на Хабр и ему все говорят, что это просто провал. Будь это вы, стали бы вы сомневаться в какой-то концепции, если живёте с ней 40 лет и даже применяете её в жизни? Да хрена с два!
Легко бросить что-то, если вы потратили на это 5 минут. Возможно бросить что-то, если вы потратили 6 часов. Но если вы потратили 40 лет, то вы уже не видите, что бросать.
Что хотел сказать автор?
Как здорово, что мы не на уроке литературы, и автор может сказать именно то, что хотел сказать автор.
Проблема "я вложил в это слишком много времени" - глобальная, но программистам, которые в большинстве своём перфекционисты, в этом плане вдвойне тяжелей. Мы очень привязываемся к коду, он - наше детище, и отказаться от него - это что-то за гранью. Но иногда это единственно верное решение.
Мне нравится проводить аналогию с тачками. Ваша машина может быть самой красивой и быстрой - прям как код, - но всё это не важно, если вы едете по тупиковой дороге - ведь вы всё равно никуда не приедете. И если на горизонте замаячил тупик, то лучшее, что вы можете сделать - это не надеяться на чудо, а как можно скорее взять свой код, сжечь его и начать заново.
Если вам не нравится, что я пишу, то не подписывайтесь на мой канал "Блог погромиста". Там ужасно.
Комментарии (98)
AspisVipera
06.02.2022 09:57+60Почему я нажал в голосовании на третий вариант?
Sdima1357
06.02.2022 10:10+22Вы нажали, потому что уже прочитали статью и потратили время... Ваш Кэп.
И я тоже нажал на третий, потому что последний вариант -последний, а два первых как правило неверные, хотя выглядят так же.
sepulkary
06.02.2022 14:34+8Я нажал на третий, потому что уже минимум двое нажали на третий, а на остальные неизвестно, нажали или там никого нет, и я окажусь в полном одиночестве, бесконечно рефлексируя горькие последствия неудачного выбора...
MinimumLaw
06.02.2022 11:14+7Число хорошее. Всегда есть три богатыря, три девицы под окном, три попытки...
В конце концов двоим скучно, а четверо неизбежно бьются на пары.
Да, из статьи прочитал только вводку. Остальное и так понятно. А вот результаты голосовалки захотелось посмотреть. И ради этого даже кликнул. На троечку, естественно.
Xobotun
06.02.2022 12:36Я был огорчён, когда выбрал все варианты, кроме третьего. А он был в два раза больше остальных. (голоса 29, 31, 61 и 29, то есть 23%, 25%, 49% и 23%)
По сути статьи – регулярно сталкиваюсь с подобными вещами, и умение вовремя отступить сильно помогает. Правда, для этого надо иметь более простой "план Б", на который можно быстро переключиться и быстро сделать, если крутой и навороченный "план А" занял больше отмеренного на него времени.
И это действует не только в программировании, но и в куче других сфер, что радует. Правда, силы воли не всегда хватает что-то быстро прекратить... :D
Sabin
06.02.2022 15:17+2Я нажал на 3 просто потому что люблю это число и, если для меня нет видимой разницы, почти всегда выбираю этот вариант
Revertis
06.02.2022 16:33+1Интересно, почему 51% людей любит это число? Я, как программист, обычно в магазине беру всё по 2/4, в крайнем случае шесть экземпляров :))
beerchaser
07.02.2022 09:00+1Это сантехническое:) 1/2" - самая ходовая в домашней разводке... и шесть экземпляров оттуда же: один сломается, один потеряется, один сосед выпросит, у одного резьба не подойдет, один в запас. так, что шесть - это впритирку...
vectorplus
06.02.2022 22:46+4Я нажал на третий вариант по очень простой причине. Из многих вариантов при прочих равных я отбрасываю первый и последний. Остаются второй и третий. Из двух вариантов при прочих равных я выбираю второй. Все, алгоритм в два прохода при n = 4
ITMatika
07.02.2022 11:26Я прочитал пару абзацев по диагонали, занёс мышь над 3-м вариантом, потом подумал, что это слишком банально и наверняка 3-й победит, а меньше всего голосов будет за 2-й, щёлкнул на 2-м. Мне больше интересно, какой всё-таки вариант в итоге проиграет.
Racheengel
06.02.2022 10:54+20Имхо надо иметь одно важное понимание: если ты наемный работник, то продукт ТЕБЕ не принадлежит. И код тоже НЕ ТВОЙ. Поэтому решение надо принимать, руководствуясь тем, готов ли ВЛАДЕЛЕЦ оплатить время и затраты на рефакторинг, а не бросаться с головой в омут. Для этого надо САМОМУ понять глубину кроличьей норы, прежде чем лезть за ЧУЖИМ кроликом. А потом обсудить с хозяином время и бюджет. И только потом копать.
Рефакторинг такая же работа для тебя, как и добавление новой фичи. Для хозяина - нет. Он должен понять, что это необходимо ему и ЕГО продукту.
Со своим личным проектом, конечно, всё проще - ты сам себе хозяин кролика. А кролика надо любить и ухаживать за ним, чтобы не умер с голоду или от ожирения :)
Ndochp
06.02.2022 15:39+4Делать красиво или копипастить говно вызывает разные чувства. Но конечно дядя, который платит должен быть в курсе, за что он платит.
Хотя иногда рефакторинг + задача стоит столько же по времени, сколько задача. Тогда можно просто оценить задачу и не вдаваться в подробности, если этого не требуют.
oOKIBrTlUTohw4Sc
06.02.2022 22:15+8Ага, да, мы все живем в идеальном мире. Вот если бы у меня спросили как правильно - я б один в один как вы рассказал, заказчик, задачу нужно обсудить, то се... Я даже не буду говорить про то, как это донести заказчику, и если человек нетехнический, то давайте будем честны, вы можете хоть 10000 часов потратить на обсуждение - но все равно решение будет ваше. Скажете ему что вот вообще дальше никак не полетим, это предел текущей архитектуры и что ему останется? (вариант когда он шлет вас нафиг и ищет того кто согласится - пока оставим в стороне). Другими словами вы можете своими аргументами манипулировать мнением и решением заказчика.
Осознаем что спихнуть ответсвенность на клиента не получится. И вот тут оказывается что оценить, а нужен ли рефакторинг просто невозможно. Потому что мы не можем предсказывать будущее это раз, можно запросто промахнуться со сроками, провалить демо, неполучить инвестиций и все, досвидания. Может оказаться что вы ошиблись и стало только хуже. Или рефакторинг не стоил того, пока вы переписывали, появилась новая идея и теперь этот код вообще нужно выкинуть.
Но есть и в дргую сторону аргументы. Иногда плохой код замедляет работу гораздо сильнее, чем это кажется стороннему наблюдателю. Потому что все мы люди и мало кому хочется работать с говном, что как бы явно не положительным образом сказывается на продуктивности. Этого даже программист может не замечать, спихивая все на лень.
А если оценить еще в больших масштабах, например проблемы с наймом новых сотрудников, ведь никто не хочет работать с легаси, то количество переменных начинает просто зашкаливать...
Поэтому мне конечно нравятся, как тут многие прагматично рассуждают на эту тему, но мне не сильно понятно, как все их логичные аргументы обрабатывают а) невозможность предсказать будущее б) слишком высокий уровень субъективности при оценке "пора-не пора рефакторить".
hostclubkea
07.02.2022 03:16Все таки код принадлежит команде разработчиков, владелец обычно не имеет знаний про то как качество текущего кода влияет на скорость и надежность разработки, поэтому команде разработчиков придётся платить технический долг. Да конечно есть разные подходы как делать рефакторинг - как часть фичи или потом отдельно, но как бы то ни было это делать придется и иногда придётся даже лукавить владельцу если вам не все равно какое качество кода вы выдаете
klirichek
07.02.2022 19:12+1Если продукт опенсорсный (и код доступен через vcs) - это инвестиция в собственную репутацию. Для этого пишутся вменяемые коммит-месседжи, для этого вообще всё затевается. Чтобы даже (если) всё не взлетит - на будущих собеседованиях ты мог показывать свой реальный ход мысли в этом реальном проекте.
А если взлетит - это инвестиция самому себе. Потому что когда-то придётся разбирать старое легаси, и описания решений, где бы они не были, очень помогут!
KvanTTT
07.02.2022 20:01+1Я бы добавил, что опыт работы с опенсорными проеками дает и хороший буст в коммуникациях, особенно если вы вносите довольно крупные изменения и вам нужно обосновывать их значимость. Мне несколько раз приходилось повторять одно и то же, приводить разные аргументы, формулировать мысли по-другому, чтобы в итоге мои изменения посчитали полезными и приняли.
AllexIn
06.02.2022 11:23+32Живу в геймдев сообществе последние 20 лет. И знаете, вижу обратную ситуацию:
люди вкладывают огромные ресурсы, пишут движки, делают готовые демки игр... А потом бросают и начинаю заново новый проект.
"Алё! У тебя почти готовая игра! Допили и выкинь на рынок! Хоть какая-то отдача будет!"
Но нет. Проект задвигается и цикл повторяется.
Это что за когнитивное искажение?
chernish2
06.02.2022 12:27+24Видимо больше нравится сам процесс, чем любой результат
zuko3d
06.02.2022 15:35+2Есть одно знаятие, которым люди тоже занимаются скорее ради процесса, нежели ради результата. Но там хотя бы трудозатраты не такие большие, как в геймдеве...
oOKIBrTlUTohw4Sc
06.02.2022 22:16+8Если я правильно понял ваш намек, то в этом деле процесс без результата тоже оставляет некую неудовлетворенность, скажем так ))
alexzeed
07.02.2022 09:21+1Ну это вообще у кого как, исходный посыл был мне кажется в том, что запланированный природой результат (пресловутые две полоски :) ) не достигается, и вообще отличается от запланированного участниками результата.
Revertis
06.02.2022 13:55+5Я бы предположил, что люди просто не видят желаемого "вау-эффекта" от того, что они наваяли.
Interreto
06.02.2022 14:26+19Я пишу электронную музыку и пока начинаешь только работу над идееей трека тебя захватывает каждый такт, а когда доходит до мастеринга (слушаешь один и тот же трек 100500 раз) то тебе кажется что трек твой скучная фигня. Делаешь мастеринг и забываешь про трек на пару месяцев, а потом возвращаешься к нему и вот сразу чувствуешь то что было в начале и конечно же косяки мастеринга которые замылились в процессе мастеринга.
acc0unt
06.02.2022 14:45+41"Почти готовая игра" - это игра, готовая на 90%. А вторые 90% кто делать будет?
Так и получается. Если разработчик или команда считают, что вытянуть вторые 90% у них не выйдет, то первые 90% - мёртвый груз.
shiru8bit
06.02.2022 16:54+6Правило 80/20. Это только кажется, что почти готовая игра почти готова. Как правило, от готовности её отделяет в разы больше работы, причём рутинной и ресурсоёмкой, а также просто непонятной для компетенции разработчиков (релиз игры тоже работа, требующая совсем других талантов). Самое интересное на момент почти готовности уже сделано, а если ещё и демка показана, то основной выхлоп уже достигнут, награда получена, и перспективы более не видны. А вот вагон трудностей впереди становится уже хорошо виден.
Ну а готовность движка в контексте игр - это вообще крайне малый процент от готовности проекта. В играх начиная с 90-х годов контент преобладает над кодом в огромном непропорциональном соотношении, весь код - это пара процентов от объёма работ. И остальные работы требуют совершенно других талантов, причём очень высокого уровня, то есть это вообще не решаемо для автора движка, а получение даже высокооплачиваемой помощи через привлечение других талантов - это ещё один очень специальный скилл, совершенно не похожий на написание кода.
AllexIn
06.02.2022 17:34+3Нет. Я говорю о реальных 80% проделанной работы. Собственно те, у кого такой проблемы нет - наводняют рынок и зарабатывают на нём. Те кто не могут сделать шаг - получают кучу почти готовых проектов.
Я предполагаю что причина в боязни релиза. Что игра провалится, что игра не принесет ожидаемого результата. Ведь если не релизить - этого точно не случится.
Меня эти рассуждения заставили откопать один старый проект, который мы с другом почти сделали. Там действительно игра в состоянии "неделя работы и можно релизить". Но основной довод друга на моё предложение проект доделать сегодня: "я хочу чтобы проект был хорош, а на это у меня сейчас нет времени"shiru8bit
06.02.2022 17:58Правило 80/20 - 80 (реальных) процентов работы занимают 20 процентов времени, оставшиеся 20 (реальных) процентов работы занимают 80 процентов времени.
Те, кто наводняет рынок - едва ли зарабатывают, разве что чисто формально, больше нуля. Наводнение - это индикация низкого порога вхождения, по тем или иным причинам. Если смог наводнить один, наводнит и другой и ещё тысяча человек, а ёмкость рынка конечна, и в итоге и без того невысокий профит размазывается по множеству разработчиков. Даже очень успешные независимые разработчики не сильно-то зарабатывают, и множество студий закрывается после первого внешне успешного релиза.
AllexIn
06.02.2022 18:12Вы ошибаетесь. Те кто наводняет рынок получают стабильно свой кусок пирога. Те кто наводняет конкурируют друг с другом, но вполне себе живут. 50К долларов в месяц на одиночку вполне реальная цифра.
Вот тем кто делает хорошие игры, на этом рынке сложнее. Потому что ты всё равно вынужден плавать в море мусора и тебя в нём не видно.
Но это лирика, я не про рынок писал, а про людей.shiru8bit
06.02.2022 18:17+1Я не ошибаюсь, а транслирую свой опыт в той же области, и он значительно отличается от вашего. Я не знаю никого, кто получал бы 50K в месяц на одиночном инди проекте, включая тех, кто занимается этим десяток лет в качестве своего основного занятия. В моей реальности у большинства инди игр даже общая сумма продаж за всё время не достигает таких значений.
AllexIn
06.02.2022 19:13Я ничего не понял. Какие одиночные проекты?
Речь про "наводняют рынок". Массово заливают рынок простыми играми.
shiru8bit
06.02.2022 19:32+1Тогда это называется длинный хвост продаж - есть условная сотня плохих игр, но какие-то продажи идут, и в сумме на долгом периоде получается какая-то прибыль. С разработкой это имеет мало общего, под такие цели обычно скупают чужие проекты за копейки. Есть конечно и такие уникумы, которые могут выпускать по две игры в месяц, но это совершенно определённо не норма.
bak
06.02.2022 18:59+4Посмотрите на график ретеншена и сразу станет понятно (они не только к игрокам относятся).
На первый день проект кажется "вау бомба!", на второй "классная идея", на 7-й "прикольно". Через пол года разработки "ща блевану", "всё что угодно только не это", "я вам сам заплачу только чтобы это больше никогда не видеть".
При этом объективно игра может быть очень крутой. Для игр обладать нулевым долгосрочным ретеншеном это вообще скорее правило.
А разработка всё только усугубляет. Ты на протяжении долгого времени играешь (тестишь) недоделанную, недобаланшенную забагованную штуку. Под конец ещё и тоннельное зрение начинает добавлятся и ты вообще перестаешь понимать что круто а что нет.
engine9
06.02.2022 23:34Возможно это невротическое проявление перфекционизма, когда основная преграда для личности (точнее для деятельности) заключается в попытке защититься от болезненной, невыносимой критики, через бесконечные итерации переделывания.
svidetelj
07.02.2022 18:04+3Имхо это что-то вроде погони за журавлем в небе вместо синицы в руках.
Т.е. люди хотят сделать идеальную игру, а выходит нормальная игра. Но хочется идеальную. И нормальную выкидывают в мусорку даже не доделав. Потому что нужна идеальная.
А вся фишка в том, что идеальный результат недостижим.
anasana
06.02.2022 11:28+2Много всего вспомнилось, читая истории и ситуации из статьи.. Самый ранний опыт из двухтысячных, когда на, долгое время, успешной дружной фирме начались задержки по зарплате (сменилось законодательство, а направление деятельности фирмы не имело никакого другого даже подстраховочного продукта) и весь офис приходил просто потому что жалко потерять начисленную, но неполученную зарплату. Выплачивали мааленькими частями, при этом общий долг накапливался лавинообразно. И по сейчас, то там, то там, встречаю различные вариации добровольного якоря надежд на обещания.
Очень сильно держит хобби, особенно когда находишься в его потоке.
P.S. Выбор голосовалки напомнил ситуацию выбора ключа на антивирус).
chernish2
06.02.2022 12:28+1Я бы не стал писать регулярку на проверку маску IP, потому что явно это легче проверить иным способом.
aamonster
06.02.2022 12:42+1Может, на то и вопрос был? Ну типа если поставит минимальную разумную проверку (такую, чтобы регэксп читался) и скажет "а дальше проверяем при парсинге в бэкэнде" – значит, разумный человек.
iStyx
06.02.2022 16:57+4Да там ничего сложного (PCRE2):
^([1-9]|([1-9]\d)|(1\d\d)|(2([0-4]\d|5[0-5])))\.(?1)\.(?1)\.(?1)$
qrdl
06.02.2022 20:33+1127.0.0.1 не распарсится - надо поддерживать одиночный ноль в 2-4 октетах
iStyx
06.02.2022 20:48Да, спасибо, очепятался в первой подгруппе, вот так правильно:
^(\d|([1-9]\d)|(1\d\d)|(2([0-4]\d|5[0-5])))\.(?1)\.(?1)\.(?1)$qrdl
06.02.2022 20:55не совсем - в первом октете, мне кажется, одиночного нуля быть не может. Хотя надо RFC читать
qrdl
06.02.2022 21:29был неправ - вполне может быть 0 в любом октете
IntActment
07.02.2022 10:12Недавно писал по работе кастомный контрол для ввода IP-адреса (как просили заказчики, «чтобы как в Windows в свойствах интернет-подключения работало где ручками можно забивать адрес»), и там для первого октета есть ограничение на ввод 1-223. Так что RFC не RFC, а важно узнать, для какой задачи парсинг будет применяться.
Бонус: при исследовании поведения этого самого контрола в окне свойств подключения обнаружил баг: через копипаст в октет можно вставить число гораздо длиннее ожидаемого.
lorc
06.02.2022 21:49+401.01.01.01 является валидным адресом, но не матчится.
А ещё мало кто знает, что IP адрес можно записать одним 32-битныим числом. Попробуйте ping 2130706433
iStyx
06.02.2022 23:57+301.01.01.01 является валидным адресом, но не матчится.
Согласен, бывает, что нужно валидировать адреса, введённые людьми. Тогда так:
^(0?0?\d|(0?[1-9]\d)|(1\d\d)|(2([0-4]\d|5[0-5])))\.(?1)\.(?1)\.(?1)$А ещё мало кто знает, что IP адрес можно записать одним 32-битныим числом.
А вот тут мои полномочия всё :)
RranAmaru
07.02.2022 05:35+5127.1 тоже валидный адрес ;)
Нули в середине можно опускать. (Кстати, в ipv6 тоже так).
paluke
07.02.2022 08:42+3Ну ping похоже использует функцию inet_addr, а у нее правила парсинга довольно неожиданные. Например, части адреса, начинающиеся с 0, считаются восьмеричными. С этим иногда сюрприз случается — программист значение, введенное пользователем, передает в inet_addr(), а пользователь зачем-то добивает двузначные части адреса нулем слева и в результате обращение идет не к тому адресу, к которому ожидает пользователь.
В линуксе ping работает именно так. Под windows 7 было так же, кажется в 10 переделали.
docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-inet_addr
Gummilion
07.02.2022 05:49+3Думаю, за 10 секунд можно сделать что-то типа
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}, в большинстве случаях этого достаточно. Я бы сделал так, сказал бы, что оно пропустит и невалидные IP, и надо ли проверять на [0-255] ?
Gradiens
06.02.2022 12:32+40Пример с 2-мя месяцами - эталонный вариант успеха.
Сдалали MVP из копролитов и целлюлозы, потом поняли, что нужно, и переделали как надо.
А если бы бы сразу реализовывали как надо - все равно вышла бы ерунда под выброс. Потому что требования поменялись.
2 месяца - это не потеря. Это наработка экспртизы, это исследования, это рабочий прототип для быстрого старта, решающий сиюминутные потребности заказчика.
Это что угодно - но не потеря.
gophp
06.02.2022 21:15+1Monolith first - хорошая практика. Если с правильной архитектурой изначально зайти, не нужно будет потом с нуля все заново писать.
majstar_Zubr
06.02.2022 12:41Спасибо за статью, хорошие примеры! Ничто иное не далет проблему существенной, как подтверждение о её важности от другого лица.
Но хочется отметить некотрую недосказанность, наверное вам стоило бы рассмотреть факторы, и побольше написать о "звоночках", и например, сравнить со случаями, когда из-за медленной реализации проекта кажется, что дорога ведет в тупик, хотя на самом деле дорога идёт в гору возле локального максимума.
Так же не могу не отметить, что в конце статьи вы вмешались в ход эксперимента вашим заголовком "Мне реально интересно, какой вариант ответа выиграет в этот раз и почему". Прочитав эти строки самостоятельно и непринужденно задаешь этот вопрос себе, и поскольку он развлекательный, то первые мысли будут связаны с областью развлечений. В качестве ответа фраза "Бог любит Троицу" всплыла раньше, чем были осмотрены пункты опроса. На данный момент, не могу сказать, благодаря какому шоу или шутке эта фраза закрепилась в голове. Но перед голосованием я предположил, что третий пункт вырвется вперёд, и считаю, что именно отсутствие каких-либо распространенных шуток, связанных с числами, приведи в равномерному распределению в остальных вариантах.
amarao
06.02.2022 12:52+9В RPG за победу над бесполезным мобом дают экспу. Это вполне разумная метафора для потраченного времени. Если время было приложено по делу, но результата нет (или он ни о чём), остаётся опыт. Чем больше одного и того же моба фармишь, тем меньше опыта. Но первые мобы - это самое нажористое, от них левелы так и прут.
VIPDC
07.02.2022 10:13+1Ну так вообще можно договоириться до Дзен-будизма и философских материй. В принципе нет ничего полезного или бесполезного, важно лишь Ваше отношение к этому.
Всё ведь на самом деле в голове. Любую ситуацию автора можно развернуть на 180° и сказать, что я получил супер важный опыт который потом в жилзни мне сэкономил 1000 часов.
По сути это отношение к жизни, например:
"не опоздал на самолет, а значит мне нужно в другое место"
"не потерял 100500$ на бирже, а уберёг себя от не нужной мне траты"
"не просрал собеседование, а одна дверь заркылась 10 открылось"....
XAHOK
08.02.2022 12:36Ну так вообще можно договоириться до Дзен-будизма и философских материй.
Всего лишь до обычного рационализма, иногда в виде защитной реакции. И, иногда, болезненного рационализма, как одного из синдромов какого-либо психического заболевания.
Для Дзен-буддизма все же более характерна отстраненность и принятие случившегося как есть, а не рационализация:
Опоздал на самолет? Ну и что в этом такого.
Потерял 100500$? Это не трагедия.
Просрал собеседование? Жизнь продолжается.
PS. Но если вы видите, что рациональный флегматик бегает в истерике, и вы не в дурдоме, значит пора вырывать первую страницу паспорта и скручивать в трубочку.
count_enable
06.02.2022 14:25+12На каждое правило находятся исключения.
Джефф Хинтон упорно занимался нейронными сетями лет 30. За это время появилась куча куда более перспективных конкурентов - HMM, SVM, первые рекуррентные сети... Не то что нейронки Хинтону ничего не приносили - всё же он был полным профессоров в уважаемом универе, но он бы так и остался малоизвестным учёным из периферии, если бы не настойчивость.
Эдисон сделал несколько тысяч бесплодных экспериментов в поисках материала для нити накаливания. Годы, потраченные впустую, с точки зрения окружающих.
Десятки операционных систем, сотни человеко-лет. Выстрелили две или три. Стартапы, где выживает каждый двадцатый. Некоторым просто повезло, а некоторые просто сдались слишком рано. Умение вовремя остановиться и упорный труд с верой в себя, когда целый мир против - кто подскажет что важнее?
Знал бы прикуп, жил бы в Сочи.
VPryadchenko
06.02.2022 14:34А разве в статье было про сдаться и все бросить?
count_enable
06.02.2022 16:44Стартап. Два года потрачено. Кто может поручиться, что на третий год яростного труда он бы не выстрелил?
engine9
07.02.2022 07:21+1А может быть еще коварнее ситуация, когда делаешь в кайф и тяп-ляп а оно выстреливает. Может быть дело не в упорном труде (как в анекдоте про лошать, которая отчаянно пахала всю жизнь но так и не стала председателем колхоза), а в том что ты делаешь и на какую цель направлено усилие?
svr_91
06.02.2022 15:17Еще как следствие этого искажения (а может, не сделствие, а новое искажение) - это то, что некоторые считают, что чем больше фактов приведено ради подтверждения высказывания (или чем больше "а если" приведено против высказывания), тем это высказывание становится правдоподобнее. Но нет, на то, правдой является высказывание или нет, количество фактов никак не влияет
mvalery
06.02.2022 16:30А ведь Антонио Страдивари говорил своему брату: "Карло, завязывай с этой ерундой. Делай скрипки!". А тот всё твердил: "За шарманками будущее, за шарманками будущее..."
nos
06.02.2022 17:41+5про "сожги" - хорошо. я сам стараюсь использовать две поговорки "лошадь сдохла - слезь" и "чем ярче горят мосты за спиной тем лучше видно куда идти". они как "якоря", которые помогают бороться с конгинтивным искажением о невозвратных затратах.
vvbob
07.02.2022 00:16+4Помню, давно уже, работал в одном проекте на С, проект довольно прикольный был, с упором на производительность. Писалось все на скорую руку, и там частенько бывали проблемы с утечкой памяти и сигфолтами. В общем, я решил раз и навсегда положить этому конец, и начал ваять такую библиотеку, которая упрощала бы работу с памятью. Накатал какое-то неимоверное количество кода, прикрутил это все к проекту, начал отлаживать. В проекте появилась масса проблем, связанных уже не с выделением и освобождением памяти, а с моей этой библиотекой, проблемы росли снежным комом, и в какой-то момент я понял что я пытаюсь соорудить какой-то кривой сборщик мусора, похожий на то что есть в JVM, только намного более глючный. И вот тут мне хватило ума и здравомыслия, наступить на горло своей песне и выпилить эту хрень из проекта, вернувшись на исходные позиции. Вычистить код от утечек оказалось намного легче и быстрее чем пытаться прикрутить мою убер библиотеку.
Решение выбросить все к черту, было верным, но очень тяжелым. Рад что все-же на это решился, это мне дало ценный опыт - не надо упорствовать в продвижении по неправильному пути. Как только приходит осознание его ошибочности, лучше вернуться назад и попробовать другой маршрут, чем зайти в такие дебри, что уже назад вернуться не получится..
Daddy_Cool
07.02.2022 00:24+5Никогда не сдавайся! vs Если лошадь сдохла - слезь!
ИМХО тут задачка как предсказать будущее. Кто умнее или удачливее - тот предсказывает правильней.
Я как-то пилил некий сложный продукт - куча математики + связь с программами написанными другими людьми. В какой-то момент я уже перестал понимать как и что у меня работает (там была куча обратных связей) я был близок к тому, чтобы сделать то, что предлагал автор статьи и друзья советовали то же самое. Но... было жалко и лениво всё переделывать. Я как-то разделил всё на блоки, расписал комментарии и... оказалось, что оно вполне неплохо работает. Народ получил продукт и остался доволен.
rrrav
08.02.2022 23:15Творческие люди обречены на судьбу Сизифа. Но без них мы остались бы пещерными людьми. Кто-то все-же докатывает камень до вершины. Удалось же Максвеллу буквально из воздуха вытянуть 4 великих уравнения.
KvanTTT
07.02.2022 01:32+4Он развивает идею и 40 лет примеряет её то здесь, то там, и даже обучает ей других по воскресеньям в 10 утра.
Не знаю насчёт 40 лет, но судя по статье и комментариям, у автора либо шиза либо маразм.
icecube092
07.02.2022 01:40+3Знакомо, на прошлой неделе столкнулся со сложным функционалом, если вкратце - отправление пуша по определенным условиям. 3 дня писал код, уже покрыл все тестами, и уже когда залил код на ревью, вспомнил - лучший код это тот, которого нет. Написал аналитику и мы решили сделать намного проще (массовая рассылка), поэтому я снес все что делал и написал решение в 100 строк. Да, не идеально, но бизнес задача решена и почти никто не заметит разницы.
Shadasviar
07.02.2022 03:17+5Да, часто такое бывает, что неделю ломаешь голову над чем то, все получается криво и медленно. Тогда бросишь все это, работаешь неделю над другими задачами. А потом начнешь писать с нуля и за день получается красиво и быстро, как в учебниках. Часто мозгу чтобы придумать что то хорошее нужно сперва сделать неудачную попытку, а после нее еще и отдохнуть, переключиться на какое то время.
RranAmaru
07.02.2022 05:28+5Завел себе правило: когда начинаешь какой-то проект, в незнакомой тебе предметной области, то первая версия считается черновиком.
В черновике разрешается г-нокодить по полной, на эффективность, обработку ошибок, утечки и пр. сознательно забивается. Основной упор делается на простоту и ясность кода.
После достижения понимания о том, что и как должно работать, черновик безжалостно выкидывается и код пишется с нуля (однако, разрешается копипастить удачные фрагменты).
Если с самого начала настроится на то что код будет выкинут, то потом намного легче с ним расстаться.
engine9
07.02.2022 07:30+4Это же великое правило, облегчающее жизнь перфекциониста и прокрастинатора, достойное быть выбитым в граните:
«Зачем тянуть до последнего и делать все плохо, когда можно сразу сделать плохо и останется время переделать».
vvbob
07.02.2022 08:27+1Лишь бы не получилось так, что в момент когда пришло время выкидывать черновик и переписывать с нуля, на вас не начинают давить в плане - дедлайн (о котором вас никто на берегу даже не предупреждал, или предупреждал, но он внезапно переместился на ранние сроки) был уже позавчера, поэтому не страдай фигней - лей в прод то что есть!
В итоге черновая версия "отливается в гранит" (Ц) и остается с нами навечно. А следующий поколения разработчиков смотрят на все это с недоумением - ну как-же можно было так наговнокодить! :)
vya
07.02.2022 10:05+2А это не прототип называется? =) Тут правда бывает так, что накидаешь черновую версию, добиваешься того, чтобы дышало, а руководство:
И так сойдёт.png
gecube
07.02.2022 08:48+1Бывает, что кто-то изобретает вещь, как ему кажется, революционную, и вкладывает в неё душу - этакий крестраж. Он развивает идею и 40 лет примеряет её то здесь, то там, и даже обучает ей других по воскресеньям в 10 утра. Потом он постит её на Хабр и ему все говорят, что это просто провал. Будь это вы, стали бы вы сомневаться в какой-то концепции, если живёте с ней 40 лет и даже применяете её в жизни? Да хрена с два!
я подумал, что ссылка будет на язык ДРАКОН :-)
И оно получилось. Да, мне пришлось всё переписывать, но я уже знал, что нужно бизнесу, и писал именно под новые требования. Мы потеряли время на этот "откат", но зато стали двигаться вперёд быстрее.
все правильно, так и должно было быть. В смысле - на старте вы и клиент не видели всей картины и забахали минимально работающий прототип. В процессе - требования поменялись и на вторую итерацию уже надо все сжечь и сделать с нуля. Все ок. Это лучше, чем начать строить уберсамолет, а потом выяснить, что он сделан не так.
В целом - статья очень хорошая. Видел на хабре аналоги про тему "когда нужно фиксировать убытки" и эту самую психологическую ловушку, что "осталось еще чуть-чуть, давайте поднажмем", но, к сожалению, найти не смог
milast
07.02.2022 09:37А я сенунд 30 выбирал в голосовалке вариант ответа, но потом вспомнил суть статьи и выбрал №3.
А ведь говорят, что, в действительности, мозг уже принял решение, а мы колеблимся и наивно полагая, что у нас есть выбор и пытаемся сами принять решение. Хотя это иллюзия и решение уже принято где-то в подкорках головного мозга. Об этом, кстати, рассказывал Андрей Курпатов.
DX28
07.02.2022 09:38+1Тут главное чтобы антирефакторинг не вошел в привычку
Один раз сделали по-быстрому - только добавив колонки,
второй раз, ну потому что фичу надо было сроко, потом, третий ...
И вот вы уже в конторе второй года только и делаете что копи-пастите разрастающее ся легаси.
Когда то надо стукнуть по столу кулаком.
TokarLimadze
07.02.2022 09:4540 лет примеряет её то здесь, то там, и даже обучает ей других по воскресеньям в 10 утра.
40 лет насыщенной, полноценной, возможно, счастливой жизни, не та ли цель, который достигает соискатель?
Структурирование времени по Берну, форма игры, одно. Способно дать хороший выход, но он не главное. Конкретный результат, полученный в течение n времени, а если не получен, то бросаем, совсем другое.
Тогда уж надо перестать складывать мили и градусы.
iiwabor
07.02.2022 10:38+1Человек занимался 40 лет стартапом и вдруг все бросить - это значит выкинуть 40 лет своей жизни, признать, что все что ты делал - бесполезная хрень. Решиться на такое и сделать - это нужно иметь железную силу воли, на такое способен один и тысячи.
Я много повидал в командировках на заводах изобретателей, которые много лет пилят какую-то рационализацию или "революционный прорыв", но по факту он оказывается никому не нужным. и они продолжают его пилить, плачут, жалуются что их "гений" не понимают, денег не выделяют , изобретение не внедряют. Грустно...
AnimeSlave
08.02.2022 21:16Иногда просто не получится бросить и сжечь. Нужно сначала дойти до того момента, когда приходит понимание, что вот уже сейчас нужно бросать.
Я это понял, когда на предыдущей работе вёл один внутренний проект. Нужна была связка 1С с одной системой: своя база данных, особая структура этой базы, неинтуитивная внутреная логика этой системы, которая не ложилась на логику 1С. Опыт был занятный. Все с кем я общался по поводу такой связки говорили одно и тоже - бесполезно. Типа, будет потрачено больше времени, чем результата получится в итоге. Оказалось это почти правда. Реализовать связку возможно, но понятно это стало только после того, как первую версию связки через два года реалиации я выкинул на мороз, и начал переписывать всё с нуля, учитывая все нетривиальные решения, которые я открыл для себя в процессе написания первой версии. В тот момент меня спасало то, что работодатель вообще не интересовался процессом разработки этой связки. Это давало мне свободу реализации, и практически безграничное время на реализацию. В другой ситуации, возможно, первая версия так и осталась бы единственным вариантом реализации.
Возможно более правильно указать, что хорошо, что приходит понимание, что пара бросать и делать с нуля. И есть желание это сделать. И плохо, когда понимание не приходит, или приходит, но желания начинать с начала нет.
mwSUE
Отличные примеры когнитивного искажения, называемого "Ошибка невозвратных затрат".
Вообще люди к сожалению очень мало внимания и времени уделяют принципам по которым работет их мозг, из-за чего мы частенько страдаем от подобных когнитивных искажений.
0x4eadac43
Чаще встречал название 'sunk cost fallacy'. На вики явление называется 'Escalation of commitment'.
NookieGrey
Недавно в статье про Маска наткнулся на отссылку о "50 когнитивных искажений"
VIPDC
У этого явления много названий. Я называю его длинно "Отсутвие силы воли зафиксировать убытки".
Оно встречается по всюду. Пример из личной жизни. Машина попала в ДТП, родственник давайте отремонтируем, закажем детали. Начинает ремонт, он не идет. И вот надо бы бросить и продать как есть, закрыв ситуацию (блого по сути средства позволяли), но нет мы же деньги вложили как теперь потеряем.
Вообще очень тяжело закрыть вопрос, и зафиксировать потери (деньги, время, нервы чувства....). Это кстати одна зи причин почему люди продолжают жить друг с другом.
IgorPie
Давным давно был одесский тост про умение вовремя остановиться