I have been on both sides. Sometimes people are amazed at our project grounding up from zero so soon, and some other times people are questioning why our project progress is that slow. It was said that compiled/strong-typed languages were faster at runtime, but slower to code. While it is true to a certain degree, it rarely matters in commercial applications. There was also a common belief that enforcing code qualities by means of TDD/Code review/testing-in-general would increase the time to launch.

注解是元编程的一种。元编程从字面意思上说就是编写程序的程序。和普通编程一样，注解在给我们带来便捷的同时，如果使用不当，也有可能造成可读性、可维护性下降等问题。 在某些注解中，可能有很多配置项，比如： //这还不是一个特别夸张的例子 @CircuitBreaker(timeout=0.05, failCounter=1, successCounter=1, fallback="App\Service\UserService::searchFallback") 如果我们的代码里用很多这样复杂的注解，就会引发以下几个问题： 注解中可使用的数据类型表达能力有限，比如必须用方法的字符串全名来表达方法，容易出错。 离开了IDE的帮助，长注解的可读性变得很差。（比如在GitHub上） 同样配置的注解多个地方使用，修改时要改很多地方。 这里我向大家推荐通过继承的方式配置Hyperf内的注解。 下面是一个继承CircuitBreaker（熔断器）注解的例子。 <?php ... /** * @Annotation * @Target({"METHOD"}) * * Shorthand for CircuitBreaker(timeout=0.05, failCounter=1, successCounter=1, fallback="App\Service\UserService::searchFallback") */ class FooCircuitBreakerAnnotation extends CircuitBreakerAnnotation { /** * @var float */ public $timeout = 0.05; /** * @var string */ public $fallback = UserService::class.'::searchFallback'; /** * The counter required to reset to a close state. * @var int */ public $successCounter = 1; /** * The counter required to reset to a open state.

The Clean Architecture is more like a fantasy. It is like a wonderland we will never be in. I would enjoy and appreciate a work where all business domains, application domains, and transports and UIs, etc. are all orthogonal. In reality, they are all wired together like a mess. It is no mess created by engineer though. The world is chaotic by itself, so do all the business around it. Imagine your boss tell your team to add a new button to your website, and you find your business rule doesn’t cover this button what so ever, so you have to update your JSON API, add new test cases, and add new event to your event sourcing bus, and change whatever is affected all the way down to the database level.

As the job demand is going nowhere in a decade, a lot of new guys want to get into programming. There are numerous courses online, teaching a variety of skills in programming. There are also new shinning frameworks climbing up GitHub trending every day. I see a lot of people, typically newly graduated students, get confused. There seems to be an endless stream of knowledge to learn. How many skills are enough?

We have carried out the first or maybe last round of rewrite of the Juhui DSP/SSP/ADX with Typescript. A few goals and non-goals have been set for this labor-intensive process. Goals Strong typed. Strong API contracts. Holistic Observability with logging, tracing, and metrics. Layered Architecture and dedicated component. Testcases can be run by anyone. Stateless over stateful. Improved readability. Proper code deprecation process. Non-Goals Use fancy technology.

Over the days I have been thinking about improving my coding one step further. As I was refactoring some company work, this idea came to me. One of the least mentioned traits of good code is that you can easily remove a slice of them (from a larger project). Think about that. Removability means components are modular, architecture is layered, and abstractions are aptly interfaced. It also means Single Responsibility is enforced, so removing one thing won’t jeopardize another.

Came across this pic from twitter. If I have an adequate number of audience, I would like to make poll out of it. What do you think about this piece of code? A: It is good code. B: It is bad code. I have never done react before (Or I have, but not professional). However this piece of code is very readable to me. If I was tasked with the job to maintain this code, I would appreciate the original author for coding in this fashion.