많은 분들이 이사다시피 저는 서버 프로그래머입니다만, 습작이나 오픈 소스로 공개한 SDK등에서 간단한 게임들을 공개해온적이 있습니다. 기본적인 클라이언트 작업 이해도는 있는 편이지만, 실무에서 클라이언트 코딩을 해온 기간은 짧은편이지요. (렌더링을 제외한 로직 구현이나 네트워크 코드를 주로 작성해왔죠. UI와 인게임 코딩은 습작에서 해온게 대다수입니다.)


그런 제가 대략 8개월여간의 유니티를 통한 개발 경험에 대해서 정리해보고자 합니다.


1. 씬과 메타 파일로 인하여, 동시 작업이 어렵다.

- 4.x대까지의 유니티는 동시 작업이 불가능한 수준으로 보면 된다. 같은 파일에 대한 동시 작업은 피하는게 좋다. 이를 위한 소통 비용이 반드시 필요한 수준.

- 이런 문제로 인하여, 구조상으로 결합도를 낮추려는 노력을 하게 되기도 하지만, 피치 못할 사정이나 소통의 오류가 발생했을 때 한명의 작업 이외에는 날려야되는 문제는 그다지 좋은 상황은 아니다.

- 결국 우리팀은 파일별 작업자를 일감 분리를 통해 분리하는 룰을 가지도록 의도해, 통일한 파일 동시 수정을 피하곤 있으나, 많은 데이터를 아우르는 작업 자체를 기피하게 되는 큰 원인이기도 하다.


2. 프리팹은 가급적 동적으로 사용하는 것이 좋다.

- 씬에 올려두고 사용할 경우, 해당 프리팹 외부의 delegate도 물릴 수 있지만, 이렇게 될 경우 프리팹이 수정될 때 마다 delegate가 날라간다.[예: UIButton의 on_click]
- 그래서 애초에 동적으로 연결하게끔 코드와 UI간의 연결 정보를 관리하면 이를 유연하게 대처할 수 있다.

- 에셋 번들로 패치 시스템을 만들 때도 고려하면 이 방법이 더욱 좋다.


3. NGUI나 UGUI 둘다 편하긴하나, 위의 단점들로 인해 잦은 변경에 유연하지 못하다.

- 그럼에도 불구하고 UI 작업 자체는 여러모로 편의성 기능이 많고, 대다수의 UI 기능들이 이미 존재하는 것은 확실히 장점이다.


4. C#스럽기보단 스크립트언어 다루듯이 접근해야 하는 부분이 많다.

- C#의 기능들이 전부 구현되어 있는 게 아니다. 사실상 일부만 구현되어있따고 보는 것이 더 많다.

- 유니티 자의적인 해석대로 구성되어있는 요소도 꽤 있다.

- 사실상 C#의 문법만 가져왔다고 마음 먹는 것이 정신건강에 좋다.


5. 코루틴은 최적화의 해결책이 아니다.

- 멀티 쓰레드 쓰듯이 코루틴을 다룰 수는 없다.

- 그렇기에 결국 블러킹함수를 많이 쓸 수록 문제가 생긴다.

- 쓰레드에서는 유니티 함수를 사용할 수 없다.

- 그래서 결국 최적화나 블러킹 상황을 줄이는 데에 한계가 있다.


6. 씬과 프리팹 저장이 직관적이지 않다.

- 런타임에 변경한 정보가 바로 반영되는 점, 씬 단위로 실행 할 수 있는 점, 일시정지 할 수 있는 점등은 장점이다.

- 하지만 내가 유니티 툴에서 테스트한 상태 그대로 파일로 저장되어 있지 않을 수 있는 점은 외부 버전 관리 시스템 (git, svn 등)을 사용하는 입장에서 큰 혼란을 가져다 준다.

- 그래서 위에 언급한 대다수의 정보를 동적으로 연결하게끔 관리한다면, 많은 문제를 우회할 수 있다.


7. 모든 씬에서 정상동작하게 관리하는 것은 장단이 있다.

