발전 가능성을 염두에 두고 개발 스케일을 키우는 코딩을 해야함

[익명(221.158)]

코드가 매우 단순해도 돌아갈수 있는 이유가 프로그램이 너무 작은 스케일의 타겟을 겨냥해서 그럼

스케일이 작으면 딱 정해진 기능만 구현하게 되는데 해봤자 얼마나 어렵겠음

그래서 유지보수의 깊이도 깊지 않음

근데 스케일이 커질수록 저렇게 안일하게 코딩하면 개발과 유지보수를 감당할 수가 없음

프로그램은 기능을 구현하기 위한 도구인데 새 기능은 안나오고 맨날 현 기능만 디버깅함

[익명(112.160)]

나 1년차 때 그렇게 하니깐 왜 쓰지도 않을 기능 염두해서 만드냐고 존나 갈구던데

[익명(112.160)]

보안 이거이거 부족하지 않냐니깐 존나 병신마냥 쳐다보고 하

[익명(221.158)]

정리되지 않은 스파게티 코드를 양성하는것도 연봉상승의 방법 중 하나이긴 함

[익명(112.160)]

그거였노... 소규모긴 했음 회사 프로그램도 그 셋이서 다 개발했고

[익명(61.77)]

발전가능성을 너무 과도하게 고려하면 over engineering 나는 것임. 적당하게 예상해서 적당하게 대비책을 만드는게 고수임

[익명(61.77)]

3주면 개발할것을 3개월이 걸리게 되는꼴도 발생하는것

[익명(221.158)]

발전 가능성을 판단하는 기준이 팀의 스케일이라 들었음 결국 개발 총량은 팀원 명수에 비례하고 이를 풀타임으로 돌려야하기 때문에 이에 비례한다는걸로 알고있음

[익명(61.77)]

발전가능성을 판단하는건 팀의 스케일이 아니라 sw의 요구사항임. 팀의 스케일은 단지 맨파워만을 의미함.

[익명(221.158)]

설계 단계에서 봤을때는 그 말이 맞을듯

[익명(182.230)]

소공시간에 배우잖아

[익명(221.158)]

소공시간에 다 잠

[익명(182.230)]

ㅋㅋㅋㅋㅋㅋ 근데 잠오긴하더라 꾸역듣긴했는데 거의다 기절함 ㅋㅋ