[미디엄] 일부 개발자가 결코 개선하지 못하는 이유

[미디엄] 일부 개발자가 결코 개선하지 못하는 이유(Why Some Developers Will Never Improve | by Sukhpinder Singh | C# .Net | .Net Programming | Mar, 2025 | Medium)

저자 : Sukhpinder Singh

위 글에서 첫 항목은 다음과 같습니다.

“그들은 C#을 여전히 2005년인 것처럼 취급합니다.”

예로 든 코드는 다음과 같습니다.

// Their idea of "good code"
public void ProcessData()
{
    ArrayList myList = new ArrayList(); // Because who needs type safety?
    for (int i = 0; i < 100; i++)
    {
        myList.Add("Item " + i); // String concat in a loop? Sure, why not.
    }
}

그리고 위 코드에 대한 저자의 평입니다.

  • List 대신 ArrayList – .NET 2.0부터 있었음에도 불구하고 "너무 복잡하다"는 이유로.
  • 루프에서 문자열 연결 – 그들은 StringBuilder에 대해 전혀 몰랐거나, 더 나쁜 경우 "과도하다"고 생각합니다.
  • 마법의 숫자와 하드코딩된 값 – 구성 파일? 환경 변수? 안 돼요, 그냥 파일 시작 부분에 const int MAX_RETRIES = 5;를 던지고 끝내세요.

그들은 LINQ, async/await, 심지어 기본 OOP 원칙도 배우지 못할 겁니다. 그리고 개선 사항을 제안할 때는요?

“작동하죠?”

여러 분은 어떠신가요?

5 Likes

코드 보자마자 boxing 성능 저하되는거 화나는군요. Generic!!

6 Likes

.NET/C#의 경우에도 그렇지만, 비슷한 문제점을 안고 커리어를 지속하는 발전하지 않는 개발자들은 다른 도메인에도 많다고 생각합니다. 학습하지 않고 IJW만 주장하는 사람들 때문에 혈압 오르는 일이 비일비재하죠 ㅋㅋㅋ

7 Likes

위 글에 동의하는 C# 사용자라도, 아래 비판은 쉽게 인정하기 힘들 것입니다.

for 와 while 은 60년대 방식이고, interface 는 90년대 방식이다.

8 Likes

개인적으로 Rx를 접한 뒤로는 .NET이 처음 도입한 Rx에 대해서 .NET 기술을 쓰는 사람들을 오히려 알아주지 못하고 RxJS, RxJava 같이 다른 곳에서 쓰는 점… 다른 언어에서 더 알아주는 게 아쉽습니다.

Rx가 된다는 것 하나로, 이벤트 소싱이나 백프레셔같은 고급 제어 기술들을 먼저 도입할 수 있었던 거라고 생각합니다.

물론 지금은 Rx없이도 가능하더라도 그런 출발점이 달랐던 .NET에 대해서 세월이 많은 부분을 고이게만 만들었던거 같네요.

2 Likes

저는 솔직하게 'Rx’를 잘 알지못합니다.

그러나, 막연하게 Rx의 원조는 Event 이고,
Event의 원조는 Callback 함수 이고,
Callback 함수는 ‘함수의 포인터’ 라고 생각합니다.

지금은 이런 것들이 더 확장되어 Interface, Action, Func 등으로 진화했다고 생각합니다.

특정한 기술이 여러 이유로 한 때에 유행할 수 있습니다. 그러나 그 근본을 알면 그 기술은 더 좋게 변해가고 이름도 바꾸고 하는 듯 합니다.

1 Like

제가 Rx를 강조했던 이유는 단순히 원형의 원형으로 올라가고자 함이 아니라,

하나의 개발 패러다임을 이끈 선두 주자였기 때문입니다.

포인터로 다되니까 C가 최고야 라는 개념으로 접근한 것은 아니라는 것입니다.

Rx는 말씀하신 interface, delegate들이 모두 들어간 기술입니다. 그리고 이런 형태가 퍼져서 다른 언어까지 번지는…언어가 다른데도 문화를 만들어낼 수 있었던 점은 시작점이 다르다고 볼 수 있을 것 같습니다.

다만 시작점은 달랐지만 세월에 의한 스노볼링은 생각보다 적었던 것 같습니다. 오히려 다른 언어에 좋은 영감을 주었지, 정작 웹개발을 하면서 백앤드에는 .NET을 쓰면서도 JS만 Rx를 쓰는 형태가 많을 정도로 .NET 에서는 오히려 잘 안쓰이는 듯합니다.

언급 드린대로 Rx의 개념은 이제 여러 클래스로 기능이 분리되어서 굳이 Rx를 쓰지 않아도 됩니다만… 그저 아쉬울 뿐인거죠.

.NET의 기술이 그만큼 빨랐고 잘 디자인되었지만 오히려 일반 개발자들이 그냥 쓰는데 그친거 아닌가 싶습니다. 물론 회사 업무만 하고 개인시간이 중요하기때문에 굳이 그런걸 하지 않아도 되는 그런 건 당연히 저도 회사원이니까 이해합니다.

왜냐하면 기술적 욕심도 있지만 결국 언어라는 건 기술로 표현되는 비즈니스 도구인게 가장 원형의 모습이 아닌가 싶어서라고 생각합니다. 말씀하신대로 한때 유행하는 기술이 있고, 또 말씀하신대로 그 기술들이 개념이 유지된 상태로 이름이 변형되는 것도 IT 업계에서는 아주 흔하게 찾아볼 수 있습니다만… Rx는 현재 진행형입니다.

이런 점들이 좀 안타깝다는 관점에서 본 것입니다.

5 Likes

공감합니다.

1 Like

최근 멀티패러다임에 관심이 생겨 함수형, 객체지향, List Processing을 적재적소 활용하는 방법을 공부하다가 Reactive Programming의 가치를 많이 느끼기 시작했는데 Rx를 C#에서 꽤 선두로 시작했었군요. :grin: 새로 알게된 사실입니다. 현재 진행형이라는 말이 공감갑니다.

2 Likes

넵 꽤 선두…가 어느정도 의미인지는 모르겠지만 제가 알기로는 Microsoft 에서 최초로 rx 패러다임을 만든 것으로 알고 있습니다. mvvm처럼 ms에서 업계에 최초로 만든 몇개 중 하나인 것이죠.

2 Likes