tldr

Things You Should Never Do As A Software EngineerHere are some of the things that software developers should avoid when coding to improve their work performance and mental health.favtutor.comBeing Perfectionist모든 것은 완벽하지 않다. 그래서 나는 “완벽한 코드”도 존재하지 않는다고 확신한다.소프트웨어 개발은 반복적인 프로세스이다. 코드를 짜고, 테스트하고, 피드백을 받고, 리팩토링 하고, 이를 반복한다. 오늘 잘 동작하던 것이 내일 동작하지 않을 수 있다. 따라서 소프트웨어는 유연하고 변경하기 용이해야한다. (이것이 soft-ware 라고..

Clever code is probably the worst code you could writeAnd clear, readable code is probably the hardest code to writeread.engineerscodex.comdef mininumTotal(self, t): return reduce(lambda a,b:[f+min(d,e)for d,e,f in zip(a,a[1:],b)], t[::-1])[0]위 코드는 흔히 “코드 골프”라고 불린다. 취미로는 좋을 수 있지만 “좋은 코드”와는 거리가 멀다.모두들 이것이 좋은 코드가 아니라는 것은 알고있다. 실제 업계에서는 가장 나쁜 코드 중에 하나라고 할 수 있다.반대로 생각해보면 가장 명확한 코드를 작성하는 것이 실제로 가장 어려..

How not to do code reviews - Aviator BlogMany code review processes become bottleneck for the engineering teams. Instead of finding bugs, it hinders progress leading to poor developer experience.www.aviator.coHow not to do code reviews전통적으로, 코드 리뷰는 엔지니어가 동료의 코드를 오류를 찾고 가독성, 효율성, 유지보수성을 보장하기 위해 면밀히 검토하는 것을 포함했다. 이 방식은 특히 대규모 팀에서 병목 현상을 유발했다. 왜냐하면 적합한 리뷰어들이 필요할 때마다 변경을 검토할 여유가 항상 있는 것은 아니기 때문이다. C..

You probably don’t need microservicesMicroservices is a great architectural style that helps to scale the system and the organization. But probably you don’t need microservices...www.thrownewexception.com마이크로 서비스는 시스템과 구조를 확장하는데에 도움이 되는 훌륭한 방식으로 최근 굉장히 인기있는 아키텍처 스타일이다. 많은 성공한 회사들(넷플릭스, Spotify..)을 포함하여 대부분의 회사들이 이 방식을 사용하거나 사용할 계획을 가지고 있다. 하지만, 몇몇 회사들은 마이크로 서비스가 가져오는 추가 비용을 간과하고 있다.본격적으로 이야기 하기전..