과학자와 프로그래머 차이

그런 코드가 점점 쌓여서 문제가 생겨도 건들지 못할 폭탄덩이가 만들어지고 인수인계도 회생도 불가한 상태가 되겠지

잘 모르시는 분들이 댓글 쓰는거 같아 흔한 케이스
예시 듭니다.

b2c b2b 케이스가 다르지만 흔한 내부의 일입니다.
ex1) 아이디어로 프로그램을 만들고 어렵게 영업을 하다가, 사업이 크게 확장된경우 ( 원히트 원더 게임이나, 비즈니스 수익이 한두개인 회사들이 이경우에 해당)
최초는 사람들이 정보를 얻고 구매 혹은 광고 트래픽 목적의 단순 로직이였다가 사업다각화로 인해, 단순한 로직들에 이거저거 넣기
시작, 돌아만 가는 로직에서 사업이 커지다보면 담당자도 자주 바뀜 히스토리 없이 버려지는 로직들 생김 - 이를 기술부채라고 하는데 주기적으로 해소필요(리팩토링, 매모리 시퓨 트래픽등등의 최적화), 사업적 측면으로 봤을때 아웃풋은 지금이나 바꾼거나 동일한데 회사의 리소스를 많이 투입해야하고 투입 대비 아웃풋 개선 효과가 크지 않으면 계속 버려지게됨. -언젠가 터짐 (프론트, 백 둘다 해당임) 이걸 프로그래머 탓으로 돌리는건 진짜 it 생리 아무것도 모르는것임

ex2) 다른사업으로 거대한 기업이 sw가 필요한 사업( 소셜커머스, 광고를 제공하는 메신저플랫폼 등등) 에 진출하는경우 사내 tf를 구성해서 비즈니스 로직에 맞는 인풋 아웃풋 이 확실한 프로그램을 구성함. 테스트인력, 빌드인력, 메니징인력, 프로듀싱인력등 한 tf 내에서 꼭 필요한 전문가만 모여서 킥오프 하면서 프로그램을 유닛단위로 만들며 단위테스트를 진행함. 빠르게 나오는 경우 트렌드에 맞아 떨어지며 사업으로 출범함. 하지만 이도 ex1의 경우처럼 트렌드나 사업요구에 맞게 바꿔야 하는 부분이 생기기 때문에 코드가 계속 바뀌어 기술부채가 생김. 이를 해소하지 않으면 짧게는 2년 길게는 5년-7년 후엔 중소에서 출발하나( 원래 it스타트업으로출발) 대기업에서 사업 확장하나 코드 상태 똑같아짐. 다만 대겹의 경우 그나마 히스토리가 존재함. ( 유지보수가 없는거에 비해서 낫다는거지 쉽다는 말은 아님 똑같이 헬게이트)

본문글에는 그냥 우스개 소리로 하는거라서 웃고 넘어가지만 댓글 모분께서 자꾸 코딩에 대해 우습게 말씀하시길래 써봄.

글고 기계어 최적화가 그리 훌륭하고 생산적이었으면 하이랭귀지는 나오지도 않았습니다. 요새는 어지간하면 하이랭귀지로도 빌드 뽑을때 최적화 됩니다요. 선생님. 어디가서 잘 모르는거 아는척좀 그만 하이소.

현직 개발자인데요 전문성을 떠나 개발이란게 그렇습니다 체계가 잘잡혀서 가면좋겠지만 현실은 개발도중 변경되는 사항이 많고 개발일정이 빡빡해 체계적으로 가기가 어렵습니다 영업하시는 분 설계하시는분들의 개발이해도와 능력으로도 설계가 많이 좌우되기 때문에 변수도 많구요 개발자 능력이 아무리 좋아도 전체적인 팀원과 상사의 능력이 안따라주면 말짱도루묵입니다 실리콘밸리와의 차이는 그런부분이겠죠 개발이해도가 높은 직원들과 업무를 진행할 것이고 현실적이고 체계적으로 갈 수 있는 개발기간을 잡아주는 것 등등.. 또 기계어에 가까울수록 성능면에서는 좋아지는게 맞을 수 있지만 코드량도 훨씬 많아지고 관리가 훨씬 어려워집니다 위 만화같은 상황이 나올확률을 더 높여준다고 봐야겠죠