📄 extremeadaexperiment.html
字号:
<head><title>Extreme Ada Experiment</title></head><body><h1><img src="logo.gif"> Extreme Ada Experiment</h1><em>Comments and questions interleaved. --<a href="RonJeffries.html">RonJeffries</a></em>
<p>I've been following the discussions of <a href="ExtremeProgramming.html">ExtremeProgramming</a> for 4 or 5 months. Six weeks ago, I was given responsibility for developing a portion of a customer demo. I choose to use Ada95 (over C++ or Java) and attempted to apply XP as I understood it. As I approach the end of this short project I have some thoughts.
<p>Several concepts worked very well. Religious refactoring was wonderful. I attempted to keep all my routines to a single page (less than 60 lines). The seasoned XP folk would probably say this is way too long, but I think that's partly an artifact of Ada's wordiness. Ada is very robust in the ways it allows you to reuse or generalize code (tagged types; package hierarchies; generic packages, functions, and procedures; etc) and this encouraged refactoring.
<p><em>I believe that the average method length in C3 is under 10 lines. But that is surely a result of Smalltalk's compactness as well as practiced focus on small methods.</em>
<p>I attempted to first get a minimal skeleton working and tested and then incrementally add needed functionality. Sometimes I succeeded. Sometimes I was led astray trying to make large additions. In general, it seems adding functionality shouldn't break the code for more than 2 days. If it does, the added functionality should probably be broken into smaller chunks.
<p><em>We try to break the code for no more than a couple of minutes, literally. In almost every case where a programmer has failed to complete changes in two days, it has been desirable/necessary to throw the code away and start over. More on this in <a href="http://c2.com/cgi/wiki?BrokenCode">BrokenCode</a>.</em>
<p>I was fairly successful with not doing more than was needed. It's interesting how desirable it was to provide a full complement of features for certain types. With the tight time constaints and with this being a demo, I sometimes choose simple albeit inefficient solutions. These solutions I tried to annotate with comments to inform any successors on ways to improve the system. I think this might be a good general principle since performance is always a problem and you probably shouldn't sweat it until the whole system is build.
<p><em>Excellent! We're glad to hear you were successful with YAGNI. How did you discipline yourself to it?</em>
<p>I failed in fully applying the rigorous testing. First, it's hard to not break test scenarios and test drivers as you incrementally fill out the system. Second, I incrementally understood the inputs and outputs of the system and the expected behavior. My feeling is that the testing style will differ drastically based on programming languages and types of system (client-server, data processing, user interface, database, etc). I need more enlightenment.
<p><em>Testing style might differ, but I wouldn't expect it to be as difficult as you discovered. We need to do a better job of describing how to unit test and how to develop in the always-100% mode. See <a href="http://c2.com/cgi/wiki?BrokenCode">BrokenCode</a>.</em>
<p>The requirements for my code were based heavily upon existing documents. I scoured the interface document to understand my inputs and outputs, and talked extensively with one of the engineers responsible for the proposal to determine the system behavior. I still made mistakes on interpretting its behavior. Using object-based programming greatly reduced the ripples, though. Another area which I feel needs more study.
<p><DL><dt> <dd><em>Good work! Communication is one of the <a href="ExtremeValues.html">ExtremeValues</a>. I'm glad to see you do it. When I program, I tend to get a little to focused on the code-writing part, and forget the talking-to-the-client part. This is an important step we should not forget. -- BT</em>
<p></DL>I still found some commenting to be necessary. Some tasks the system had to perform were difficult to map to a short phrase. My choices were to have identifiers that didn't quite discribe the actual processing; to have VERY long identifiers (Do_This_And_Conditionally_Do_That); to encourage others to look at the implementation (rather than just the interface); or to supplement the interface with what it should do, it's entry conditions, and side-effects. I chose to comment. There were also times where a simple concept required some complexity in the code. A one-line comment seemed appropriate.
<p><em>Even the <a href="ExtremeProgrammingMaster.html">ExtremeProgrammingMaster</a> uses a comment once in a while. The trick is not to let them substitute for writing good code. Names such as Do_This_And_Conditionally_Do_That, however, can usually be avoided. Think in terms of the intention of the method (its purpose), not its implementation. Probably the method does something that does have a single-concept behind it ... or it wouldn't belong in a single method anyway. Finish_With_Document might be the intentional name for a method that could have been called Close_Window_And_Optionally_Empty_Trash.</em>
<p>I have also been toying with <a href="ExtremeProgramming.html">ExtremeProgramming</a> in C with very limitted success. Is it possible XP works better with object-oriented programming than it does with structured programming? More likely, I'm just a crummy C programmer :)
<p><em>I have a lot of C experience, and would enjoy going back to it with an XP orientation. I'd expect it to serve me well there. It was always my practice to limit routines to a few lines, even in C, which would help. However, refactoring is always harder in a language that can't hand you a window with all the references to the old name, for changing to the new one.</em>
<p>Any thoughts?
<p>--<a href="http://c2.com/cgi/wiki?WayneCarson">WayneCarson</a>
<p>====
It seems to me that strongly typed languages have a significant advantage
here, because of their ability to maintain 'automated consistency'. As a
long-time Ada programmer, I've learned how to use the language to do a lot
of consistency checking for me; when the code compiles, it almost always
runs. The remaining errors are design errors, which are exactly the kind
of intellectual errors that humans should be concentrating on.
Furthermore, the checking-in-the-large and separate compilation makes
it easier to detect problems from reorganizing a program. One tool
that I've wanted is a "hoister tool" that allows me to move, for example,
a procedure from one unit to another. The "hoister tool" will resolve
namespace changes, compilation order, etc, or tell me why it can't make
my program consistent again.
<p>Thus I suspect that the 'issue' is not object-oriented, but rather
strongly-typed; I'd expect Java to be "better" than C++ for this reason.
<p><PRE> dave emery
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -