Перейти к контенту
Dennis_Chikin

Рефакторинг

Рекомендуемые сообщения

Повешу это здесь сразу, чтобы иметь перед глазами постоянное напоминание.

 

Как я это представляю, кроме введения и обсуждений в формате "все ни о чем":

 

Создается паралельно более специализированная тема, типа "динамическое подключение функций" (это если вопрос достаточно синкретичен), или "нетпакеты", или "таймеры", или вот прямо конкретно "_g.script".

А здесь черкается заметочка.

 

"Все ни о чем" обсуждаем прямо здесь.

Ссылка на комментарий

Я бы создал эти отдельные темы, и либо сделал им всем тег "Рефакторинг" (что не очень продуктивно, пожалуй), либо дал бы всем префикс [Рефакторинг]. Или скомбинировал бы оба варианта, на усмотрение.


Подарки

  • 2
  • 2
  • 3
  • Ссылка на комментарий

    Тема "нетпакеты". Пока только скрипт с выдранным из amk и заоптимизированным по скорости.

     

    Не нужно так переименовывать. Здесь ссылки достаточно. Ну или тэг.

     

    _g.script

    Просто гравипушка и поправка/альтернатива

    Таймеры. И сон.

    Изменено пользователем Dennis_Chikin
    • Полезно 1
    Ссылка на комментарий

    По тому что тема более обширная. Просто там сейчас всего одна статья. Что, будем после каждого поста переименовывать ?

    Ссылка на комментарий

    Гм... Вообще-то не вижу какого-то особого энтузиазма. Скорее - "ну что там этот идиот опять награфоманил" - если вообще хоть кто-то в раздел еще заглядывает.

     

    Впрочем, преимущество ситуации как раз в том, что можно графоманить без оглядки.

    Мда, знали бы вы, как меня с этой солянкой достало, когда что-то написал, отладил, и даже работает, но  только у меня. А просить попробовать кого-то другого - надо опять откатывать под древние уежища, возвращая кучу только-что вычищенного индокитайского мусора, и не факт,  что получится.

    А уж что там куда навертели во всяких прочих ооп и  дмх - вообще неизвестно. 20 вариантов отката назад, в меловой период, причем в стиле угадайки.

     

    И вообще все эти правки и "адаптации", когда меняется ради 10 строк чего-то нового 20 других скриптов в 20 местах каждый, непонятно зачем...

    Но, ведь, блин, всем нравится и всех устраивает.

    Не понимаю...

     

     

    Мда, а что я сказать-то хотел ?

    Ну, вот так вот и получается - параллельно и перпендикулярно, с взаимными кросс-отсылками.

    Все равно по одному скриптику править не получится - где-то придется и с глобальной заменой.

    Сохранять древний апи или мистическую "совместимость" смысла не вижу.

    И то, и другое надо заново делать.

    Изменено пользователем Dennis_Chikin
    Ссылка на комментарий

    Возможно, просто никто и не думает подходить к этому вопросу системно. Может, масштабы пугают. Но при этом почему-то не пугает то, что объемы пост-работы в итоге получаются еще больше. Наверное, надеются на авось.

    Плюс авторитет давит. Ну а как же! Скрипты ТАКИХ МАСТЕРОВ, там все по умолчанию правильно! GSC!!! AMK!!!


    Подарки

  • 3
  • 2
  • Ссылка на комментарий

    Сохранять древний апи или мистическую "совместимость" смысла не вижу.

    И то, и другое надо заново делать.

    Рефакторинг - это как раз "оставлять древний апи" и "мистическую совместимость". Если этого нет - это переписывание заново. И если в рефакторинге какой-то смысл есть, еще в одном фреймворке смысла нет.

     

    Уже переписано достаточно много всего, а главного так и у не увидел. Что именно переписывается: оригинальные скрипты, амк, солянка? Под какую версию сталкера? Определиться с целью рефакторинга: новая это будет система или улучшение старой? Может это будет своеобразным эталоном и учебником для скриптеров? И тому подобное.

     

    По-хорошему надо завести проект на гитхабе. Выложить туда оригинальные скрипты и уже после этого рефакторить. Причем принципиально важно, чтобы можно было взять коммит, скопировать в геймдату сталкера и игра запустилась бы.

     

    Рефакторинг делать в отдельных коммитах, оптимизации в отдельных. Для оптимизаций приводить цифры сколько был, например, апдейт актора и сколько стал.

     

    Для скриптеров принципиально видеть что было, что стало и объяснение зачем и почему поменяли.

     

    ------------------

     

    Пока же обсуждать особенно нечего: что было до этого неизвестно, зачем вообще все те функции в _g.script, может их по другим файла раскидать.

    Повторюсь нужна цель и идея, а потом уже тонны кода. Да больше работы и писанины(или даже гораааздо больше), но появляется некоторая самоценность работы. Что-то новое, чего не делали раньше :)

    Плюс авторитет давит. Ну а как же! Скрипты ТАКИХ МАСТЕРОВ, там все по умолчанию правильно! GSC!!! AMK!!!

    :) Вообще-то каждая вторая команда с больше чем одним скриптером переписывала. Переписывал Артос, переписывали ЛА, переписывали ОГСЕ, переписывали под ЧН и ЗП, Денис вон в солянке переписывал. Только результат нулевой по сути - еще одна ни с чем несовместимая загогулина, о которой никто ничего не знает. Взять тот же старинный АМК - берешь и не знаешь проблем - пишешь на форуме и чуть ли не мгновенно получаешь ответ.

     

    Делать это еще раз - сизифов труд.

    Изменено пользователем abramcumner
    • Согласен 1

    Подарки

  • Ссылка на комментарий

    Я что-то не очень понял.

     

     

     

    Рефакторинг - это как раз "оставлять древний апи" и "мистическую совместимость". Если этого нет - это переписывание заново. И если в рефакторинге какой-то смысл есть, еще в одном фреймворке смысла нет.

     

     

    Повторюсь нужна цель и идея, а потом уже тонны кода. Да больше работы и писанины(или даже гораааздо больше), но появляется некоторая самоценность работы. Что-то новое, чего не делали раньше

     

    Тут нет противоречия?


    Подарки

  • 3
  • 2
  • Ссылка на комментарий

    @Murarius,

    я не вижу.

     

    Новое из второй цитаты - это не новый код, а новая идея: переписать и улучшить скрипты так, чтобы можно было подставить в существующие моды и ничего не сломалось :) Что и является рефакторингом по определению.


    Подарки

  • Ссылка на комментарий

    DC занимается, на мой взгляд, реинжинирингом. Рефакторинг нужен для читаемости кода, я не считаю, что там должна быть "новая идея".

    Создание шреймворков конечно круто, но в разрезе игр - дело неблагодарное. Такие вещи пишутся самими разрабами, что мы и видим. Хотя крутое апи для логики можно запилить.

    Кстати, гит - тема. На худой конец - свн, хотя нет, гит лучше для таких "проектов".

    ТЧ 1.0004. SAP и Trans mod

    github

    Ссылка на комментарий

    2abramcumner: Мы все умрем, да !

    И про то, что у каждого свои видЕния и привидения - спасибо, Кэп, я помню.

     

    Вот только совместимости ни какой реально ни где нет. Ни по сэйвам, ни по апи, ни по чему вообще.

    Есть набор странных ритуалов, типа изменил где-то одну строку - измени еще 50 скриптов в 50 местах.

    И НИ по каждому чиху. Добавил непися, убрал непися, добавил ствол, убрал ствол, спилил мушку - НИ.

     

    Хотя в действительности 99.9% НИ обязаны все тому же ритуалу.

     

    И, да, Артосокод мне тоже нравится. Студентам давать хорошо, ибо "солдат, который ни чем не занят..."

    Вот только kee\/\/1_hAcckePssKaIY-aaЯ запись имен переменных и функций... Э-эээ, несколько печалит. А опечаток и неумышляемых результатов копипасты при этом - не так чтоб уж ну очень сильно меньше, чем у меня.

    В общем, кто бы собрал, опубликовал, разложил и объяснил. Чтоб пол жизни не ушло на вникание. И чтоб потом все трижды не проклять, пытаясь дописывать.

    Ну и с инкапсуляцией - все-таки перебор, да. Перебор.

    А так - все в нем здорово, можно издаваться, аки Дийкстре. Кроме шуток.

     

    Да, гитхуб - идя, конечно, хорошая. Кто-б занялся... А свина - таки фффтопку. Ибо опыт - крайне негативный.

     

    И, конечно, да - мы все умрем !

    Изменено пользователем Dennis_Chikin
    • Согласен 1
    Ссылка на комментарий

    @abramcumner, ну например я использую коды 12 симбиона весьма активно, я плохо понимаю в программировании, но как-то складывается со временем так, что улавливаю ход мыслей Artos'a и уже дергаю эту оптимизацию/систему/модуль себе (ну и дописываю/переписываю по мере надобности). И на счет ЛА, там отчетливо штрихи Artos'a видны, тем более он сам по поводу этого высказывался, так что я бы о ЛА не говорил.

     

    О неиспользовании этого всего, я думаю что собирается команда, ставятся задачи которые надо в сроки выполнить, и не суть как, но ты должен сделать, а когда начинаешь говорить, что прежде чем писать какие-то скрипты нужно ввести несколько вспомогательных систем, переписать особо кривые моменты в скриптах, что например для меня тоже дело не одного дня. А остальных это не заботит, по какой причине я не знаю, может время, может желание, может навыки. Я вот например уже без ивентов тех же работать не могу, очень мощная и функциональная система, да и скрипты адаптируются всего-лишь добавлением поля в таблицу.

     

    На счет трудности понимания венгерки согласен с Денисом. По моему он единственный из известных, кто на ней пишет. Еще один из минусов мне кажется это повальный вывод данных в конфиги, хоть конечно и грузится на старте, но я все-же привык городить килотонные таблицы в скриптах напрямую.

     

    По сути НИ зачастую зависит от пересбора all.spawn, либо от каких-то непоправимых квестовых косяков с сопутствующей потерей сейвов. От all.spawn можно вполне отказаться, если написать парсер путей из конфигов, да я понимаю кое-что без него не задать, но в общем и целом незадачливые модмейкеры исправляют кривые координаты путей, вот эту проблему то и можно решить.

    Делать это еще раз - сизифов труд.

    В точку сказано, у меня в свое время был выбор чьими кодами пользоваться, Artos'a или malandrinus'a; выбрал первое, так как и функционал пошире, и позаковырестее все написано :) Самому это все делать конечно можно, но долго, да и зачем? Когда уже все есть давно...

    Изменено пользователем Карлан
    Ссылка на комментарий

    Карлан, кстати, спасибо: я понял, в каких примерно случаях нужен стиль написания кода Артоса.

    Вот мне реально в тех же ивинтах разбираться лениво, по тому что не нужны, и с плоским работать проще - когда все перед глазами. А для кого-то - действительно нужный инструмент, время экономящий. И оверхед при этом - не так страшен.

    Ссылка на комментарий

    Можно и плоское написать, мне вот классом нравится (удобнее). Оверхед я думаю небольшой, хотя специально не замерял, но тем не менее и в примитиве встречаются такие случаи, где код работает раза в два дольше, чем стандартная функция (тот-же table.insert), если я правильно понял о чем ты.

     

    У меня и в ивентах все перед глазами, я не знаю чем тебе они не понравились.

    Ссылка на комментарий

    Объясните мне пожалуйста вот эту шайтан-конструкцию, а то я никак прикола не пойму:

    --' Сохраняем уровень сложности
    if save_treasure_manager == true then
    packet:w_u8(level.get_game_difficulty() + 128)
    else
    packet:w_u8(level.get_game_difficulty())
    end
    --' Загружаем уровень сложности
    local game_difficulty = reader:r_u8()
    
    
    local load_treasure_manager = false      
    if game_difficulty >= 128 then           
    game_difficulty = game_difficulty - 128
    load_treasure_manager = true           
    end 

    Собственно спрашивается, а нафига 128 прибавлять/вычитать, когда можно просто уровень хранить? Или тут какой-то подвох, которого я не разглядел?

     
    Ссылка на комментарий

    Правда, зачем этот флажок - ни кто не знает, но все продолжают сохранять. Даже я, переписав форматы всех сэйвов, вдребезги и пополам, у себя его зачем-то оставил.

    • Согласен 1
    • Полезно 1
    Ссылка на комментарий

    Разве это не менеджер тайников? Просто он отключаемый из скриптов (для тестов или еще чего). А может быть есть такая ситуация, когда в сейве нету этого флага, тогда якобы чтение тайников приведет к ошибке.

    Изменено пользователем Desertir

    ТЧ 1.0004. SAP и Trans mod

    github

    Ссылка на комментарий

    Он самый.

     

    А вот смысл этого действа... Вот что-то типа такого:

        local treasure_mgr
        local dfcy = pk:r_u8()    -- Загружаем уровень сложности
        if dfcy >= 128 then
            dfcy = dfcy - 128
            treasure_mgr = true
        end
    еще что-то грузится...
        if treasure_mgr then
            treasure_manager.init()
            treasure_manager.load( pk )
        end

    грузится список тайников с метками. Которые снимаются, когда актор в тайник заглянул. Ну и зачем ? При этом в модах сверху понаворочено еще по стописят скриптов, которые тоже что-то делают с этими тайниками и метками.

    Итоговый вывод - рудимент. В смысле, вообще весь скрипт.

     

    Всю информацию о тайниках следует хранить в самих тайниках.

    Изменено пользователем Dennis_Chikin
    Ссылка на комментарий

    Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

    Комментарии могут оставлять только зарегистрированные пользователи

    Создать аккаунт

    Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

    Зарегистрировать новый аккаунт

    Войти

    Есть аккаунт? Войти.

    Войти
    • Недавно просматривали   0 пользователей

      Ни один зарегистрированный пользователь не просматривает эту страницу.

    AMK-Team.ru

    ×
    ×
    • Создать...