블레이저 코드 작성 중,
ctrl
+.
를 누르면, 아래와 같이 제안됩니다.
예전같으면 인텔리센스가 make method async
를 최상단에 제안했는데 말이죠.
뭔가 인텔리센스를 축소하고 있다는 느낌이 드는군요.
혹시, 이번에 해고된 개발자들 중에 인텔리센스 팀이?
(VS 는 Preview 가 아닌 최신 버전, 블레이저 9.0)
블레이저 코드 작성 중,
ctrl
+.
를 누르면, 아래와 같이 제안됩니다.
예전같으면 인텔리센스가 make method async
를 최상단에 제안했는데 말이죠.
뭔가 인텔리센스를 축소하고 있다는 느낌이 드는군요.
혹시, 이번에 해고된 개발자들 중에 인텔리센스 팀이?
(VS 는 Preview 가 아닌 최신 버전, 블레이저 9.0)
Copilot을 프로모션 하는 것일 수도 있고, AI에 집중하기 위해 엔지니어들을 대량으로 layoff 하는 과정의 후폭풍으로 제품의 QA 컨트롤 실패가 점점 늘어나는 증거일 수도 있다고 생각합니다.
이런 식의 문제점이 Visual Studio 본판 뿐 아니라 Windows, Office, 심지어 Azure 등에서도 계속 발견되고 있는게 큰 문제라고 생각하고 있습니다.
오히려 기존 인텔리센스의
과도한(?) 추천으로 (e.g. Primary Constructor)
불만이 많았던 것들이 다시 축소되는 과정일 수도 있겠다는 생각이 드네요.
그 추천은 변함 없이 계속되는 것 같습니다.
추천보다는 error 의 해결을 코파일럿으로 던지는 것 같습니다.
저는 public 생성자 중 객체 초기화에 필수적인 것을 primary 로 지정하는 것이 좀 더 체계적이라고 생각합니다. 그리고, 파생 시에 문법이 간소화되는 것도 큰 이점이라고 생각합니다.
abstract class B(int x)
{
public int X = x;
}
class D(int x, int y) : B(x) // 생성자 문법 간소화
{
public int Y = y;
public D() : this(0, 0) // primary 생성자 호출 강제
{ }
}
일반적인 생성자를 쓴다면, primary 생성자 호출이 강제되지 않는데, 이는 어쩌면 실수의 원인이 될 수도 있을 것입니다.