작금의 패러다임이 아니라

자바나 자바 스크립트가 누더기 언어라서 그게 패러다임인거지.

가볍게 임베디드나 전장비회사만 가도 아니라는 것을 알 수 있음

조금만 더 나아가면 대규모 데이터 처리 회사라던가

그리고 솔리드 하는것 자체가 조직규모의 개발자들 모아놓고

실력자체가 불균형하니 그걸 어거지로 맞춰보자고 하는 개념임

입출력만 고정 해놓고 각 객체들은 솔리드 시켜버리는거지

그럼 중간 수정단계에서 플로우 하는것이나 어떤 모듈에 문제점이 있는지는 보기 편해지지만

그리고 글 전달에 잘못된게 있었나본데

모듈을 수정하는게 아니라

그 모듈로 A 용도로도 쓰고 B용도로도 쓰는 점이 문제라고 말하는거임.

최적화를 전혀 고려하지 않음. 그래서 메모리 낭비가 심한거고

그게 조직적인 프로세스에서는 최적화 되어있지만

실제 컴퓨팅에서는 최적화 되어 있는게 아님.

라이브러리 가져다 쓰다 보면 개발에는 편해도 해당 라이브러리가

어떻게 하드웨어를 가져다 쓰는지 물어보면

모르는 인간들이 태반임

그런데 자바나 스크립트 언어 사용하던 개발자들 특징이 그래.

라이브러리를 까보지도 않고 doucument 내용만 보거나 선행 개발자들을 신용하니까.

실제로 자신들이 라이브러리 보다 최적화 할 실력도 없는게 현실이고

실제로 자신들이 하던 업무에서도 문제 없었고

그래서 누더기 골렘언어 쓰던 사람들이 보면 if 문에 천 줄 있는게 형편없어 보이지.

왜냐고? 라이브러리에서 document에서 대충 스펙 설명한걸로 해당 코딩 다 이해한것처럼

가져다 쓰는게 추상화거든 입력 -> 추상적 된 연산처리 -> 출력

시스템 입장에서 보면

if문에 뭔 지랄을 하던 시스템 최적화만 잘 되어 있다면 전혀 상관없음

모듈을 쓰던 if문을 쓰던 jmp일 뿐

코딩만큼 가독성 좋은 언어가 어디 있다고 천 줄 가지고 가독성 타령을 함?

가독성에 문제가 생겼다면 정체 모를 라이브러리가 나타났거나

해당 알고리즘을 이해 못하는 경우밖에 없음

다시 말하지만 자바나 자바스크립트 같은 누더기 골렘 형태의 개발이면

프로세스 문제가 아니라 개발자간의 문제로 솔리드 하는게 맞음

그게 누더기 골렘 개발하는 형식과 관리하는 방식에 최적화 되어있으니까.

그러나 만든 것 자체는 누더기 골렘임.

If문에 천 줄 걸려있으면 오류나서 디버깅할때 욕부터 나오는거. 함수 부르는 비용 하나 아까울 정도의 극한의 속도를 요구하는 작업이라면 할 말은 없으나, 그 정도 비용은 현재 컴퓨터에선 버든이 0에 가깝고 가독성과 유지보수성을 지키는게 모든 비용면에서 봤을때 정답에 가까움

if 문 천 줄 걸려있던 모듈에 100줄이 걸려있던 오류가 나면 쓰레기지.

해당 개발자가 하드웨어 프로세스에 대한 이해가 전혀 없다고 밖에 볼 수 없음.

그것도 못하고 남에게 디버깅 맡길 개발자면 뭘 믿고 업무를 맡겨?

교육이나 시켜야지.

그리고 기존에 작동하다가 후에 패치 및 업데이트로 안 되는 거라면

인수인계가 제대로 안되었다는 이야기 밖에 더 됨?

그건 해당 조직이 문제가 있는 거지.

누더기 골렘 언어 쓰는 곳이라면 애초에 능력도 안되는데 그렇게 코딩하게 냅둔게 문제고

초급 개발자 쓰는 곳이면 코딩 수준도 초급도 이해 할 수 있을 정도로 낮추어서 제공해야지

그리고 if문 천 줄 내용 나눠서 함수로 처박았다고 천 줄이 100줄 되는 것도 아니고

디버깅 과정에서 라인 체크가 안 되는 것도 아니고

천 줄의 연산처리가 함수나 객체에 처박는다고 줄어드는 기적이라도 일어나?

함수에 처박던 객체에 처박던 천 줄은 천 줄이구요 분할을 해도 천 줄입니다.

그리고 해당 프로세스를 디버깅을 했다면 그 프로세스의 목적이 뭔지 알고 기능 명세서를 들고 있을 텐데

왜 욕이 나옴? 그 정도의 프로세스 이해도 밖에 없는 인간이 왜 디버깅을 하고 QA및 재 조정을 함?

그게 욕이 나올 수준이면 하지마. 너에게 맡기는 것 부터가 잘못 된거지

입력 보고 출력 보면 어느 정도의 연산 처리가 필요하고 코딩을 얼마나 어떻게 순차적으로 진행 될지

머릿속에서 떠오르는게 정상이지. 만약 일반적인 방식으로 처리가 안되어 있다면 그 이유를 찾아보고

테스팅 돌려보는게 순서고 그래야 쟁점을 찾고 왜 수정을 했는지 그리고 어떻게 개선을 했는지 보고를 할 거 아냐.

그냥 에러나서 유지보수 했습니다. 하고 끝낼건가?

라이브러리 패치 되어서 해당 버전에 맞게 수정했습니다.

전 버전으로 다운그레이드 했습니다. 이런건 초급 개발자들이나 하는 말이지.

운전면허도 없는 애들에게 운전대 맡긴격이잖아.

일단 시동걸고 엑셀 밟아집니다.

너 혼자 코드씀? 몇명이서 하는 작은 프로젝트면 조건문에 만줄 처박아도 상관은 없응. 근데 하드웨어 프로세스 다 이해하고 코드 이해 필요없이 기능 명세서 보고 완벽하게 할꺼면 코딩 컨벤션 왜 있음?

회사 오래다니는 방법: 나와 신만이 아는 방식을 고수한다.

이젠 신만이 아십니다

그만큼 시간을 줬음이 포인트네ㅋㅋ

그렇지ㅋ 그만큼 기록하는게 중요하니까 나중에 유지보수를 위해서 상세한 기록을 잘 남기라고 시간을 주더라고.

함수명 개좆같이짜네

와 우리 사수도 그렇던데

나도 그런코드 인계받아서 유지보수하는데

각 콤보박스 값을 DB에서 읽어와서 집어넣고 선택된 인덱스도 아니고 선택된 값으로 돌아가는 루틴이 너무 많은데

콤보박스마다 다 다른 프로시저에서(패키지도 다름) 읽어오니까 점심 나가서 먹을거 같더라.

쉬벌 그래서 여기 원래 들어가야되는 선택된 값이 뭐냐고 ㅋㅋㅋ 문서도 없어

선택값이 9라고? 9가 뭔뜻인데, 아 뭔진 모르겠고 9면 된다고? 마스터 입력하는 사용자도 모르는걸 내가 어케 알아 ㅋㅋㅋ

우린 변수에 itp1,2 3 sfile1,2,3 이딴식으로 해놔서 ㅅㅂ 짠놈만 알게 해놨어