S>>Встречал достаточно хороший код, который отлично тормозил.
Aё>Если не удовлетворяет требованиям по производительности- это плохой код.
А для бизнеса и нету таких требований по большему счету. Зато есть куча программахеров которые считают что производительность это все. Отсюда и битовые двиги справа вместо деления на двойку (в плюсах), метапрограммирование и еще куча подобной хрени.
Здравствуйте, __kot2, Вы писали:
__>сейчас я, например, работаю над очень крутой вещью и получаю столько, чтобы спокойно отклонять письма от рекрутеров компаний, в которых многие мечтают просто хотя бы прособеседоваться, хотя конечно же есть какие-то минусы, но мой накопленный опыт дает мне знания как можно не заниматься переделыванием компании под себя, а просто получать удовольствие
Корелляция здесь такая: чем чаще ты меняешь работу, тем она выше. Но, с другой стороны, проектом нужно заниматься какое-то н-ое время чтобы видеть все косяки и недоработки. И это не только написание кода, это и поддержка и работа с юзерами.
Резюме: хочешь расти по зарплате, чаще меняй работу (что, однако, не добавляет экспириенса как программисту).
Здравствуйте, Олег К., Вы писали:
Aё>>Если не удовлетворяет требованиям по производительности- это плохой код.
ОК>А для бизнеса и нету таких требований по большему счету. Зато есть куча программахеров которые считают что производительность это все. Отсюда и битовые двиги справа вместо деления на двойку (в плюсах), метапрограммирование и еще куча подобной хрени.
Если отбрость сантименты в сторону- хорошего программиста от плохого отличает способность писать элегантный и оптимальный код. Чем больше логики не помещается в кэш процессора и больше тактов тратится на оверхед (в том числе из-за неправильно выбранного алгоритма)- тем дольше бизнес пьёт чай.
Здравствуйте, Aртём, Вы писали: Aё>Если отбрость сантименты в сторону- хорошего программиста от плохого отличает способность писать элегантный и оптимальный код. Чем больше логики не помещается в кэш процессора и больше тактов тратится на оверхед (в том числе из-за неправильно выбранного алгоритма)- тем дольше бизнес пьёт чай.
берешь код иногда какой-то опенсорсный, например. тестируешь — падает. бывает. например, x264 кодек иногда кадры битые дает. ты задаешь себе вопрос — мы сможем решать проблемы по мере поступления или вставить его в продакшен? открываешь код, смотришь. ну конкретно x264, насколько я помню, неплох.
а если это например OpenSSL, Miranda, или мыщъхвский аналайзер, как он его тут описал, то вывод — нет, мы не будем это использовать в продакшене. качество не то.
Aё>Если отбрость сантименты в сторону- хорошего программиста от плохого отличает способность писать элегантный и оптимальный код. Чем больше логики не помещается в кэш процессора и больше тактов тратится на оверхед (в том числе из-за неправильно выбранного алгоритма)- тем дольше бизнес пьёт чай.
А прикинь, можно вообще запихать весь код в мэйн() и тогда вообще не будет никакого оверхеда связанного с вызовом функций. Но это я так, утрирую. Посыл тут был другой. Во всем нужна золотая середина, если ты понимаешь о чем я.
Ну и в реальной жизни я больше как-то наблюдаю что бизнес страдает из-за нашего собрата а не пьет чай.
Здравствуйте, мыщъх, Вы писали:
М> что вы имеете против того, что сигналом к перестройке внутренних структур аллкокатора служило обращение к памяти за пределами выделенного блока?
Где гарантия того факта, что обращение к памяти за пределами выделенного блока — это преднамеренное действие программиста, а не случайный прострел по памяти?
Здравствуйте, мыщъх, Вы писали:
М>давайте так. в си нет [нормальной] поддержки массивов. malloc вообще возвращает не массив, а указатель. если это чужой malloc, то за массивом может быть пустота, обращение к которой поимеет непредсказуемые последствия. если же это наш malloc, то мы гарантируем, что за массивом то, что нужно. грубо говоря, возвращаем структуру. кстати, в этой структуре явно прописан размер. М>это _сильно_ все упрощает. теперь не нужно передавать функциям указатель на данные и размер данных. скажу больше. если у нас есть функция поиска подстроки в строке и эта строка лежит где-то в середине большого блока данных, то мы передаем указатель на начало данных. да! на начало данных. там есть структура в которой размер данных и индекс строки. М>проблема переполняющихся буферов решается сама собой, т.к. любая функция на любом уровне вложенности может проверить что она не выходит за границы буфера, ибо имеет в своем распоряжении всю необходимую инфу. типа if (scb->idx > scb->len) return -1; какие у вас возражения против кастомного аллокатора?
Мне это дело представлялось не таким заурядным, я полагал, что все обращения к памяти за границами выделенного для функции буфера каким-то хитрым прерыванием автоматически докладывались менеджеру памяти. А описанное вами больше подходит на аллокатор с дополнительным address sanitaizer, доступным (или даже принудительно используемым) для обычных функций. Пусть даже и в виде некого мета надмножества "С с аллокатором и массивами", которое генерировало абсолютно корректно работающий на всех платформах код на С (сильное утверждение), да еще и с дополнительными оптимизациями.
То, что бизнес-дяди вечно торопят с релизами и вообще всячески мешают программировать, — не новость. Обычно они очень не любят выделять людей и время на всякий рефакторинг. Видать в данном случае где-то стало совсем худо, раз они стали так бросать людей на амбразуру, не так ли?
М>реально, дешевле написать с нуля с учетом новых требований чем задрачивать воду в ступе. я категорически против рефракторинга. когда мужикам делать нечего они яйца чешут. то есть рефракторят. что дает рефракторинг? зачем он? пишите сразу правильно. или переписывайте. а рефракторить это имитировать бурную деятельность ничего не делая по существу.
Откуда такая ненависть к рефакторингу? "пишите сразу правильно" — это что за ересь такая? Никто же с сходу не набирает весь код из головы, а сначала делают какие-то минимальные реализации методов, а потом дописывают, как-то упорядочивают абстракции. А это не что иное, как рефакторинг. Расстановка пробелов — это тоже вполне себе рефакторинг, хоть и поверхностный, однако он вытекает из-за отсутствия нормальных средств (и соглашений) форматирования. Плюс тут есть такая вещь, как синдром свежего взгляда. Даже просто беглый просмотр написанного пару месяцев назад кода может запросто привести к цепочке удивительных открытий.
А вот обеспечение возможности вносить изменения и доработки в соответствии с меняющимися требованиями — так это вообще первое дело. Когда этот процесс идет с умеренной скоростью, то количество необходимых изменений должно быть минимальным. Но даже когда shit happens, и требования вообще меняются на противоположные (или просто формулируются в неожиданно четкой форме), бывает вполне возможно переиспользовать уже имеющиеся наработки.
Что касается скрытия файлов, так там вроде как была задача просто исключать "." и ".." из листинга содержимого директорий. Достаточно тривиально, не правда ли?
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, мыщъх, Вы писали:
М>реально, дешевле написать с нуля с учетом новых требований чем задрачивать воду в ступе. я категорически против рефракторинга. когда мужикам делать нечего они яйца чешут. то есть рефракторят. что дает рефракторинг? зачем он? пишите сразу правильно. или переписывайте. а рефракторить это имитировать бурную деятельность ничего не делая по существу.
Сразу видно, что ты не программист (что ты и сам в общем-то уже сказал). Рефакторинг тебе не понятен, и ты сделал вывод, что он не нужен. Это типичное проявления эффекта Даннинга — Крюгера.
Здравствуйте, uncommon, Вы писали:
U>Здравствуйте, мыщъх, Вы писали:
U> Сразу видно, что ты не программист (что ты и сам в общем-то уже сказал). U> Рефакторинг тебе не понятен, и ты сделал вывод, что он не нужен.
не хочу писать большой пост, объясняющий элементарные вещи. меня окружают два типа программистов. первый (намного более многочисленный, "новая школа", поколение Z по пелевину). их девиз: "тут не думать, тут кодить надо". второй (старая школа) может три месяца ходить вокруг компьютера и не написать ни строчки, рисуя закорючки в рабочем журнале и вынашивая дизайн в голове.
второй тип не нуждается в рефракторинге. второй тип зачастую старше, чем индустрия программирования (старички по восемьдесят лет мне встречаются). многие пришли в программирование из инженерных областей. разрабатывали авионику или автомобили. или просто сан-узлы. посмотрел бы я на вас как вы будете сан-узел рефракторить, не говоря уже об автомобилях.
кроме того, если какой-то узел (или модуль программы) хочется отрефракторить, то, возможно, подумав еще немного, его можно выкинуть и заменить другим -- с бизнес-фичами на борту. ну то есть совсем другим. скажем, у вас мультипоиск реализован через ахо-корась а вы предлагаете рабин-карпа. или вообще генерацию DFA дерева. или тут выходит швейцарский нож яры и вы понимаете, что он одним махом заменяет у вас кучу узлов.
все манагеры к рефракторингу относятся в лучшем случае как к неизбежному злу. в худшем -- отказываются понимать зачем переписывать то, что работает и за что вам платили зарплату и премию если теперь вы доказываете, что это нужно рефракторить. если уж рефракторить, то не просто чесать яйца, разгревая говны, а переписывать модули, создавая business value. манагеры это одобряют. потому что появляются новые фичи или улучшается производительность. причем, производительнось может улучшаться и за счет применения алгоритмов жадных до памяти, которые раньше реализовать не было возможности, т.к. тупо не было столько памяти у клиентов...
> Это типичное проявления эффекта Даннинга — Крюгера.
нет, это не типичное проявление. если я не программист, то это значит только одно: в job description у меня не значится написания продакшен кода. однако, я близко знаком и с теми, кто пишет такой код, и с теми, кто контролирует его написание и когда я говорю "рефракторинг не нужен", то это не мой вывод. это авторитетное мнение тех, кто руководит программистами (включая и самих программистов старой школы).
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>что дает рефракторинг? зачем он? пишите сразу правильно.
С "пишите сразу правильно" есть пара проблем Первая думаю почти всем известна и понятна: то что сегодня показалось правильным, завтра может не вписываться в новую или изменившуюся ситуацию/требования. Второе — зачастую чтобы написать "сразу правильно" нужно реально очень много продумывать — получается такой перфикционистский подход, и он конечно с одной стороны неплох, но бизнесу может быть невыгодно и просто не нужно чтобы код был весь такой сразу правильный, потому что на такой код может тратиться в разы больше времени. Ну и особенно обидно будет, когда вы вот так, чтобы написать сразу правильно, "3 месяца думали с ручкой в руках, не написав ни одной строчки кода" (как вы пишете о "старичках" в следующем посте), а потом бац и какое-то непредвиденное изменение ситуации.
Здравствуйте, мыщъх, Вы писали:
М>не хочу писать большой пост, объясняющий элементарные вещи. меня окружают два типа программистов. первый (намного более многочисленный, "новая школа", поколение Z по пелевину). их девиз: "тут не думать, тут кодить надо". второй (старая школа) может три месяца ходить вокруг компьютера и не написать ни строчки, рисуя закорючки в рабочем журнале и вынашивая дизайн в голове.
По-моему оба типа — крайность. Должен быть баланс. Думать и стараться сразу написать хорошо конечно нужно, но время на обдумывание должно быть вменяемым, а не так что можно за час придумать нормальное решение, но мы будем думать неделю чтобы написать сразу идеально и правильно. Я сейчас начинаю приходить к тому, что код должен быть гибким, как глина, и при выборе решения нужно задавать себе вопрос: если вдруг решение окажется не самым эффективным — насколько легко или сложно будет его потом переделать? Какие в данном случае будут последствия не самого оптимального решения или кода? Если исправить будет сложно — ок, надо хорошенько подумать. А если легко — не нужно убивать кучу времени, нужно просто взять и написать, а потом если что отрефакторить или переписать — это нормально.
Да и вообще, по-моему на практике (об этом кажется еще Брукс писал) на серьезных проектах редко бывает что сразу взяли и написали правильно, нужно закладывать определенную гибкость и быть готовым, что много придется переписывать или рефакторить.
Здравствуйте, мыщъх, Вы писали:
М>(старая школа) может три месяца ходить вокруг компьютера и не написать ни строчки, рисуя закорючки в рабочем журнале и вынашивая дизайн в голове.
Требования у манагера меняются каждую неделю, причём часто на противоположные. Нужно или вынашивать нетленку со скоростью света, или адаптироваться к жизненным условиям, и писать простой и расширяемый код, т.е. такой, где можно, не задумываясь, заменить один модуль на другой, а не переписываться вообще всё с нуля.
