운영 오픈전 베타 테스트를 해야 한다. 테스트에서 잘 될거라 생각 해도 막상 운영에 올리면 안된다. 보는 사람마다 이게 아닌데.. 할 수 있다. 베타 테스트때 잡아야 편하지 실제 오픈하고 버그 잡을려면 잡을 수도 있겠지만 싫은 소리듣고 힘들게 해야 한다. 기획단계에서는 요구사항을 받지만 끝날때쯤에는 안정화에 힘쓰고 수 많은 요구사항은 고도화나 운영에 넘겨야 한다. 그러지 않으면 프로젝트가 끝나지 않는다. 또한 팁은 운영에서 테스트 하기 힘들기 때문에 오픈전에 운영데이터를 테스트 DB에 엎어달라고 요청한다. 저녁 6시쯤. 그럼 그 데이터 가지고 배치테스트를 하면 편한다. 괜히 새벽배치 때문에 아침일찍 나와서 힘들게 하지말고... 그리고 통합테스트를 모두 같이 해야 한다. 무조건 버그가 나오게 되어 있다. ..
프로젝트, 개발 기간은 길게 가져가는게 좋겠지만 (정확한 표현은 개발,테스트에 필요한 충분한기간) 비용이 문제라 무작정 길게만 가져갈 수는 없다. 그래서 적절한 시기로 타협을 하는데.. 문제는 너무 짧은 기간을 잡아서 프로젝트를 밀어 부치는 경우다. 물론 그렇게 해도 어떻게 밤을새던, 주말 출근하던 무리하게 할 수는 있겠지만 과연 퀄리티가 좋을까? 엿이나 먹어라 하고 소스를 복잡하고 엉망으로 만들어 놓을 수도 있다. 이런 소스를 가지고 운영을 하면 당연히 결과는 불보듯 뻔하다. 고생길이 열려있다. 그래서 개발,테스트할 시간을 충분히 갖는것이 중요하다. 그러나.. 하나 맹점은 개발, 테스트 기간이 충분하다고 할지라도 노는 개발자가 있을때 문제가 발생한다. 대부분의 사람들은 돈을 받고 일하면 최소한 돈값을 ..
실제 개발이나 프로젝트에 투입되서 일하다 보면 대부분이 테스트 환경을 구축해서 하나 일부 사람, 업체들은 테스트를 왜 구축해? 이런 사람들이 있다. 왜 불필요하게 테스트 환경을 구축해? 나 참 이런 XXX 꼭 이런 사람들이 사고친다. 물론 테스트 환경 구축을 하지 않고도 개발 할 수도 있다. 그러나.. 충분한 테스트 없이 운영에 올려면 이런 저런 문제가 발생한다. 그러니 테스트에서 이런저런 충분한 테스트를 하고 운영에 올려야 한다. 운영에서 올려서 테스트할 수도 있겠지만 테스트환경 처럼 충분한 테스트를 할 수 없는것은 자명한 일이다. 문제가 생겼을때 테스트환경에서 재빨리 수정해서 올리면 될것을 운영에 올려서 테스트하고 수정하고 또 운영에 올려서 테스트하고.. 이게 뭔지..
디자인패턴이다 MVC 다 등등 여러가지 개발관련 철학들이 나와 있지만 막상 현장에서 해보면 가장 개발자가 작업하기에 가장 편하고 쉬운게 뭘까 연구해본다. 일단, 공통 모듈. 물론 공통모듈의 장점이 있다. 하나만 수정해도 여러군데서 다 적용되기 때문에 편할 수 있다. 그러나.. 사람들의 요구사항은 끊임없이 변한다. 그래서 공통모듈에 if else 써가며 해보지만 소스는 점점 복잡해지고 추적하기 짜증나기 시작한다. 물론 이렇게 피곤해지면 테스트도 덜 하게 될것이고 장애로 이어지는 지름길이다. 그리고 무슨 패턴이라는 둥 해서 이동이 많고 복잡하게 하는 경우가 있다. 이런 경우도 피곤하다.. 그래서 공통모듈은 최대한 값이 불변하는 경우를 제외하고 안쓰는게 좋다. 그냥 따로 분리해서 가는게 속 편하다. 공통으로 ..
- Total
- Today
- Yesterday
- 이클립스
- proc
- 스크래핑
- XE
- JDBC
- ocajp
- 인포믹스
- ocjap
- 플러터
- C언어
- 라이믹스 모듈
- C
- webix
- MySQL
- 문자열
- 자바
- 파싱
- 파이썬
- KG
- Python
- xe addon
- xe애드온
- esql
- php
- 포인터
- 자바 smtp
- 프로씨
- EC
- 오라클
- XE3
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |