Late News: Replit Paid Subscription / Good SW Development Habits

Replit Yearly Paid Subscription

I subscribed because I felt the need to try out an AI programming tool, and it was on Black Friday sale until December 1st.

I chose this because I don't have a decent computer,

• Run and check results in the browser without needing to install compilers or interpreters locally.
• Learn programming without worrying about environment settings.
• Collaborative coding projects. (If I share a link, we can do pair programming together) - Anyone can join if needed.
• Rapid prototyping and testing of code.
• Teach coding to students in an interactive way.
• Hosting lightweight web applications or APIs.

I should make a video about this in the future. Replit

Looking at the World (Various News)

Economy

2024-11-29 (Fri) Morning Routine (Hankyung) : South Korea's interest rate cut from 3.25% to 3.0% / Increasing income disparity, decreasing consumption / X-ble Shoulder (wearable robot) / Conditional ETF 20% smooth sailing (Foreigners are buying it)

>> Ultimately, if foreigners don't buy, there's no way for stock prices to rise.

IT

Reference Link1, Reference Link2

10 Habits to Become a Better Developer

>> Exactly what I felt while building and maintaining the telematics/cluster platform, but I couldn't put it into practice properly. I shouldn't be afraid of change, and if I break it down like this, it seems possible.

Original article: Korean, English

1. Keep commits small, to the point where you might think, "Can I really make it this small?"
You never know when you'll need to revert specific changes. Knowing the exact location of a bug that occurred 6 days ago and being able to revert only that commit without complex merge conflicts is a huge relief. My standard is simple: if the code compiles, I can commit it.

2. Follow Kent Beck's maxim: "To make the change you want, first make that change easy (Caution: This can be difficult), and then make the easy change."

"To make the change you want, first make that change easy (Caution: This can be difficult), and then make the easy change."
Make sure that more than half of your total commits are refactoring. Continuous refactoring means finding and applying improvements that can be done within 10 minutes. These small improvements will allow you to solve large requirements later with simple changes. Large-scale refactoring should be avoided.

3. All code is debt.
Undeployed code is debt of debts. You need to check if the code works properly and at least doesn't break other functions. Tests give you confidence, and production deployment provides verification. Frequent deployments may slightly increase hosting costs, but it's worth it to know that your last task was real progress. One of the Agile principles is that "working software is the primary measure of progress." Here, the words 'working' and 'progress' have a crucial meaning, so I've defined them in my own way. 'Working' means deployable level, and if it contributes to a function, it is 'progress'.

4. Ask yourself if you're testing the framework's functionality. If so, don't.
The framework has already been tested by people far more professional than you, and you should trust that the useState() hook works as intended. Keeping components small means that the framework handles most of the core tasks, so many tests aren't necessary. As components grow, complexity increases, and you need to write more tests.

5. If a particular function doesn't fit anywhere, create a new module (or class or component) and find the right place for it later.
It's better to create a new, independent structure than to force it into a place where it doesn't feel right. Even in the worst case, remaining an independent module isn't that bad.

6. If you don't know what an API should look like, write the test first.
This forces you to think from the perspective of your "customer", which in this case is yourself. You can find cases that you wouldn't have found if you wrote the code first and then tested it. You don't need to be too dogmatic about TDD, and it's okay to work in larger units (e.g., write multiple lines of code before passing the test). The amount of failing code doesn't always have to be small. If you know what you're doing, don't let principles hinder productivity.

7. Copy-pasting is fine once.
Don't do the second duplication (i.e., the third copy). At this point, you'll have enough examples to create a good abstraction. Integration is necessary because the risk of implementations of the same function being different from each other is too high. Slightly awkward parameterization is better than implementing similar functions multiple times. If this situation happens again, improving parameters will be easier than integrating four different implementations.

8. Designs get old.
Refactoring can slow it down, but eventually, you have to change the way it works. Don't be too heartbroken when you have to discard something you cherished and were proud of in the past. You did your best at the time, and there's no need to blame yourself for not making it perfect enough to not need changes. Most of software development is about changing software. Accept it and move on. There is no perfect design, and change is the core of software development. Your ability as a developer is determined by how skillfully you can change.

9. Technical debt can be categorized into three types:
1) Those that hinder current work, 2) Those that will hinder future work, 3) Those that might hinder future work. All other classifications are subsets of these three. Minimize those in #1 and focus on #2. Don't worry about #3.

10. Testability is closely related to good design.
The inability to easily test is a signal that the design needs to be changed. Sometimes, that design might be the test design. For example, if em.getRepository(User).findOneOrFail({id}) is difficult to mock, it's better to separate that call into a separate mockable function or write a test utility that can easily mock entity manager methods. The reason tests aren't written is not because they don't want to test, but because they are difficult to test.