For me the biggest difficulty is I find it hard to read unverifiable documentation. It's like dyslexia - if I can't connect the text content with runnable code, I feel lost in 5 minutes.
So with this approach of spending 3 hours on planning without verification in code, that's too hard for me.
I agree the context compaction sounds good. But I'm not sure if an md file is good enough to carry the info from research to plan and implementation. Personally I often find the context is too complex or the problem is too big. I just open a new session to resolve a smaller, more specific problem in source code, then test and review the source code.
This is an interesting topic, but I don't think the article effectively conveys its message.
The title focuses on good and bad refactoring, but most of the content discusses good and bad design. This means that many of the bad examples are inherently bad, regardless of whether they were refactored from another version or written from scratch.
The introductory comic and the conclusion mention how to perform refactoring, but the rest of the article drifts away from this and only discusses the resulting code.
The first pitfall mentions changing the coding style, but the explanation actually addresses the problem of introducing external dependencies.
The fifth point, "understand business context," should actually be "not understanding business context."
If we perform refactoring incrementally, it's inevitable that there will be some inconsistencies during the process. Therefore, the third pitfall, "adding inconsistency," should include additional explanations.
In summary, I think the article would be more helpful if it focused more on how to perform refactoring rather than criticizing a specific piece of code.
Choosing "Hands-On Selenium WebDriver With Java" might not be ideal, not due to the book's quality, but because web UI automation represents only a fraction of the automation testing field. Even within UI automation, Selenium has become somewhat outdated.
For testers without automation foundations, I suggest learning Python and crafting short scripts for automating daily tasks. This covers the initial aspect of automation testing: 1, controlling another program through code.
This skill is very useful, even if you don't write automation tests, as it can enhance efficiency in documentation work and data analysis
Another essential skill is: 2, mastering the art of writing effective automation test cases.
The mindset for automation testing differs significantly from manual testing, requiring even experienced testers to learn. The official Cucumber tutorial is an option, even if Cucumber isn't utilized for test writing in the future. The examples in the documentation still offer universal reference value.
It seems that book requires some knowledge of Java, which might be too much for my sister as she already starts losing faith in herself...
I start thinking about preparing a small sandbox for her so she can look at it more as something fun to experiment with and showing her a few base commands she can use there...
> TDD is good for fast feedback in some domains,......
It hears like, "IDE is good for fast feedback in some domains. "
If someone saying that IDE is only suitable for GUI application but not the software he is writing, he probably means that "look at me, I am the old school tough guy." It's about the people dislike the tool but nothing about the domain.
The advantage of Vim is not faster but more abstract way to manipulate text. It build a language of text operation in higher level, which make you faster.
Image picture editor which has only concept pixel, but not sharp, mask, layer...
