[TechNews] 유용한 개발 관련 아티클 및 영상 #15

 

 

1. 유용한 개발 관련 아티클 및 영상 #15

---

소프트웨어 개발의 미래에 대한 고찰

• 기계가 창의적으로 생각할 수 없다는 것이 자동화에 대한 주된 반대 논리였으나, 이제 그 주장은 점점 약해지고 있음
• 소프트웨어 개발은 단순히 코드를 작성하는 것 이상임
• 업무의 성격이 바뀌고 우리가 사용하는 도구가 지금과는 매우 달라지겠지만, 가까운 미래에도 소프트웨어 개발자를 위한 시장은 여전히 존재할 것 같음

 

출처: https://news.hada.io/topic?id=13982&utm_source=slack&utm_medium=bot&utm_campaign=T03FE7QJV

 

 

 

팀은 암환자인 저에게 다시 보자고, 약속했습니다

• 암에 걸린 직원에게 최선을 다하는 회사의 모습을 볼 수 있음
• 연봉이나 인센티브와 같은 물질적인 보상도 좋지만 동료의 보상이 어쩌면 최고는 아닐까?

출처: https://flex.team/blog/2024/04/04/welcomeback-flexteam/

 

 

 

디자인 시스템, 코드를 넘어

• 만들기 전에
  • 디자인 시스템은 제품의 일관성, 효율성이라는 가치를 달성하기 위해 만들어짐
  • 만들고자 하는 시스템의 철학과 목표는 앞으로 쌓아나갈 결정의 토대가 됨
• 만드는 중에
  • 만드는 중에 생기는 결정들이 팀에서 합의한 방향성에 어긋나지 않아야 하며, 대원칙에 기반한 결정도 연습이 필요함
  • 시스템은 선택되는 순간 제품보다 수명이 길어진다. 그렇기 때문에 지속 가능성을 고려해야 함
• 테스트 코드
  • 디자인 시스템은 핵심 기능을 올바르게 제공하고 지속 가능해야 하는데, 이 두 가지는 테스트 코드라는 최소한의 안전장치로 보장되어야 함
  • 테스트 코드는 어디까지나 제품을 돕는 수단이며, 물론 테스트가 모든 버그를 발견해주지는 않음
• 여유 시간 확보하기
  • 여유시간이란 팀 사이클에서 하루 정도 본래의 사이클에서 벗어나 우선순위 높은 백로그를 구현하거나 자동화된 테스트를 보강하는 등, 기술부채를 청산하는 시간을 의미함
  • 역설적이게도 팀이 바쁠수록 이 시간을 지켜야 함, 빠르게 달리는 속도만큼 쌓이고 나중엔 감당하기 어려워짐

디자인 시스템을 설계할 때, 어떠한 부분을 고려하고 결정해야 하는지에 대한 내용이 엄청 상세하게 적혀있다. 설계하고자 하는 시스템에 따라 필요한 의사 결정을 맞추면 좋을 것 같다.

출처: https://so-so.dev/react/design-system-beyond-code/

 

 

 

DBC 를 이용한 Living Documentation 만들기

• DBC의 소개
  • DBC(Design By Contract)는 eiffel programming 언어의 창시자인 Betrand Meyer가 1988년 Object-Oriented Software Construction 라는 그의 책에서 처음 소개한 개념임
  • DBC 를 잘 활용하면 코드를 더욱 가동성있게, 서술적으로 작성하여 코드 자체가 문서가 되는 code as a documentation 로 한 걸음 다가설 수 있음
• DBC에 대하여
  • 소프트웨어 시스템의 구성요소들은 시스템 내에서 어떠한 obligation (의무) 와 benefit (혜택) 에 의해 동작하는 현실 세계와 밀접 하다고 보는 것
  • 상호간에 발생하는 의무와 혜택은 어떠한 계약의 울타리 아래에서 보호되고 유지됨
• DBC와 OOP
  • 객체간의 협력을 통해 시스템을 구성하는 OOP 에서는 이러한 contract metaphor 가 동작하기에 가장 최적의 장소임
  • OOP 에서의 contract 는 객체 들이 서로 책임을 통해 협력하는 과정에서 계약 관계가 있다고 봄
  • DBC를 사용해 계약의 내용을 모두 코드에 녹인다면, 그 자체로 코드가 비즈니스 정책 문서가 될 수 있음

출처: https://medium.com/@dhslrl321/dbc-를-이용한-living-documentation-만들기-ef65c18ff5ac