今日推薦開源項目：《設計模式 design_patterns》
今日推薦英文原文：《There Is No 「I」 in Software Development》
今日推薦開源項目：《設計模式 design_patterns》傳送門：項目鏈接
推薦理由：這個項目是對諸如工廠模式這樣的場景設計模式的講解，通過使用 UML 圖與示例代碼來讓讀者更容易理解，如果一時間搞混了 UML 圖中的各類圖標，項目里也介紹了 UML 圖可以幫助讀者重新回憶學習。
今日推薦英文原文：《There Is No 「I」 in Software Development》作者：Igor Vlahek
原文鏈接：https://medium.com/better-programming/there-is-no-i-in-software-development-4ec478631d6b
推薦理由：在團隊合作中自己只是一小部分，別忘了除了你之外還有別人會影響你的代碼
There Is No 「I」 in Software Development
Try changing it to 「we」 next time
The famous 「I」 word
「I」 — this is a word I have been hearing a lot of lately. And this 「I」 word is often coming from developers that are working solo on back-end applications that often do not have any real users. Put aside the notion that we are talking about the back-end developer now.If you are a developer, we can all agree that you can get attached to your application and call it your own. That』s especially true if you have been working on it intensively for years and you know the code by heart. It』s not a surprising fact that sometimes developers feel like they are the only user of the application. And often they start to use 「I」 instead of 「we」 when talking about the application we control.
In this article, I will talk about my experiences with developers working on back-end, front-end, and firmware applications, and their wrong vision of our application. We will mention the importance of saying 「we」 and not 「I」 when we talk about:
- application logs
- application code
- the solution as a whole
「I」 Sentences
Let』s start with my favorite.「I find logs in my application readable, and I can manage just fine.」
This is my favorite. Well, the logs are not just for you. There is a long list of clients that are interested in your logs. All the persons listed here are acting as a line of defense for you from the clients. They will bug them first and not you when your application is not behaving as expected.Let』s name your clients:
- DevOps — They are the ones deploying your application. If they can figure out why your application is not working as expected early, they will save a lot of time for the people later in the chain.
- Developers— You are not going to work indefinitely on your application. Other developers will come and continue your work. And they will need to figure out why your application is not working as expected in production. Logs are there for them too. Think of other developers working on your application even if you are the only one working on it at the moment.
- QA — If they can figure out who is to blame in a situation when two applications are communicating, they will not bug two persons, they will bug only one person, thus saving valuable time.
- Support — There is no sweatier call than when someone reports a bug in production. Think of those guys too. Give them just enough information to know whether this is a bug or not.
- Configuration parameters during startup — DevOps can make mistakes while configuring your application. Log loaded configuration parameters during your application startup. This will save a lot of your time.
- External calls to other services — If you are calling external services, log what is sent and to whom you are sending. If you are calling REST services, log the URL you are targeting and request body you are sending. If you are sending a message to Kafka, log which Kafka server and which Kafka topic you are targeting. You can load the correct parameters, but sometimes you are passing the wrong parameter used to route calls to external applications.
- Request/Response — Log requests coming to your application and responses generated by your application. This is the most valuable piece of information you can get when a report from a production environment comes. With this information, you can rule out your application as a potential suspect for a bug.
- A critical decision in your application — If your application needs to decide which path to go, log which path it has taken and the parameters that made it go on the path. Often you can see application going the way you did not anticipate. Log what: the path the application has gone. And log why: the parameters that made you go that path. It will be easier to analyze later.
「I can find my application code readable, and I can manage just fine」
This is the deadliest 「I」 construct, in my opinion. You can fix logs rather quickly. And you can fix logs without affecting the application logic. In each iteration, you can add logging without fear that you will break something. But if the code does not follow any rules but your rules, then we are in for trouble.There are a lot of coding styles on the internet you can follow. The most important thing is to follow one of the guides. By following the guide, you are admitting that you are a part of a collective and that the time you are working on the application is finite. One of the days you will resign or go to another position. When the time comes, your application is not going to be yours anymore. It is going to be passed to another developer. Be kind to them.
Be good to the programmers inheriting your codebase, even if you are the one-man team behind it:
- Employ one of the following code styles found on the internet. Just google it. It will give you plenty of choices. I suggest Oracle code convention and Google Java Style guide for Java application.
- Read 「Clean Code」 by Robert C. Martin. I cannot stress enough how important this book is for every developer, and for a Java developer especially. Once you have read it, you will realize that you have been programming the wrong way all along. Just read the book if you haven』t. It will be an eye-opener.
- Write unit/integration tests. Tests are here to warn us if someone changed the application behavior. And they are also here to teach developers inheriting your application.
- Employ CI to your application. By employing CI to your application, you will leave a template for how your application should be built on another developer』s PC. If it works on the CI server, it will work on another developer』s PC also.
「The bug is not in my component. My part of the overall solution is working just fine.」
This is also an interesting one. This can be heard from developers on the front end and back end, and from the firmware people. But in my surroundings, the firmware people win this category.For me, this is a normal response from a developer that is doing their job right. When saying right, I mean the developer that is testing applications on the dev or local environment, or just taking time to test the application and not passing it straight away to QA. You can』t get mad at a good developer saying this. Why? Because we all think that our application is bulletproof. And especially if the developer is testing the application against other components. But even if you are such a developer, you must remember that your application is almost always only a small part of a bigger system. Even if you have tested the application by yourself and you have tested the application for input, they are still saying it』s not working as expected.
What can we do if someone approaches us saying that the bug is in your component? At the least, you can write a test and show that the bug is not in your component. Remember, we are only earning money when the whole solution is working as expected. Your goal is to remove the suspect from your component as soon as possible. As soon as you remove the suspect, they will be looking for another suspect and they will leave you alone. And when your application has been identified as a false suspect a number of times, you will get respect and you will not be bothered so often.
In this situation, the fact that your application is working fine does not make it better. It makes you better, but in the eye of the clients, you are looking bad as the one who made the bug. We are all looking bad in the eyes of the clients. Only when all components are working as expected will we be earning money. Be a team player and cooperate with others in identifying a component that caused a bug.
Remember, we are only making money if the solution as a whole is working.
Thanks for reading!
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
