@disjukr@hackers.pub · 3 following · 25 followers

Website
0xabcdef.com
GitHub
@disjukr
X
@disjukr

better CSS에 대한 접근들(CSS-in-JS, Atomic CSS, Preprocessor)의 공통된 한계는 constraint solving 방식이 아니란 것이다.

다들 어떤 기존의 스타일을 '덮어쓰는' 방법, 근데 개중에 좀 잘 덮어쓰는 방법을 찾고 있다. 그런데 많은 경우, 뭔가를 덮어쓰려고 하고 있다면, 그건 사실 값을 덮어쓰는게 아니고 만족해야할 조건을 추가하고 싶은거다. 값을 덮어쓰는 것은 조건을 추가하는 방법 중 가장 강제적인 하나의 방법일 뿐이고. 즉, 디자인 시스템은 어떤 조건들의 합들로부터 실제 스타일을 구하는 방법이어야 하고, 개발자는 조건만 명시할 수 있어야 한다.

constraint solving을 잘 설계하고 구현하는게 어렵다 왜 이렇게 안 하냐고 하긴 좀 거시기하다. 그래서 나도 요즘 propagator를 공부중이다.

엘리먼트의 클래스 목록에서 순서는 의미가 없고 집합처럼만 작동하기 때문에 (선언 순서가 영향을 주는건 css rule만 해당) d1과 똑같이 적용될 것 같아요.

0

복잡한 코드를 단순하게 줄여나갈 수록 발생하는 버그의 빈도나 심각도가 점진적으로 올라가는 경향이 있다고 느낀다

@disjukr@hackers.pub

이 기술 블로그 포스팅에서는 코드 복잡도와 버그 심각도 사이의 미묘한 관계를 탐구합니다. 저자는 복잡도를 높이는 방향으로 문제를 해결할 때, 버그 빈도와 심각도를 점진적으로 줄일 수 있지만 최적의 해결책에 도달하지 못할 수 있다는 점을 지적합니다. 반대로, 복잡도를 낮추는 방향으로 접근하면 문제 해결에 드는 비용을 예측하기 어렵다는 어려움이 있습니다. 특히, 회사에서 코드 복잡도를 줄이는 대신 높이는 방향으로 문제 해결을 요구받는 상황에서 엔지니어로서의 자아와 현실 사이의 괴리를 느끼는 저자의 고충이 드러납니다. 개인 시간을 투자하여 더 나은 해결책을 찾아도, 이를 회사에 도입하는 데 많은 설득 비용이 소요된다는 점을 강조하며, 회사 내에서 자아실현을 포기해야 하는지에 대한 고민을 토로합니다. 이 글은 기술적 효율성과 조직적 요구 사이의 균형을 찾는 데 어려움을 겪는 개발자들에게 깊은 공감을 불러일으킬 수 있습니다.

Read more →
0
0