How an ideal Pull Request(PR) should look like.
Name: The name of the PR should indicate what its purpose is. Is it a feature? or a fix? or just config update? etc.
Convention: The spacing of the code, variable/function/class naming should be followed. Give meaning full names. Give thought before naming because these names will decide how fast you can debug/iterate on the code.
Class design: Remember that class you took in university for OOPS? Its time to use it and apply some brain before adding classes. There can’t be a perfect class design but there is always a scope of improvement. Are you exposing correct functions from class? Can you extend it to some other class? Can you override some other existing classes?
Function scopes: I find many developers doing this mistake. A function is a design to do some work, it can't do everything. Delegate its work some other smaller function. It makes adding new features, understanding, debugging code super easy.
Unit Tests: I can't stress this enough. Write those f***ing tests. Why do you even want to test function scenarios by integration testing? Just write unit tests and test a function. I see many engineers not writing tests and hitting endpoints to test business logic, a total waste of time. Unit tests save time to test code, iterate, fix a bug, test a small part of code.
Comments: Your code should be easy to read, following naming conventions is one best way to go for it. But if it contains some magic logic or something which most people won't get, please write a comment. If I am reviewing a PR and I am not able to get what that code is doing, not a good sign for scaling the code. So try to write as much a comment as possible, trust me, comments are a savior when code breaks.
Network Calls: We know network calls are expensive, establishing the connection, is time-consuming. So are you establishing networking calls in the loop? Can you reuse the connection? Can you process data in batch? Can you do multiple requests in a single connection? Optimizing network calls give you some of the highest returns on latency.
Asynchronous Calls: Understand the need for an operation, like updating the data, sending data to other services. Do you need to wait to complete them? Can they operate separately? If yes then try to call them asynchronously via queues(eg. RabbitMq) or Ajax calls etc.
Logging: Log the data which you will find useful for debugging or analysis. Don't just catch the exception and return something. Log that exception. You can log API request input and output, events firing and many other things depending on the use case. The point here is to use logging so you can monitor, debug, analyze code properly.
My take on writing close to perfect has been improving over the period of time. I just wanted to share some of the things I learned which many can find useful. I might be wrong/partially correct as I am also learning. Please feel free to give suggestions about how we can improve this post.
Happy Hacking