- 모든 씬에서 기능이 정상동작하게 하기 위해서는, 코드의 선행 조건을 만족시키기 위해, 애매모호한 룰을 세우게 되는 경우가 있다.

- 특히나 패치 시스템을 사용하고, 코드와 메타 데이터를 관리하는 경우가 특히 그런데, 가급적 실행해볼 수 있는 씬을 한정지어 스크립트의 전제 조건을 줄여주는 것이 좋다.


8. 예외처리 규약은 C++이나 C#으로 직접 제작할 때와 다르게 고민해봐야 한다.

- 유니티가 추상화 해놓은 레이어 위에서 예외처리 정책도 정해야 하기 때문에, 이를 감안한 예외 처리 룰을 세우는 것이 좋다.

- 특히 STL과 다른 동작을 하는 컨테이너가 많다. C++에 익숙한 사용자는 더더욱 컨테이너에 대한 레퍼런스를 다시 읽어보아야 할 것이다.



간략하게 정리해본 유니티 사용시 팁과 사견이었습니다.

아마도 한참을 더 사용하게 될 거 같은데, 그에 따른 여러 판단은 생각 날 때 마다 정리해서 공유해보록 하겠습니다.

'C# > Unity' 카테고리의 다른 글

유니티 개발에 대한 썰  (0) 2015.08.25
Posted by 엘키 엘키
 TAG 유니티

댓글을 달아 주세요

명언

가장 큰 약점은 약점을 보일 것에 대한 두려움이다 - 보쉬에우리는 종종 뭔가 나아지게 하려다가 괜찮은 것 마저 망친다 - 리어왕


지식에 대한 투자가 언제나 최고의 이윤을 낸다 - 벤자민 프랭클린

당신이 가진 생각이 딱 하나밖에 없다면 그것만큼 위험한 것은 없다 - 에밀 사르티에

언어의 한계가 곧 자기 세계의 한계다 - 루트비히 비트겐슈타인

진보라는 것은 변화와는 거리가 멀고 오히려 기억에 의존한다. 과거를 기억하지 못하는 사람은 과거를 반복할 운명이다 - 조지 산타야나

참으로 고통스러운 일입니다. 자신이 겪는 어려움을 보고는 알게 되죠. 다른 누가 만든 게 아니고 바로 자신이 문제를 만들었다는 걸. 소포클래스(아이아스)

상식과 정직만큼 사람을 놀라게 하는 것은 없다 - 랄프 왈도 에머슨

자기 비난에는 사치성이 있다. 우리가 자신을 비난할때, 다른 사람은 우리를 비난할 권리가 없다고 우리는 느낀다. - 오스카 와일드

좋은 울타리는 좋은 이웃을 만든다 - 로버트 프로스트

아무리 뛰어난 천재라도 세부사항에 집착하면 그 재능이 발휘되지 않는 법이다 - 레바의 8번째 법칙

주변을 둘러보니 변화와 쇠퇴뿐 - 라이트 “함께 하소서”

완성이라는 것은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 얻게 되는 것이다. - 생텍쥐페리

가끔은 망설이는 자가 재난을 모면한다 - 제임스 써버

생각없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다. - 알프레드 노스 화이트헤드

아무리 흐른 먹물이라도 가장 훌륭한 기억력보다 낫다 - 중국속담

Tip
자신의 기술에 관심과 애정을 가져라

자신의 일에 대해서 생각하면서 일하라

어설픈 변명을 만들지 말고 대안을 제시하라

깨진 창문을 내버려두지 말라

변화의 촉매가 되라

큰 그림을 기억하라

품질을 요구사항으로 만들어라

지식 포트폴리오에 주기적으로 투자하라

읽고 듣는 것을 비판적으로 분석하라

무엇을 말하는가와 어떻게 말하는가 모두 중요하다

DRY(Don’t Repeat Yourself) - 반복하지 마라

재사용하기 쉽게 만들어라

관련 없는 것들 간에 서로 영향이 없도록 하라

최종 결정이란 없다 (불변하는 결정은 없다)

