좋은 소프트웨어는 사용자가 원하는 것을 주어야 한다. 그러려면 사용자의 요구를 잘 분석해야 겠다. 경제성도 따져보아야 한다. 정해진 가격과 시간으로 만들어야 하기에. 이를 위해 적절한 소프트웨어 아키텍쳐를 생각해 보아야 한다.
좋은 소프트웨어는 SW적 품질이 좋아야 한다. 이해하기 쉽고, 간결하고, 유지보수 쉽고, 성능 좋게 짜여진 프로그램이 좋은 품질의 SW이다. 좋은 품질은 좋은 프로그래머가 만든다. 좋은 프로그래머는 프로그래밍을 단순히 code를 배설하는 행위라 여기지 않는다. 레고 블럭 쌓기 같이, 예쁜 공예품을 만드는 것 같은 세심함과 뿌듯함으로, 사랑하는 사람을 위해 음식을 만들 때와 같은 착한 마음으로 임한다. 최소한 전에는 그랬다.
80년대 프로그래밍은 K&R 로 시작했다. Fortran으로 잠깐 짜 보다가 C를 접하니 정말 프로그램 구조를 이해하기 쉽게 만들 수 있어 프로그램이 훨씬 쉽게 다가왔다. 많은 친구들이 The Elements of Programming Style 을 보았다. K&R 저자 중 하나인 Kernighan이 책의 저자 중 한명이기도 했으니. 이제는 고전이 되었다.
Dennis Ritchie가 계셨다 (묵념). K&R의 R. C를 만들었다. Ken Thompson, Brian Kernighan과 UNIX를 만들었다. 이들 모두 비슷 비슷한 연배로 Bell Lab에 있을 때 동료들 이었다. 끝내 주는 시절이었을 것이다.
Fortran과 PL/1 예를 사용했지만 지금도 The Elements of Programming Style 의 77개의 지침들은 맞는 것이 많다.
"Everyone knows that debugging is twice as hard as writing a program
in the first place. So if you're as clever as you can be when you write
it, how will you ever debug it?" ㅋㅋㅋ
유명한 대학의 유명한 교수님이 강의 중 말씀하시길,
"Advances in programming language are caused by the need to protect software from the programmers"
프로그래머의 능력을 너무 믿지 말라는 얘기. 아키텍쳐, 패턴 다 도움되지만 프로그래밍이 수준이하면 사상누각.
"devil is in details"
* Rules from The Elements of Programming Style
1. Write clearly - don't be too clever. : 잔재주 부리지 말고 명료히 짜도록. for 조건문내에서 이상한 짓 하지 않도록.
2. Say what you mean, simply and directly. :
3. Use library functions.
4. Avoid temporary variables.
5. Write clearly - don't sacrifice clarity for "efficiency." : 우선 명료해야 한다. 성능은 그 다음에...
6. Let the machine do the dirty work.
7. Replace repetitive expressions by calls to a common function.
8. Parenthesize to avoid ambiguity.
9. Choose variable names that won't be confused.
10. Avoid the Fortran arithmetic IF. : 다행이 C 부터는 이렇게 할 수도 없을 것 같다.
11. Avoid unnecessary branches.
12. Use the good features of a language; avoid the bad ones. : C# 에서는 같은 효과를 너무 많은 방법으로 할 수 있게 만들어 오히려 헷갈린다.
13. Don't use conditional branches as a substitute for a logical expression. : 맞는 말씀.
14. Use the "telephone test" for readability. : 설명하기 쉽고 보기 쉬운 프로그램이 이긴다.
15. Use DO-END and indenting to delimit groups of statements. : pass next three statements including this.
16. Use IF-ELSE to emphasize that only one of two actions is to be performed.
17. Use DO and DO-WHILE to emphasize the presence of loops.
18. Make your programs read from top to bottom.
19. Use IF…ELSE IF… ELSE IF… ELSE… to implement multi-way branches. : else if 가 4개 이상 나오면 switch .. case로. C/C++ 에서도 string 을 지원하면 편할 때가 많으니 만들도록.
20. Use the fundamental control flow constructs.
21. Write first in an easy-to-understand pseudo-language; then translate into whatever language you have to use.
22. Avoid THEN-IF and null ELSE. : 패스
23. Avoid ELSE GOTO and ELSE RETURN. : 패스
24. Follow each decision as closely as possible with its associated action.
25. Use data arrays to avoid repetitive control sequences.
26. Choose a data representation that makes the program simple. : 프로그램을 ADT 개념으로 구성하는 친구가 착한 프로그래머.
27. Don't stop with your first draft. : 첫번째부터 생각대로 돌아가면 생각이 짧은 것이다.
28. Modularize. Use subroutines. : 지당한 말씀
29. Make the coupling between modules visible. : 모듈간 서로 잘 아는 사이는 좋지 않음. 커플링은 작을 수록 좋음.
30. Each module should do one thing well. : 객체지향 개념은 역사가 깊음.
31. Make sure every module hides something. : 착한 프로그래머는 Fortran으로 객체지향 프로그래밍을 나쁜 프로그래머가 Java로 짜는 것 보다 더 낳게 짠다.
32. Let the data structure the program. : 역시...
33. Don't patch bad code – rewrite it.
34. Write and test a big program in small pieces.
35. Use recursive procedures for recursively-defined data structures.
36. Test input for validity and plausibility. : defensive programming...
37. Make sure input cannot violate the limits of the program.
38. Terminate input by end-of-file or marker, not by count.
39. Identify bad input; recover if possible.
40. Treat end of file conditions in a uniform manner.
41. Make input easy to prepare and output self-explanatory.
42. Use uniform input formats.
43. Make input easy to proofread.
44. Use free-form input when possible.
45. Use self-identifying input. Allow defaults. Echo both on output.
46. Localize input and output in subroutines.
47. Make sure all variables are initialized before use. : C 에서는 메모리 clear할 때에도 포인터도 nullptr 해 주기.
48. Don't stop at one bug.
49. Use debugging compilers.
50. Initialize constants with DATA statements or INITIAL attributes; initialize variables with executable code.
51. Watch out for off-by-one errors.
52. Take care to branch the right way on equality.
53. Avoid multiple exits from loops. : 나쁜 프로그래머가 사람 헷갈리게 하는 패턴 중 하나..
54. Make sure your code "does nothing" gracefully. : 생각했던 일을 안하고 그대로 빠져 나올 때가 있을 수 있다는 것을 명심하고 이 경우도 잘 처리하도록. 얼음위에서 바퀴가 헛 돌더라도 차 뒤집혀지지 않게...
55. Test programs at their boundary values. : 문제는 종종 외곽에서 생긴다니까...
56. Program defensively. : 친구가 짠 모듈을 의심하도록...
57. 10.0 times 0.1 is hardly ever 1.0. : 왠만하면 숫자 비교 시 == 사용하기 전에 생각해 보기를.
58. Don't compare floating point numbers just for equality.
59. Make it right before you make it faster. : 일단 맞아야지. 그 뒤에 성능이나 refactoring을.
60. Keep it right when you make it faster.
61. Make it clear before you make it faster.
62. Don't sacrifice clarity for small gains in "efficiency."
63. Let your compiler do the simple optimizations.
64. Don't strain to re-use code; reorganize instead.
65. Make sure special cases are truly special. : 같은 예외가 자주 걸리면 그건 예외가 아니지.
66. Keep it simple to make it faster.
67. Don't diddle code to make it faster – find a better algorithm. : 의미있는 성능 개선은 알고리즘 개선에서 나온다.
68. Instrument your programs. Measure before making "efficiency" changes.
69. Make sure comments and code agree.
70. Don't just echo the code with comments – make every comment count.
71. Don't comment bad code – rewrite it. : 이런 것은 정말 죄악.
72. Use variable names that mean something.
73. Use statement labels that mean something.
74. Format a program to help the reader understand it.
75. Indent to show the logical structure of a program.
76. Document your data layouts.
77. Don't over-comment.
착한 프로그래밍은 읽기 쉬어야 하느니...
'소프트웨어 이야기 > 착한 프로그래밍' 카테고리의 다른 글
| 간단한 C++ 전략 패턴 (0) | 2012.12.11 |
|---|