Effective ProgrammingWhy test?Program designWhy refactor?Regression testingProgramming disciplineDealing with I/ODealing with GUIsCreeping featurismThe EndJan 15, 2019Effective Programming“The new US stealth fighter, the F-22 Raptor, was deployed for the first time to Asia earlier this month. On Feb. 11, twelve Raptors flying from Hawaii to Japan were forced to turn back when a software glitch crashed all of the F-22s’ on-board computers as they crossed the international date line...every fighter completely lost all navigation and communications when they crossed the international date line. They reportedly had to turn around and follow their tankers by visual contact back to Hawaii...if they had not been with their tankers, or the weather had been bad, this would have been serious.”http://slashdot. org/index.pl?issue=20070225Why test?Program design“In preparing for battle I have always found that plans are useless, but planning is indispensable.” --Dwight D. Eisenhower The same is true in programmingYou must plan out your program in advance, so you know where you are trying to go--but expect many changes along the wayDon’t just jump into coding with the first approach that occurs to you, but consider alternate plansAlways be ready to refactor as needed“How far you can go without destroying from within what you are trying to defend from without?” --Dwight D. EisenhowerActually, I don’t think this quote has any relevance to programmingWhy refactor?Refactoring: Making changes to your program that don’t affect what the program doesSome refactorings:The name of a method no longer accurately describes what it does, so you want to rename itYou need more control over what a method does, so you want to add a parameterYou need to use only part of what a method does, so you extract that part into a separate methodYou realize that a method is in the wrong class, so you move it to a different classEclipse makes these and other refactorings relatively “safe”--that is, they are unlikely to break your programNot all refactorings are as easyRegression testingRegression testing: Testing whether the program still works, after you have made a change to itJUnit tests are extremely useful for regression testingA thorough set of tests gives you the confidence to refactorDebugging is dangerous--fixing a bug is very likely to introduce new bugsIt is a general rule that the difficulty of debugging a program goes up as the square of the program sizeProgramming disciplineTo write impressively good programs, here are some rules to followPlan ahead--consider more than one design before you start programmingRefactor early and oftenTest everything you can as thoroughly as you can--don’t let the code get out of controlWriting tests before you write the code isn’t the only way to program, but it improves your program design as well as your codeStart with “the simplest thing that could possibly work”Insofar as possible, make only small changes to your programDon’t add features until the code you already have is “completely” debuggedIt takes discipline to follow these rules--it’s easier to just jump in and start writing code--but a methodical approach greatly increases your chance of successDealing with I/OWe can (in some cases) test our output methods PrintStream originalOut = System.out; OutputStream os = new ByteArrayOutputStream(); PrintStream ps = new PrintStream(os); System.setOut(ps);We can even test our input methods InputStream originalIn = System.in; byte[] buf = "Some input string".getBytes(); InputStream is = new ByteArrayInputStream(buf); System.setIn(is);Dealing with GUIsGUIs are not easy to test with JUnit-like softwareThere are programs that attempt to provide automatic JUnit tests for GUIs, but I haven’t found any I likeIf you want to write a GUI testing framework, you should explore java.awt.RobotThere is a reasonably good, albeit not perfect, solution to the problem of testing GUIs...Don’t do any work in the GUI class!Use the MVC (Model-View-Controller) approachThe GUI should only communicate between the user and the modelOf course, this is easier said than done, but still....Even if a GUI “works,” that doesn’t make it easy to useOf course you think your GUI is obviousYou should always have at least one other person try it out without help from you--you will probably be surprised at the resultCreeping featurism“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” --Antoine de Saint-ExuperyIn my opinion (as you already know), the highest praise you can give to a program is to say “it just works”Unfortunately, most software competes on the basis of how many features it offersSometimes you need those featuresWhen you don’t need them, you are better off without themThe EndThe original study that showed huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of intitial coding time between the best and worst programmers was about 20:1; the ratio of debugging times over 25:1; of program sizes 5:1; and of program execution speed about 10:1. They found no relationship between a programmer’s amount of experience and code quality or productivity. -- Code Complete, page
View Full Document
Unlocking...