//TODO: making row to be 10times bigger.
func spritePositionCalculator4move(column: Int, row: Int) -> CGPoint {
let x = LayerPosition.x + (CGFloat(column) * GS.s.blocSize / 2 ) + 25
let y = -(CGFloat(row) * 10) - 120
// debugPrint("hjhXYCalculator : row(\(row)), y = ", y)
return CGPoint(x: x, y: y)
}
요구 사항이 바뀌면 사실 바뀌는게 엄청 많은데...
보통 믿는 관계에서는 요구 사항이 바뀔 것을 미리 예측하지 못한다.
믿음이 깨지는 경우는 산출물을 보고 욕심이 생기는 경우이다.
뚝심있는 기획자가 있으면 정말 다행인데, 보통 기획자라고 불리는 직책도 시키는 대로 문서를
만드는 경우가 고작인 경우가 많다.
정말 고객의 입장에서 만들어 지고 교체되어야 할 사항이라면 개발자의 야근은 오히려 즐거울 것이다.
예를 들어 블럭을 없애는 것이 아니라 한 칸 내리는 구현도 그렇다.
/ let hjhAction002 = SKAction.scale(to: 0, duration: 0.5)
atomicSprite!.run(SKAction.sequence(
[
// SKAction.group([hjhAction002]),
SKAction.moveTo(y: (GS.s.gameScene?.spriteYpositionCalculator_(row: vY+1))!
, duration: 0.5)]
))
자 이 코드로 한 칸은 내려졌다. 없애는거 주석처리하며 액션 그룹에서 빼버리고 옮긴다.
spritePositionCalculator_ 를 써도 되지만 불필요한 연산이 들어가니
func spritePositionCalculator_(column: Int, row: Int) -> CGPoint {
let x = LayerPosition.x + (CGFloat(column) * GS.s.blocSize / 2 ) + 25
let y = -(CGFloat(row) * GS.s.blocSize / 2) - GS.s.blocBottomLocationConstant
if(GS.s.logLevel == .location) { debugPrint("hjhXYCalculator : row(\(row)), y = ", x, y) }
return CGPoint(x: x, y: y)
}
를 떼서
func spriteYpositionCalculator_(row: Int) -> CGFloat {
return -(CGFloat(row) * GS.s.blocSize / 2) - GS.s.blocBottomLocationConstant
}
게 만들었다.
이걸로 끝인가?
블럭이 들어가는 자료 구조도 바꾸어야 한다. 코드가 바뀌면 side effect, 개발자들 끼리는 "사이드"라고 불리는 것 때문에
또 테스트 들어가고 모듈이 크면 기존에 잘 되던 기능도 모두 테스트 해야 한다.
그렇다.... 누군가 말했다.
구글 이미지 검색하니 누가 벌써 이미지랑 엮어서 만들어 놓았네.
ㅋㅋㅋㅋㅋ
가령 나 같은 경우 어느 정도 이야기가 된 다음 결론은 아이들을 위한 게임이라고 해서 정말 즐겁게 개발하고
수 없이 바뀌는 요구사항도 모두 수용 했는데 나중에 초반에 이야기 되었던 회의 내용은 다 사라져 버리고,
결국 제일 처음 아이디어로 다시 돌아 갈 때 정말 일하기 싫어서 몇 달을 놀았다.
기업에서 월급 받으며 가장 오래 논 기억은 8개월인데 그 때 오버워치 처음 시작해서 회사에서 한 것으로 금장까지 달았다.
1080이라서 라서 좋았다. 뭐, 물론 커널 패치나 임베디드, 엔진쪽도 다루는 광범위한 스킬로 눈 가리고 아웅할 수 있는 경우가
많았기 때문에.
최근에 대기업 와서 일하면서도 아주 뛰어난 시니어 엔지니어 분이 몇 달 동안 로그만 고치면서 놀고 있다는 말을 술자리에서
해 주셨다. 내 이야기를 한 것도 아닌데 내가 참 마음에 들었는지 진심을 이야기 해 주셔서 ... 고마웠다. 물론, 그 분은 한번 일하면 야근, 특근은 별 생각 안하고 완벽한 산출물을 내시는 오랜 프리랜서 실력자 시라 이렇게 적어도 괜찮다.
내가 하고 싶은 말은...
개발자가 논다는 기준은 다 다르겠으나, 논다고 해서 일을 안하는 것은 아니다.
그러나 정말 영혼까지 불탈 수 있는 프로젝트로 세팅하느냐 마느냐는 진심어린 커뮤니케이션에 달렸다고 보면 되겠다.
회사에 엉덩이 붙이고 있는 거야 개발자 기본 스킬이다. 어렵지 않다.
문제는 그게 중요한게 아니니까
700명 몽땅 원격근무해도 잘 되는 회사
700명이 일하는데도 사무실 하나 없고 그럼에도 어도비에 대적할 만큼 성장한 소프트웨어회사 인비전. 대체 어떻게 가능했던 것일까?
www.ttimes.co.kr
이런 회사가 나오는 것이다.
원격 근무 잠깐 도입해 보고 실패하는 스타트업 많이 봤는데
실패의 이유는 딴 것 없고,
그냥 구라다.
그렇게 할 마음도 없으면서 시도하는 척.
회의 하면서 다른 사람 말 들어 주는 척.
하고 결국 지 꼴리는 대로 한다.
뭐, 대부분 남자들이 그래서 아~주 정확한 표현을 적었다.
꼴리는 대로 하고 싶으면 회의 하지 말고, 그냥 혼자 기획하고 개발하고 테스트하고 퍼블리싱하면 된다.