목표물을 찾기 위해 예광탄을 써라(지금 무엇을 얼마만큼 하고 있는지를 확인하라)

프로토타입을 통해 학습하라

문제 도메인에 가깝게 프로그래밍하라

추정을 통해 놀람을 피하라

코드와 함께 일정도 반복하며 조정하라

지식을 일반 텍스트로 저장하라

명령어 셀의 힘을 사용하라

하나의 에디터를 잘 사용하라

언제나 소스코드 관리 시스템을 사용하라

비난 대신 문제를 해결하라

디버깅을 할 때 당황하지 마라

“Select”는 망가지지 않았다. (컴퓨터는 고장나지 않는다. 내가 코드를 잘못짠거다)

가정하지 마라. 증명하라

텍스트 처리 언어를 하나 익혀라

코드를 작성하는 코드를 작성하라

완벽한 소프트웨어는 만들 수 없다

계약에 따른 설계를 하라

일찍 작동을 멈추게 하라 (문제가 있을 때)

단정문을 사용해서 불가능한 상황을 예방하라

예외는 예외적인 문제에 사용하라

시작한 것은 끝내라

모듈간의 결합도를 최소화하라

통합하지말고 설정하라 (Config 기능을 따루 둬라. 코드에 상수를 박아넣지 마라)

코드에는 추상화를, 메타데이터에는 세부 내용을

작업흐름 분석을 통해 동시성을 개선하라

서비스를 사용해서 설계하라

언제나 동시성을 고려해서 설계하라

모델에서 뷰를 분리하라

칠판(개별 컴포넌트들이 모두 참조할 수 있는 공용 메모리공간)을 사용해 작업흐름을 조율하라

우연에 맡기는 프로그래밍을 하지 말라

여러분의 알고리즘 차수를 조율하라 (알고리즘의 대략적인 소요 시간을 예측하라)

여러분의 추정을 테스트하라

일찍 리펙터링하고, 자주 리펙터링하라

테스트를 염두에 두고 설계하라

소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다

자신이 이해하지 못하는 마법사가 만들어준 코드는 사용하지 말라

요구사항을 수집하지 말고, 채굴하라

사용자처럼 생각하기 위해 사용자와 함께 일하라

구체적인 것보다 추상적인 것이 더 오래간다

프로젝트 용어사전을 사용하라 (팀원들 간에 공통의 용어를 사용할 수 있도록 하라 - 의사소통의 효율을 위해)

생각의 틀을 벗어나지 말고, 틀을 찾아라

준비가 되었을 때 시작하라

어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다

형식적 방법의 노예가 되지 마라

비싼 도구가 더 좋은 설계를 낳지는 않는다

팀을 기능 중심으로 조직하라

수작업 절차를 사용하지 말라

일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라

모든 테스트를 통과하기 전엔 코딩이 다 끝난 것이 아니다

파괴자(고의로 만들어놓은 버그)를 써서 테스트를 테스트하라

코드 커버리지보다 상태 커버리지를 테스트하라 (테스트 할때, 개별 코드에 빠지지 말고 전체적인 맥락을 놓치지마라)

버그는 한번만 잡아라 (같은 버그가 계속 나와서는 안된다)

한국어도 하나의 프로그래밍 언어인것 처럼 다뤄라 (문서를 작성할때도 코드를 쓰는 것처럼)

문서가 애초부터 전체의 일부가 되게 하라. 나중에 집어넣으려고 하지 마라

사용자의 기대를 부드럽게 넘어서라 (사용자의 기대를 제대로 이해하고, 그것보다 약간 더 좋게 만들면 좋아한다)

자신의 작품에 서명하라 (스스로에게 부끄럽지 않은 코드를 만들어라)


Posted by 엘키 엘키

댓글을 달아 주세요

https://nssm.cc/


 nssm-2.24.zip


rails 서비스화에 사용한 배치 파일 예제입니다. 아주 간단해요.

윈도우 서버의 경우 권한 문제에 빠질 수 있는데, 이 경우 아래 링크처럼 대처하세요.

