[251015] Day 65 - 추석과 소프트웨어 공학

들어가며

이번에는 LIG 에 다니시는 연구원 분이 오셔서 4일간 소프트웨어 공학에 대한 강의를 해주고 가셨다. 그런데 세상에나, 피어들한테 텔레칩스와는 완전히 결이 다르게 뽐뿌를 막 넣어주시고 가셨다 ㅋㅋㅋ 그래서 추석동안, 그리고 지금까지도 여전히 고민으로 남아있는 부분들이 여럿 있다. 지금 생각나는 것들을 하나씩 정리해볼까. 요건 2달 리뷰에 넣어야겠다.

ㅤ

그래도 굉장히 많은 인사이트들을 얻을 수 있었던 귀중한 시간이였다. 완전히 텔레칩스랑은 관계가 없는 옆 회사의 사람이다 보니깐 조금 더 폭넓게 말해줄 수 있던 것들이 많았던 것 같다.

ㅤ

먼저 정리를 조금 해보자면, 세상은 발전할거고 C를 작성하는 일은 줄어들거고 그 마저도 AI 가 작성하게 될거다. SW로 먹고 살거라면 설계를 할 줄 알아야 한다. 객체지향을 해라. 죽을 때까지 일해야 한다면 학사로는 부족하다. 석사를 생각해봐라.

ㅤ

이외에도 전반적인 임베디드 SW 분야에 대해서나 SW로 오래 먹고살기 위한 다양한 인사이트들을 얻을 수 있었던 좋은 시간이였다. 이전까지 내가 해오던 것들도 여기로 넘어오는데에 있어서 크게 손해보는 장사가 아니라는 것도 느꼈고 — 아니 오히려 장점으로 보일 정도 — 조금 더 나의 특장점을 살리는 개발 분야를 골라야 하나 고민하게 되는 계기가 되었다.

ㅤ

오늘의 키워드

소프트웨어 공학과 설계

소프트웨어 설계에서 가장 중요한 것은 변화를 수용할 수 있도록 설계하는 것

ㅤ

SW 직군에서 오래 살아남으려면 결국에는 설계를 할 줄 알아야한다!

ㅤ

ㅤ

Software Architecture

• 기능 : 실행이 가능 (요건 온몸비틀기로 어떻게든 해낼 수 있음)
• 품질 : 00의 성능으로 실행이 가능 / 100만 접속 감당 가능
• 제약사항 : 기한 / java로 작성하기
• 제약사항과 품질 등에 따라서 전체 아키텍처가 달라질 수 있다. Trade-off 에 따라 어떻게 구조를 잡을지 설계.

ㅤ

개발 프로세스

• 워터폴 모델
• V 모델 → 제조업 분야에서는 요런걸 되게 많이 사용함.
• 프로토타이핑 모델 (이게 에자일하게 가져가서 결과물에 대한 피드백을 말하는게 아니라, UML 기반의 다이어그램에 대해서도 적용할 수 있는 것임)
• 애자일 모델

ㅤ

요구 분석

이제는 무엇을 할 지 결정하는 것이 어떻게 할 지 결정하는 것보다 중요해지고 있다.

• 기능 요구 / 비기능 요구 파악이 중요

ㅤ

Unified Modeling Language

• 요구사항을 분석하고 이를 시각적으로 표현하기 위해서 사용.
  • UseCase를 분석하고, 이를 기반으로 유스케이스 다이어그램, 시퀀스 다이어그램을 작성
  • 도메인 모델을 작성 (클래스 파악하기)
• 프로젝트 상황에 맞게 얼마나 디테일하게 작성할 지 결정할 것

ㅤ

아키텍처 설계

이 개발 시스템에서 무엇이 중요한지를 작성한 문서.

다이어그램으로 계층 등을 표현 + 각 칸이 어떤 역할을 해야하는지에 대해 디스크립션을 상세히 작성해야함.

ㅤ

• 보통 프레임워크가 아키텍처의 구조를 제공함.
• 아키텍처는 ‘철학’이라고 봐도 됨

ㅤ

언어

함수형 언어

• 함수형 언어가 인기가 늘어난 것은 듀얼코어 때부터임.
• 멀티스레드 환경에서 객체지향은 객체의 내부 상태가 누구에 의해 변경될 지 모름 (타이밍 이슈)
• 그래서 동일한 input에 대해서 항상 동일한 결과가 나오지 못함.
• 그러나 함수형 언어를 사용하면 상태를 가지지 않기 때문에 input에 대해 항상 동일한 output을 사용할 수 있음.
  • 고차함수!
