괜히 기본기본 하는게 아님. 기본은 단기간내에 쌓기도 힘들다
이걸 고리타분하다고 생각되는게 타당할수도 있음. 요즘 시대는 패스트 전략이니깐.
그치만.. 문제 해결 방법같은걸 왜 생각하냐고 그냥 가져다 쓰면 되지라는 마인드는 도저히 납득이 안가네
너는 그럼 돌아가기만 하고 빠르게 만들수 있으면 장땡이라는거냐? 그럼 PHP나 쓰던가
가져다 쓰면 장땡이라는 마인드 극혐
소쿠릿(sokcuri)
2016-02-23 08:33
추천 2
댓글 80
다른 게시글
-
어떤 온라인 리듬게임 어플리케이션의 api를 빌려쓰려는데 [2]맑탉앉핝꿇..(110.70) | 16.02.23추천 0
-
세상은 생산성좋은넘을 원하지. 10선비마냥 고리타분한 선비를 원하지 않음 [7]익명(203.228) | 16.02.23추천 0
-
최호성의 열혈강의c 책 보면서 감명깊었던 구절 [11]ㅇ(183.96) | 16.02.23추천 2
-
와 정말대단하네요 ㅁ [1]옥정요(120.237) | 16.02.23추천 0
-
사람은 필요에 의해서 발전하는 동물이다 [3]소쿠릿(sokcuri) | 16.02.23추천 1
-
template 에서의 ++ operator 오버로딩 질문있어여 [4]whatugonna..(sibal214) | 16.02.23추천 0
-
바로여기가 제일인곳! ㅅ [1]남궁준우(117.149) | 16.02.23추천 0
-
프로그래밍 배운지 1주일차에 첫 프로그램 만들어봄ㅋ [3]ㅇ(183.96) | 16.02.23추천 0
-
디시한다고 친구인거는 아니랬는데 [1]삼댕(39.7) | 16.02.23추천 0
-
디시에 답글 달기가 필요 [2]삼댕(39.7) | 16.02.23추천 0
기본적인 방법론이야 다 아는데 뭘 그리 연설을 하세요? 취업은 하셧어요?? 연설은 언제까지 하시려고??ㄷㄷ
뭘 안가져다쓰면 본인이 다 만들어서 내줄기세 ㄷㄷㄷㄷㄷ
아 그래요? 그래서 생산성=필요하면 갖다 쓰는 것이 전부? 소프트웨어 공학론 제대로 수강했으면 이런소리 절대로 못하는데
아니 무슨 내가 가져다 쓰지 말라고 했냐 개노답
봐라 이런놈들이 바로 옆에 있는사람까지 짜증나게 만드는 개병신 이론충ㅅㄲ임ㅇㅇ 10선비라는것도 대갈빡 좋은새끼들이나 10선비질 해야지 원....
단기적으로 볼 때 가져다 쓰는 방식은 훌륭한 방법론이 맞음. 그런데, 코드를 가져다 쓰려면 거기에 따라붙는 라이센스나 혹은 나에게 불필요한 부분의 소스코드라거나, 그것을 수정 가공하기 위해 들어가는 노력이 추가로 들어가는데, 이것은 코드를 처음부터 만드는 것에 밀리지 않음
소프트웨어 공학을 수강했냔다...........................ㄹㅇ ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ개그맨이 따로 없으시넫ㄷ
가져다 쓰더라도 좀 알고 쓰라는게 그렇게 이해하기 힘든 말이야? 그걸로 이론충 어쩌고 하네 ㅋㅋㅋ 내참
소프트웨어 공학의 기본 전제가 유지보수와 생산성을 높이기 위한 큰 틀을 배우는건데 이건 뭐 재대로 배우도 안한놈이 어서 선비질 ㄷㄷ 닥치고나 있으면 무식한거 티라도 안남 ㅇㅇ 그냥 닥치고 있어염ㅇㅇ
10선비 지식 수준 ㄷㄷ
당장 필요하다고 생각없이 막 가져다 쓰다간 리팩토링의 지옥에 빠지던가 덩치는 엄청 커져서 유지보수 힘들어진 기형적인 프로젝트만 양산하게 되는 꼴이지. 아 그리고 지금이 어느시댄데 LOC로 생산성 따지고 자빠졌냐
즉 특정 기능이 돌아가기만 하는 수준으로 작성을 한다면 당연히 가져다 쓰는게 맞음 그런데 이것을 제품수준까지 끌어 올리려면 직접 작성해야 할 경우가 많아짐. 웃긴건 가져다 써야 하는 코드의 난이도가 엄청 높으면 또 코드를 가져다 쓸 수 밖에 없는데, 이런 코드들은 대부분 로열티를 물어야 하는 경우가 많음
아 그래서 필요하다고 막 가져다 쓰시는게 유지보수성이 높다고 말씀하시는거? 최소한 뭐가 좋은지 알려면 시간복잡도 계산정도는 해야할텐데? 그러려면 따져야 하는거 아닌가 그냥 막 가져다쓰라네 ㅋㅋㅋㅋㅋㅋㅋ 기적의논리
라이브러리의 문제는 라이브러리의 종속성 문제뿐만이 아니라 버그까지 일일히 확인해야 하는 문제도 있음. 단순히 가져다 쓰면 끝? 이게 아니라는거야. 상용 수준까지 올리려면 이런 부분까지 QC를 거쳐야 하고. 결국 라이브러리의 수정까지 가는 경우가 생긴다면 어쩔건데? 라이브러리를 그 시점에서 바꿔? 어림도 없는 소리 ㅋㅋ
이상으로 알고리즘의 알자도 모르는 10병신선비의 연설을 마치겠습니다. 들어주신다고 고생많으셧습니다. 여러분
가만히 닥치고나 있으면 욕이나 안처먹지 ㅇㅇ 교수들도 갖다 쓰라고 하는판에 뭔 개병신새끼가 기어들어와가지고 갖다쓰면 되네 안되네 허삿노 ㅋㅋ
위에 내 댓글 자세히 읽어보세요. 단순히 가져다 쓰면 끝이 아니라고 쓴 거잖아요;
야 너 솔직히 이런식으로 희열느끼는거 웃기지 않냐. 사람 하나 비아냥하고 깐다고 니 격이 올라가든
그럼 너는 그냥 가져다 쓰면 되겠네 아니 무슨 졸업작품 수준의 프로토타입이나 습작정도를 대면서 세상은 생산성 좋은놈들을 원한다~ 라이브러리는 가져다 쓰는거다~ 알고리즘 몰라도 된다 이딴소리를 하고 앉아있냐 너 프갤에 왜있냐 ;;
사람들이 착각을 하는게, 라이브러리를 가져다 쓰면 개발 난이도가 낮아질 것이다라는 건데, 절대 그렇지 않음 그 라이브러리 떄문에 이쪽 코드에 제약사항이 늘어나서 개발 난이도는 몇배로 뻥튀기됨
그러게여 교수님들도 라이브러리에 있는게 더 정확한거라고 직접 만들지말고 갖다 쓰라고 하는데 먼 병신이 와서 선비질을 해대네요 ㄷㄷ
아뇨.. 저는 위에서 부터 쭉 소쿠릿 님 말이 맞다고 하는 건데요...
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
IT바닥에는 옆에있는 사람도 짜증나게 만드는 저런 병신선비들이 있습니다. 아는것도 없음서 선비질을 해댄달까요 조심 또 조심 ㅇㅇ
저기 203님 님 개그맨이죠 대체 님이 말하는 IT바닥은 어디있죠 대학교 강의실 바닥인가
그런데 그렇다고 해서 직접 짜는게 무조건 옳은 것은 아님;
뗄감들이 뭘 알겠나요 그냥 그렇게 변변찮은 싸구려 도구로서의 삶 살다가 죽게 냅둬요
여기 흉들은 오픈소스를 제대로 풀젝에 도입해서 써보긴 한건지 의문이넹. 적용해서 문제가 있으면 방법은 여러가지염. 첫째 이슈 트랙커에 문제에 대한 경로와 현상을 올리고 누가 패치해줄때까지 기다린다. 둘째 본인이 보고 수정해서 풀리퀘스트 요청함. 셋째 회사에서 패치 오픈을 허용 안하면 라이센스 이슈는 없는지 확인해서 대처
제 주변 직원들을 보면, 초급은 라이브러리를 끌어다 쓰고요. 중급은 직접 짭니다. 그런데 고급은 다시 끌어다 쓰기 시작하더라구요;;
첫째로도 충분한게 아주 액티브한 플젝트는 흉들이 피드백해줌. 개꿀
확실한건 라이브러리의 동작이나 구조에 대한 이해없이 끌어다 쓰기만 하면 나중에 탈남. 그걸 말하는거에요. 해결 방법이야 codingm님처럼 많죠. 저나 달빛님은 가져다 쓰면 좀 알고 쓰라는거지 쓰지 말라는게 아님;;
근데 보통은 가져다쓰는 닝겐의 문제일 확률이 매우 높다. 그건 본인 스스로가 가져다 쓰고 문제가 발생했을때 최소한 자기는 문제없이 잘 썼다는 확신은 가질 수 있어야함
codingm.// 훃 말이 맞음. 그렇지만 그게 되지 않는 경우도 많이 있음 오픈소스에서 의도한 목적대로 쓰는 경우도 있지만 저 쪽에서 의도하지 않은 목적으로 쓰는 경우(자체 보드에 포팅하여 발생한 이슈라거나..)에는 수정요청도 어려움
첫째 문제의 양면성이 있는데 그정도로 액티브한 프로젝트는 누군가 버그리포트를 했을 가능성이 높고 구조라던가 여러가지 문제로 Pending되는 이슈들이 적지 않다는거죠. 그리고 좀 마이너한건 피드백 그딴거 없어요 그래서 좀..
기본적인 동작이야 다 알고 갖다 쓰는게 기본인데 뭘 그리 으름장???ㅇㅇ ㄹㅇ 10선비라 할말을 잃으셧남;;ㄷㄷ
먼 글쓰는거 보면 교수보다 뛰어나서 아주 초빙교수급??? 되는거마냥 나불거리는데 실상은 병신일듯 ㅇㅇ
내가 경험이 일천한 것이긴 하지만, 오픈소스의 경우 기능 자체는 클리어 하게 잘 돌아감. 그런데 우리 프로젝트의 요구조건에 맞추기 위해 커스더마이징을 진행하려고 하면, 결국 그 라이브러리 소스를 분석하고 수정하는 과정이 필요하게 되는데, 그 시간과 비용이 직접 만드는 것 보다 많은 경우가 꽤 있음
자체보드 포팅이라는게 보통 오픈소스의 기여인데 그리고 나서 메인스트림으로 가느냐 못 가느냐의 이슈인거고 메일링에 질문질하면 흉들이 잘 알려줌. 엑티브하지 않는 프로젝트가 좀 문제가 많죠.
아니 나도 부족한거 많고 배우는 입장이라 여기 횽들한테 도움도 많이 받는 입장인데 너는 좀 문제있는것 같아서. 기본적인 i/o는 아니깐 라이브러리를 쓰겠지만 라이브러리에 대한 이해가 동반되어 있음? 그런거 없이 필요하다면 막 가져다쓰는건 문제라는거잖아 차근차근좀 읽어보지
codingm// 어... 이건 좀 부끄러운 이야기 이긴 한데.. 좀 작은 업체의 프로젝트들은 대부분 오픈소스를 가져다 쓰면서 기여할 생각들이 없으신 경우라.....
라이브러리에 대한 이해라는 말이 좀 와닿지 않는다. 솔직히 도메인이 달라서 그런가 난 라이브러리에 이해보다는 프로젝트 엑티비티를 우선으로 보고 걍 가져다씀. 솔직히 라이브러리를 이해하려면 해당 도메인에 대한 지식이 풍부해야할텐데 난 머가리가 나빠서
음... 그러니까 이런거죠.. 문제있어? 그럼 오픈소스 가져다 해결해! 그런데 우리 코드는 유출금지! ;;;
많이 쓰인다던가 등으로 검증이 되었다면 그렇게 해도 별 문제는 없겠죠. 근데 저같은 경우는 마이너한걸 많이 만져봐서 그런가 희안한 버그들을 많이 만나봐서..
흠 뭔가 대화가 이상하게 가는데
달빛연구자 / 안타깝네요 오픈소스=공짜 정도로 생각하는 분들이라..
애초에 대충 돌아간다는 것 자체가 프로덕션에 적용해도 문제가 없다는거 아님? 난 그 논지로 말한거임
소쿠릿흉말대로 마이너한 플젝은 피드백받기도 어렵긴해서 도메인지식이 없는 경우는 무조건 피해야함
아뇨 203 저분은 생산성을 위해서 그냥 가져다 쓰면 된다고 하는거고. 그 뒷감당을 전혀 생각 안하는터라 그걸로 얘기하고 있던거에요
대신 마이너한 문제라도 커뮤니티 드리븐 성격이 강하면 흉들이 잘 답변해줌
아 그런곳 좀 부러워요 동병상련이랄까 ㅋㅋ
소쿠릿 : 예 대충 문제없이 돌아가면 걍 엑티비티한 오픈소스 가져다쓰면 되죠 ㅎㅎㅎ
아하... 저는 일단 돌아간 후에 고객 요구에 맞추어 커스터마이징 한다면 (영상채널 사이에 특별한 데이터를 넣는 다거나 등등) 혹은 우리쪽 보드나 서버 환경에서만 발생하는 문제라거나;;; 이런식의 뒷감당이 어려운 면이 있다는 점을 말하고 싶었어요
그정도 뒷감당이 안되면 어차피 홈즈루로 만들어도 마찬가지일거임여
음.. 대충 이런거죠. 우리 웹서버를 만들어줘! -> 아파치를 깔았다 -> 자 이제 이걸로 보드위의 실행프로그램을 제어하자!! ->?!
이야기가 산만해 졌으니 일단 제 주장을 정리할게요..
흠 제 말은 오픈소스를 가져다 쓰다가 커스터마이징에서 A문제 발생->수정 이지만 그게 불가능한정도면 인하우스개발->셀수없는문제발생->A'문제 발생일 확률이 매우 높음
결론은 오픈소스 가져다가 뒷감당 안될 정도면 인하우스로 첨부터 개발해도 프로젝트 망
정리끝
사실.. 오픈소스가 낫냐 인하우스가 낫냐는 문제가 논의의 중심은 아니었어요. 최소한 로직이 어떻게 돌아가는지 알고 통제할수 있어야 한다는거였는데. 이해 없이 막 코드 짜서 돌아가기만 하면 된다는건 위험하다는 것
근데 난데없이 라이브러리 쓰라는데? 이래버리니 좀 당황스러울수밖에 없는거죠.
1. 오픈소스 끌어다 쓰는 것은 옳다. 2. 그러나 오픈소스를 끌어다 쓴다고 해서 무조건 개발 난이도와 비용 기간이 절약되는 것은 아니다. ( 복잡도와 뒷감당 문제) 3. 이런 이유로 개발자가 직접 모듈을 개발해서 돌파해야 하는 이슈가 존재한다.
소쿠릿 : 닌겐이 모든 도메인 지식을 가지기는 불가능하기때문에 로직이 어떻게 도는지 다 아는건 애초에 불가능. 그정도로 검증하려면 해당 도메인 지식을 가진 전문가가 코드검증을 시일을 꽤 소요해서해야하는데 무리염.
지적허영심 + 학력에 대한 열등감 + 학식충
codingm님 말씀이 대부분 맞긴 한데 오픈소스의 커스더마이징이 인하우스 개발보다 어려운 경우는 매우 많이 있다고 봅니다. 역으로 일정 수준의 인하우스 개발을 수행하지 못하는 개발자가 오픈소스의 커스터마이징을 제대로 수행할 수 있다고 보지는 않아요. 오히려 오픈소스를 가져다 쓰다가 문제 발생! -> 회피코드에 의한 더 많은 문제 발생! 이런식이 되는 경우도 많이 있습니다.
학식충이나 2년 이하 경력을 가진 잉여인가보네
잘못 말했네요 ㅠ 그런뜻이 아니었는데.. 음..
@달빛연구자 : 흉 애초에 회피코드에 의한 더많은 문제 발생!의 능력이라면 흉이 얘기한 인하우스 개발을 수행하지 못할 개발자들이 많을거예요..결국 흉이 얘기한게 예기치 않은 사이드 이펙트인데 같은 인력이라면 결국 인하우스에서도 발생할 여지가 높음
@달빛연구자 : 그리고 흉말대로 커스터마이징이 더 어려운 경우 많긴 해요. 너무 구조가 복잡하고 방대해서 어디 건드리면 하부 시스템에 의도하지 않는 문제를 일으킬 수 있는.. 근데 또 그렇게 복잡한 애들은 액티브할 확률이 매우매우 높고 여러가지 방법으로 workaround가 아닌 방법으로 회피할 수 있는 방법들을 대부분 제시해주고 있음.
실무에서 프로젝트가 너무 비대하다던가 커스터마이징의 난해 등의 이유로 직접 모듈을 개발하는 편이 이득인 경우가 적지 않나요?
@달빛연구자 : 근데 그정도 규모의 오픈소스를 인하우스로 개발하려면 비용(머니든 일정이든)이 만만치 않을텐데 대부분의 회사에서 그걸 수용하기는 힘듬.
보통 이런 경우도 오픈소스 커스터마이징으로 해결하는 편일려나..
음.. 실 예를 들면.. 동영상 스트리밍 서버를 만들자! -> FFMPEG을 끌어다 쓰자! -> 그거 써본놈 있음? 없음! -> 인터넷에 문서 있음? ->어.. 별로 없네?! -> 영어 되는놈 있음? -> 없음! ->미나엏;미낭ㄹ;ㅗㅁㄴ오; ->그냥 제가 HLS랑 웹서버 스펙보고 만들게요...ㅠㅠ
라이브러리를 가져다 쓰시는 분들이 가끔 빠지는 함정이 이런게 있는 것 같아요. 동영상을 10초 단위로 자르는 기능이 필요하다! ->어? FFMPEG에 그 기능있어! -> 헉.. 그거 쓰자고 FFMPEG을 포팅하자고?! -> 이슈발생! -> FFMPEG가 이렇고 저래서 못고치겠어요 ㅠㅠ
거대한 라이브러리중에서 내가 필요한 기능은 소수인 경우가 많.. 저도 ㅠㅠㅠ
요즘도 ffmpeg 포팅 이슈가 있음? 뭐지;; ffmpeg은 코덱 라이센스 이슈 말고는 요즘은 문제 안될것같은데 저야 거의 메이져한 아키나 플랫폼에서 써서;;
아님 libav랑 정치적인 이슈
소쿠릿 : 제가 쓰는 것들은 모듈화가 잘 되서 코어랑 필요한 모듈만 가져다 쓰면 되는게 대부분이라 데헷!
제가 용어를 좀 모호하게 썻는데요. 포팅레이어의 함수를 작성한다는 의미의 포팅이 아니라, 그냥 단순히 빌드하는 곳에 FFMPEG의 빌드트리를 붙인다고 보시면 될 것 같습니다.
입장을 마지막으로 정리하면 이렇습니다. 1. 라이브러리가 방대하고 그 기능을 대부분 써야 한다면 위에서 열거한 어려움 모두 감수하고 당연히 라이브러리를 써야 함 2. 그러나 라이브러리에 포함된 일부 기능을 사용하기 위하여 라이브러리를 사용하는 것은 그리 좋은 결과를 가져오지 못함
http://lgstar.tk
커뮤니티 사이트 입니다 많은 이용 부탁 드립니다. - DCW