http://elky.tistory.com/561


Install_web.bat

pushd %~dp0

@echo off


%cd%\nssm.exe install %1 C:\RailsInstaller\Ruby2.1.0\bin\rails.bat "s -p 8000 -e production"

%cd%\nssm.exe set %1 AppDirectory %cd%



Start_web.bat

pushd %~dp0

@echo off


net start %1



Stop_web.bat

pushd %~dp0

@echo off


net stop %1



Uninstall_web.bat

pushd %~dp0

@echo off


net stop %1


nssm.exe remove %1 confirm

Posted by 엘키 엘키

댓글을 달아 주세요


service_wrapper.zip


콘솔 프로그램을 service로 등록해주는 instsrv, srvany의 wrapping batch 파일입니다.


사용법은 

install.bat "서비스명" "실행파일경로" "인자"


uninstall.bat "서비스명"


입니다.

Posted by 엘키 엘키

댓글을 달아 주세요

script/rails 파일이 존재하는지와 내용을 확인 해볼 것.


해당 파일에


#!/usr/bin/env ruby.exe

APP_PATH = File.expand_path('../../config/application',  __FILE__)

require_relative '../config/boot'

require 'rails/commands'



위와 같은 정보가 있는데, 이 정보들을 바탕으로 서버를 구동 시키려 하기 때문.


'Web > Ruby on Rails' 카테고리의 다른 글

Rails 5.0 Release  (0) 2016.07.02
vscode with rails  (0) 2016.04.14
rails aptana studio에서 디버깅 안될 때  (0) 2015.04.14
Rails를 이용한 웹 로그 서버 구축기 ver2  (0) 2014.12.16
Ruby on Rails 소개  (1) 2014.12.02
windows 환경에서의 mysql2 gem 문제  (0) 2014.11.12
Posted by 엘키 엘키

댓글을 달아 주세요

버그는 프로그래머의 숙명이다.

 

섬세하게 만들려한 IOS, OS X에도 버그는 종종 있으며, 사실 많은 사람이 M$ 부르지만 나의 경우는 매우 감사하고 있는 MS 경우에도 버그는 많다. 구글도 예외는 아니고. (구글 apps 초창기 패치할 마다  언어 관련, IME 관련 문제를 겪게 했던 일은 나름 유명한 일화다.)

 

이러한 회사는 분명히 업계의 엘리트가 모여있을 텐데 어째서 이렇게 버그가 나오는걸까?

 

어찌보면, 버그는 당연한 숙명이다.

 

하나의 어플리케이션을 작성하기 위해, 작성된 위지윅 툴을 사용하더라도, 버그가 없다고 단정 지을 없다.

하물며, 코드가 들어가고, 각종 코드를 재사용하고, 다른 코드를 얹는 과정에서는 복잡도와 결합도는 증가하고, 당연히 버그가 생길 여지도 많아진다.

 

그렇다면 버그를 없애려는 노력과 기반은 당연히 마련해야 할테고… (나의 디버깅 관련 글들은 대부분 주제에 대한 글로 이루어져 있다) 그렇게 했는데도 발생한 버그들에 대해선 어떻게 대처해야 것인가?

 

나는 대안으로 기록. 버그 노트를 작성해야 한다고 생각한다.

 

꽤나 많은 프로그래머들이 버그를 부끄러워한다.

숨기려고도 하고, 괴로워 하기도 하고.

 

하지만 나의 경우는 꽤나 많은 버그가 환경에 영향을 준다고 생각한다. , 기존에 작성된 코드가 버그의 수나 버그의 수위를 조절한다고 생각하고.

 

, 그렇다면 버그는 부끄러워 대상이 아니고 개선해야 대상이다.

 

그럼 하나 질문.

 

개선을 위한 습관으로  어떤 노력을 해보셨나요?

 

흔히들 하는 핑계가 경력이 쌓이면 저절로 고쳐져요같은 경험론이다.

