Jump to content

DoubleX

Member
  • Content Count

    986
  • Joined

  • Last visited

  • Days Won

    9

DoubleX last won the day on September 26

DoubleX had the most liked content!

2 Followers

About DoubleX

  • Rank
    Just a nameless weakling
  • Birthday 06/14/1991

Profile Information

  • Gender
    Male

Recent Profile Visitors

10,978 profile views
  1. In a solo project, when to refactor usually has an easy, simple and small answer - When you start feeling the significant pain for a while of not doing the refactor. Actually, it's like when to clean your room when you're the only one using it - When you start feeling quite uncomfortable on your messy room for a while. But in a team project, that will be very different, at least because: 1. Different team members have different pain threshold 2. Different team members have different pain tolerance 3. Most importantly, different team members have different pain points So in this case, some kind of a previously agreed upon protocols on refactoring in the team has to be made, even though the protocol can be very vague and ambiguous. Also, on the management level, the reasons to refactor will be very different from those of the team members, because the former usually cares about effectiveness and efficiencies on the end results as a team, and rarely cares the pains that impede productivity of the latter in the process
  2. Yes, that's why I've written this: And personally, I use another model when it comes to considering refactoring on the architectural design level - building mansions, but this analogy is much, much more complicated and convoluted that, probably only those having several years of professional software engineering experiences will really fathom it. The number of stories is like the scale of the codebase, and clearly, different codebase scales demand different architectural designs. It's because, a single storey building might not need a foundation at all, while the foundations of a 10 storey building and that of a 100 storey building can be vastly different. Also, usually, the taller the building, the stricter the safety requirements and contingency plannings(like code quality requirements and exception handling standards in the codebase) will apply to it, because the risk(probability and severity of consequences) of collapse will increase as the building gets taller if nothing else changes. As the codebase scales, it's like increasing the number of stories of the building, eventually you'll have to stop and reinforce or even rebuild the entire foundations first before resuming, otherwise the building will eventually collapse. Also, it means that with the restrictions of the current technology, any codebase will always have an absolute maximum limit on its scale and the number of features it can provide, because having a 10B LoC scale codebase is as unimaginable as having a 10km tall building in the foreseeable future, even though they might eventually be the realities. So, even when the architectural designs are ideal on the current state of the codebase, one can't simply add more and more features without considering whether those architectural designs still work well with the increased codebase scale, and eventually some major refactoring involving architectural design changes have to be done. On the other hand, if each storey is modular enough(thanks to the ideal architectural design), as long as the pillar of strengths in that storey isn't damaged or even destroyed(maybe it's like the interface and the underlying core implicit assumptions of a module), reworking on a storey shouldn't affect too much on the adjacent, let alone other, stories, even though there are something like water pipes, electrical wires, air vents, etc, that are across multiple stories and even the whole building, which is like cross-cutting concerns in the codebase, that can get in the way of refactoring. However, I do think that my harvester analogy can serve the point by bringing at least the following across: 1. Not considering the importance of refactoring can lead to long term disasters, and fatal ones in some cases 2. Always refactoring when the codebase has less-than-ideal code qualities is usually sub-optimal on the effectiveness and efficiency of pumping out features 3. Deciding when to refactor should be calculated on a case-by-case basis, and all the relevant factors should be considered 4. Sometimes one has to sacrifice the long term for a short time to ensure the short term crisis will be solved well enough And perhaps, the most important point is that, the productivity of adding new features in the codebase will rarely be linear across the development lifecycles :)
  3. DoubleX

    DoubleX_RMMZ_TPBS_CTB

    Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 1000): * 1. You no longer have to edit the value of * DoubleX_RMMZ.TPBS_CTB.PLUGIN_NAME when changing this plugin file * name
  4. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 1000): * 1. You no longer have to edit the value of * DoubleX_RMMZ.TPBS_Battle_Turns.PLUGIN_NAME when changing this * plugin file name
  5. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 1000): * 1. You no longer have to edit the value of * DoubleX_RMMZ.TPBS_Actor_Hotkeys.PLUGIN_NAME when changing this * plugin file name
  6. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0900): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Targeting_Hotkeys.PLUGIN_NAME when changing this * plugin file name
  7. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0800): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Script_Call_Hotkeys.PLUGIN_NAME when changing this * plugin file name
  8. DoubleX

    DoubleX_RMMZ_Plugin_Query

    Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0700): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Plugin_Query.PLUGIN_NAME when changing this plugin * file name
  9. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0700): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Custom_Script_Calls.PLUGIN_NAME when changing this * plugin file name
  10. DoubleX

    DoubleX_RMMZ_Custom_Key_Maps

    Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0600): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Custom_Key_Maps.PLUGIN_NAME when changing this plugin * file name
  11. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0400): * 1. You no longer have to edit the value of * DoubleX_RMMZ.TPBS_Configurations_Edit.PLUGIN_NAME when changing * this plugin file name
  12. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0400): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Auto_Battle_Command.PLUGIN_NAME when changing this * plugin file name
  13. DoubleX

    DoubleX RMMZ Targeting AI

    Updates * { codebase: "1.1.0", plugin: "v1.01b" }(2020 Dec 2 GMT 0400): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Targeting_AI.PLUGIN_NAME when changing this plugin * file name
  14. DoubleX

    DoubleX RMMZ State Triggers

    Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0400): * 1. You no longer have to edit the value of * DoubleX_RMMZ.State_Triggers.PLUGIN_NAME when changing this plugin * file name
  15. Updates * { codebase: "1.1.0", plugin: "v1.00b" }(2020 Dec 2 GMT 0300): * 1. You no longer have to edit the value of * DoubleX_RMMZ.Skill_Item_Triggers.PLUGIN_NAME when changing this * plugin file name
×