• 대신 메모리랑 CPU를 많이 사용하긴 하지만, 요즘에는 메모리랑 CPU 성능이 좋아져서 괜찮음.

ㅤ

함수의 유형

• Procedure
  • procedure는 인자로 데이터타입만 전달할 수 있음.
• Method
  • method는 인자로 객체를 전달할 수 있음.
  • method의 실행을 위해서는 객체(메서드의 주인)이 필요함.
• Function
  • function은 인자로 function을 전달할 수 있음.
  • = 람다 함수 (익명함수) 전달 가능
  • 이걸 써서 합성함수를 만들 수 있음.
  • C++에서도 쓰레드에는 람다를 사용할 수 있음.

ㅤ

자바는 객체지향이기 때문에 인자로 객체를 넘길수는 있지만, 함수를 인자로 넘길 수 없음.
그런데, 함수를 객체로 한 번 감싸서 다루면서 함수를 인자로 넘길 수 있게 테크닉을 적용해뒀음. 그래서 자바도 함수형 언어처럼 함수 호출이 가능해졌다.

ㅤ

면접을 준비할 거라면

면접은 나를 자랑하는 자리라기 보다는 나를 셀링하는 자리임.

최대한 회사에 대한 정보들을 찾아보고 팀에서 사용하는 도구와 필요로 하는 내용들을 찾아보기.

내가 지금까지 해왔던 것들이 회사에 어떻게 도움이 될 수 있는지를 어필하는 방향으로 준비해야함.

ㅤ

SOLID와 객체지향

• SRP : 단일 책임 원칙
  • 클래스는 단 하나의 책임을 가져야 한다.
• OCP : 개방 폐쇄 원칙
  • 기존 코드를 그대로 두고 기능을 확장할 수 있어야 한다.
• LSP : 리스코프 치환 원칙
  • 자식 클래스는 부모 클래스를 대체할 수 있어야 한다.
• ISP : 인터페이스 분리 원칙
  • 클래스는 자신이 사용하지 않는 인터페이스에 의존하지 않아야 한다.
• DIP : 의존성 역전 원칙
  • 고수준의 모듈은 저수준 모듈이 아닌 저수준 모듈의 추상화에 의존해야 한다.

ㅤ

객체지향을 잘 하려면 구현 상속 보다는 인터페이스 상속 (구현) 을 잘 활용해야한다.

ㅤ

객체지향 언어의 람다 함수는 함수 인자로 함수를 넘기기 위해 나왔다.

• 기존의 방식에서라면 함수 하나만 담는 클래스를 선언해서 객체로 new 하고 인자로 넘기는 방식을 사용해야 함
• 근데 이게 보일러플레이트가 너무 크니깐 그냥 줄여서 함수를 전달할 수 있는 것처럼 문법을 만들었다.2

ㅤ

객체지향에서 섹시쌈뽕코드

• 상속은 데이터만 → 클래스에는 데이터만 넣고 상속하기 (extends)
• 구현은 메서드만 → 인터페이스에는 메서드만 넣고 구현하기 (implements)

ㅤ

• Idiom : 구현 레벨에서 자주 사용하는 패턴 (언어에 종속적임 - java에서 많이 사용되는 idiom)
• 디자인패턴 : 설계 레벨에서 자주 사용하는 패턴 (언어와 관련 없음). 실체가 없음.
• 프레임워크 : 설계의 개념이 적용되어있는 라이브러리. 실체가 있음.

ㅤ

제조업 기업에서의 면접 질문

• TCP/UDP
  • 프로토콜의 장단점
• C와 C++ 차이점
  • (프로시저 / 객체지향 - 패러다임 차이)

신호 및 시스템 학습

추석동안 신호및시스템 강의를 듣고 학습을 하면서 내용들을 쭉 정리했다.

신호및시스템이 사실 어떤 과목인지도 모르고 일단 덤볐는데, 선형대수학적인 내용들을 도구로 사용하고 있기는 하지만, 

 

https://etst.tistory.com/431

[신호및시스템] Phase 3-2 - 이산 푸리에 변환

https://etst.tistory.com/432

[신호및시스템] Phase 3-3 - Fast Fourier Transform

https://etst.tistory.com/433

[신호및시스템] Phase 4-1 - 샘플링

https://etst.tistory.com/434

[신호및시스템] Phase 4-2 - 샘플링 복원

https://etst.tistory.com/435

[신호및시스템] Phase 4-3 - 이산 신호처리 파이프라인