[%] 와 프론트는 다른의미로 재사용성 챙기기가 빡시네

[ㅁㅁ(39.117)]

백에서의 추상화랑은 결이 아예 다르구나

UI 복잡해질수록 백이랑은 다른 의미로 신경써야될게 많아짐

백에서 추상화, 재사용성 이런건 데이터 자체에 좀 더 초점이 맞춰져있는데

프론트는 이 컴포넌트에 추후 어떤 UI가 들어와서 확장될 수 있을지, 

진짜 단순한 예시로 앱 홈쪽 만든다고 치면 나중에 설정에서 색상 같은거 바꿀 가능성도 고려해서 짜야함.

웹앱 규모 커질수록 고려해야할게 백이랑 다른 맥락으로 많아지네

[익명(221.167)]

그래서 애초에 객체개념반영에 조까세욤 하고 진화해왔음.. 요샌 좀 다른게 많지만 그래도 보편적인 절대다수입장에선 신경안씀 하고있음 필요하면 또 그렇다고 못만들어쓰는것도 아니라.. 이런걸 존나 싫어하는 사람들이 많은건 덤ㅋㅋㅋ

[익명(155.230)]

그냥 더러운거임 - dc App

[익명(119.56)]

프론트는 주먹구구식이 답임 진짜 단순한 동일 리소스만 모아서 쓰는게 나음

[익명(110.9)]

요즘은 재사용성 챙기기도 어렵드라

[익명(121.129)]

프론트와 백은 목적, 맥락이 다르니까

[익명(211.209)]

ㄹㅇ 백은 데이터 위주로 모든게 추상화되고 체계화되어있다고하면 프론트는 너무 관심사가 많음. 디자이너 입장도 있고, 기획자 입장도있고, 개발자 입장도 있고. 백하다가 프론트 보면 요런 오히려 전투적인 설계에 재미를 느낌. 그래도 약팔이 아키텍쳐 말고, 실무에서 쓸만하게 괜찮은 애들 많아서 참고 중.

[익명(139.180)]

거기다가, 그냥 순수하게 구현관점에서만 봐도 객체지향적인 상태를 DOM에 동기화시키는게 깔끔하게 떨어지지 않는경우가 너무 많음 그런데 백엔드에서 하던 방식 그대로 가져와서 "프론트는 왜 이렇게 안해요?" 하는 백엔드 밖에 모르는 바보들 보면 때리고싶다

[익명(211.209)]

전통적인 객체지향으로 다루면 외부세계의 의존성과 사이드이팩트를 담지못하니 UI표현은 한게가 있고 차라리 Flux패턴처럼 상태기준으로 안전하게 transition한다는 컨셉으로 가는게 젤 깔끔한듯.

[익명(211.209)]

그거와 별개로 재사용성 챙기는건 또 다른 패턴들이 있고. 리액트 생태계가 잘 갖춰져있는듯.

[익명(49.142)]

그래서 리엑트도 클래스 -> 함수 컴포넌트로 갔잖음

[익명(124.146)]

ㄹ

[익명(124.146)]

프론트도 코드 역할따라 프로토타입 활용 잘해서, css 구조 설계 잘해서 짜면 니네가 말하는것들 구현 가능함. 단 그만큼 프백 양쪽다 개발 해야할게 늘어날 뿐이라 그렇게 잘 안함]

[프로그래밍(nowadays3724)]

재사용을 챙기기란 너무너무 어렵다~

[익명(211.209)]

뱅샐 CTO가 왜 프론트앤드 개발자 출신 CTO는 많이 없을까에 대한 요 내용과 비슷한 내용을 남겼는데 공감함. (
https://twitter.com/hwangbyhwang/status/1761772131736838329?s=20)
프론트는
쌓여가는 코드베이스의 문제를 해결하는것에 업무 효율을 많이 느끼는 사람들이고, 시스템 문제는 효율이 적거나 문제가 없는 편.
백앤드는 시스템의 문제를 해결하는게 효율이 높은 직군. 비교적 코드베이스의 문제 자체가 그리 어렵지 않아서 해결도 쉬운편.
그러다보니 백하던 사람들이 클라개발을 하면 쉽다고 생각했던 문제들을 끙끙앓게되니 더 어렵다고 느낀게 아닐까?
반대로 클라 사람들이 인프라나 시스템 문제에 대해서 다루면 더 흥미롭게 보는 이유인것 같기도 하고

[익명(139.180)]

저 글 처음보는데 완전 공감함. 프론트는 코드레벨에서 다 해결해야해서 빡셈