주변 지인들과 수많은 얘기와 경험 해보고 내린 결론은 절대 버그는 경험과 비례하지 않는다. (물론 절대적 경험치나 기본기가 부족한 경우는 버그를 양산하기도 한다. 혹은 절대적으로 촉박한 일정도 그런 문제를 만들기도 하고)

 

오히려 위에 언급한 시스템이 버그를 줄여든다.

 

추가적으로 개인적인 노력도 반드시 필요하다고 생각한다.

나의 경우는 그런 의미로 버그 노트를 작성해왔다. 대략 9년여 되가는 습관은, 나의 버그 수를 줄이진 않았어도 같은 종류의 버그 재발은 급격히 줄여줬는데, 자체적인 회고를 주기적으로 거치는 것도 병행하는 덕택일거다.

 

반드시 자신의 버그를 돌아봐야 한다고 생각한다.

그러기 위해 버그 노트를 작성하고, 과정에서 기록되어야 것은 다음과 같다.

 

  • 현상
  • 추정
  • 과정
  • 원인
  • 해결책

 

항목을 채우다보면, 잘못된 해결책이나, 미흡한 원인 파악, 잘못된 추정등이 밝혀진다. (종종 잘못된 현상 보고도 있긴 하고)

 

그런 과정을 반복하다보면, 자신의 잘못된 습관이 보인다. 습관을 고쳐나갈 수록, 퀄리티 높은 프로그래머가 된다고 생각한다.

 

물론 이런 노력없이도, 좋은 퀄리티의 프로덕트를 만들어 내는 분들이라면 괜찮지만, 아니라면 버그를 줄이기 위해 버그 노트를 써보면 어떨까?


Posted by 엘키 엘키

댓글을 달아 주세요

꽤나 많은 상황에서 우리는 기존 코드를 분석해야 한다.

 

빌드업이라 불리는 프로젝트에 필요한 기능들을 만져나가는 과정에서도 우리는 라이브러리나, 오픈소스 코드등을 통해서 기존 코드를 분석해나가야 한다.

 

물론 과정은 섬세하게 만져나갈 여지가 있고, 그간의 결합도를 조절해나갈 여지가 있으므로 상대적으로 코드 분석의 여지가 적다.

 

심지어 사용하는 라이브러리들이 익숙하거나, generic하게 구현되어있다면 더더욱이 쉽고.

 

 

 

사실 가장 곤욕스러운 과정은 프로젝트 dependency 코드를 분석하게 때이다.

 

과정에서, 코드간의 결합도를 낮출려고 노력해온 흔적이 있는 경우는 그래도 상대적으로 쉬운 편에 속한다.

예를 들어 패킷으로만 다른 티어와 통신을하고, 패킷 핸들링 코드가 명확하다면 기존 코드가 난해하다해도 결합도를 풀어가는데에 상대적으로 수월하다.

 

하지만 진입점의 종류가 곳이고, 기능별로 핸들링 코드가 분리되어있음에도 객체간의 관계가 명확하지 않고, 쓸데 없이 복잡하게 보이는 일은 비일비재하다.

 

 

이럴때 당신은 어떻게 분석하는가?

, 인수인계를 위해 어떻게 준비해야 하는가?

 

많은 코드 분석과정을 해본결과, 지켜본 결과 많은 사람들이 두가지 방법정도로 코드를 분석하더라.

 

상향식 코드분석과, 하향식 코드 분석이다.

 

그림. , 전체적인 구조 설계의 전제 파악, entry point 분석, 스레드 디자인 분석과 같은 프로젝트의 룰을 파악하는데에 주력하는 것을 하향식 코드 분석이라 부른다.

 

반대로 컨텐츠별로 하나씩 기능들을 분석하며, 실제 컨텐츠별 사용중인 클래스들을 분석해나가는 것을 상향식 코코드 분석으로 부른다.

 

 

두가지 모두 적절히 이루어지면 좋겠지만, 사실 대부분의 경우 입사나 부서이동 직후 업무를 바로 진행해야되는 경우가 수두룩 하다.

 

이럴 경우 어떤 방법을 먼저 채택할 것인가?

 

나의 경우는 항상 하향식 코드 분석을 선호해왔다.

 

프로젝트의 , 전제를 모르고선 다른 코드들의 디테일을 봤을 , 코드가 과연 작성된 코드인지, 혹은 자연스레 녹아든 코드인지 판단도 안된다고 여겨서이다.

 

그렇다고 상향식 코드 분석이 나쁘다고 없다.

 

일관된 규칙으로 코드가 관리되어왔고, 간결하면 간결할 수록, 상향식 코드 분석이 빛을 발하기 때문이다.

 

하지만 그런 상황은 그다지 자주 벌어지지 않는다. 어찌보면 작성되어있는 코드 양이 많으면 많을수록 이상론적인 이야기이고, 꽤나 많은 경우에는 하향식 코드 분석을 선행하고, 이후 상향식 코드 분석으로 전환하는 과정이 옳다고 본다.

 

여기에 문서화에 대한 이야기를 빼놓을 없다.

 

그렇다면 인수인계 자신의 작업 기록을 위한 문서화는 어떻게 해야 하는가?

 

나는 작업 규칙과, 설계 기준을 명세하면 충분하다고 생각한다.

작업의 디테일은 고생한 과정을 기반으로 기록해 수록 좋다.

만약 두사람 이상이 같은 작업 과정에서 고생했다면, 작업 자체가 집중을 요하는 작업이거나, 혹은 실수의 여지가 많은 빈틈있는 기반 작업이 되었다는 것을 (혹은 그러한 툴이나 라이브러리, 코드 등을 이용하거나) 의미하기 때문이다.

 

겪었던 문제들에 대한 기록만 취합되어 있더라도 상대적으로 많은 시간을 아낄 있다고 생각한다.

그래서 나는 버그 노트를 작성하기 시작했는데, 이에 대한 이야기는 다음 글에서 이어서 하려 한다.


Posted by 엘키 엘키

댓글을 달아 주세요

내가 코드를 작성할 때 신경쓰는 코딩 규약들을 정리해본다.

 

소유권

  • 객체의 소유 주체는 (생성과 소멸의 관리 주체는하나로 규정한다.
  • 객체의 생성,소멸 스레드도 하나로 규정한다.
  • 다른 클래스에서 호출되어야만 하는 메소드를 만들지 말라.
  • Has a 관계가 명확하다면 관계를 혼란 시킬  있는 메소드는 절대 만들지 마라.

 

진입점

  • 진입 점은 명확하게한곳으로 관리하자
  • 만약 다양한 진입 점이 있을  밖에 없다면다른 각각의 진입 점에서 왔음을   있게 하라.

 

중복

  • 중복을 허용하지 말라.

 

단일 규칙

  •  가지 이상의 규칙을 허용하지 말라새로운 규칙을 도입하고 싶다면기존 규칙대로 작성된 전부를 고쳐라.
  •  가지 이상의 규율이 존재하는 것은코드 작성/분석  모든 과정에서 해가 된다.

 

전치 검사, 후치 검사

  • 메소드는 정상적으로 실행되기 위한 선결 조건에 대한 검사를 해야 한다.
  • 메소드는 정상적으로 실행되었을 때의 기대 값을 충족 시키는지 검사해야 한다.

 

호출 주체

  • 누가 호출해도 문제가 없는 메소드만 외부로 개방하라.
  • 만약 특정 클래스에서만 호출해야 정상 동작한다면, 잘못된 설계이고, 잘못된 사용법을 제공하는 것이다.

 

호출 순서

  • 호출 순서에 영향을 주는 코드는 지양하라.
  • 피치 못할 사정으로 함수의 호출 순서가 일정해야만 한다면, 정해진 호출순서대로 실행하는 상위 함수를 만들고, 내부를 숨겨라.


Posted by 엘키 엘키

댓글을 달아 주세요

이전버튼 1 2 3 4 5 6 7 ··· 45 이전버튼

블로그 이미지
Software Engineer
엘키

공지사항

Yesterday31
Today27
Total1,605,481

달력

 « |  » 2020.8
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

글 보관함