2016/08/26 Scott Meyers – The Most Important Design Guideline

每天推荐一个英文视频

http://v.qq.com/page/q/v/o/q0...
https://www.youtube.com/watch...

本日看点

API 是 library 的 interface，就像 GUI 是软件的界面一样。设计合理的 API 对于 library 的用户来说非常重要。请 library 的开发者都认真看一下这个视频吧。

内容摘要（http://oguzpedia.blogspot.jp/...）

00:24  I want to talk about single most important guideline I know 
       of writing software independent of the its language, its tasks, its 
       users, etc.
       
00:50  #1 Make interfaces easy to use correctly and hard to use incorrectly.

00:55  We spend a gigantic amount of time on interfaces!

01:40  There are two types of interfaces.

01:45  #1 Encountered by everybody:
          GUI/Software interfaces
          Command line interfaces
          Speech interfaces
          
01:50  #2 Encountered by software developers:
          Library interfaces
          Module interfaces
          Class interfaces
          Method and function interfaces
          Generics and template interfaces
          
04:00  Interface users are typically smart and motivated.

05:00  If they use your software improperly, it is your fault!

05:27  What this means is that software should be designed and implemented 
       to be easy to correctly and hard to use incorrectly.

06:05  The software development industry should shoot for Rico Mariani's 
       "pit of success".
       
06:20  It means by default all forces should push you in the right direction.

06:46  Principle of least astonishment: strive to maximize the likelihood 
       that user expectations about an interface are correct.
       
07:30  Your job is to maximize the odds that the guesses are correct.

07:42  If users can do something, it should do what they expect.

07:55  If users know what they want to do, they should be able to guess how 
       to do it.

08:20  UI counterexamples:
       Starting from Win 95, press the Start button to shutdown the computer.
       
08:45  The rationale was "everything else we tried was worse".

09:12  What is biggest complain about Win 8? It doesn't have a "Start" button!

09:40  If your interface is so liked & so long-lived, be proud of it!

10:45  [In an old Mac OS] in order to eject the removable media, drag its icon
       to the trash can!

12:25  In Win XP, choosing the large font size instead of the normal one was very 
       problematic!
       
13:10  While installing Qt 4.8 on a Win computer, "The install path must not 
       contain any spaces..." Pointing to poor porting from Unix!
       
15:45  Expedia and Kayak's calendar selection UI's in 2010, i.e. after iPhone: 
       Kayak allowed swipe, but Expedia didn't!
       
16:20  Some interfaces are so bad, it is really difficult describe exactly what 
       is wrong with them! A very poor UI example from a calendar app.
      
18:15  Slate mobile app for reading articles: the "Top Comment" inserted into 
       the middle of article!

19:40  General techniques:
           - Avoid gratuitous incompatibilities with the surrounding environment: 
             take advantage of what people already know
           - Offer natural syntax
           - Offer intuitive semantics:
               In API's, when in doubt, do as built-in or standard library types 
               do. In GUI's, try to have mouse clicks, keyboard shortcuts and 
               gestures mean the "usual things".
               
22:25  More specific techniques:
           - Choose good names: the very first impression that people get is based
             on names!
             
24:50  UI counter example: Adobe Acrobat 9 after modifying a PDF displaying a
       dlgbox with three buttons: "Do you want to save changes to your file? 
       Yes, No, Cancel." What does "Cancel" mean is confusing!
       
25:45  OpenOffice has a similar "Save, Discard, Cancel" dlgbox!

26:30  Being desktop apps, i.e. space isn't so restricted, you can put more 
       text on the "Cancel" buttons.

26:45  Another solution, without asking silently saving the file which brings 
       other UI challenges.

27:05  One of things I find is that if you have UI challenge that is making 
       difficult for people to do the right thing try to come up with an 
       alternative design that makes the problem completely go away!

27:25  "Gulf of execution": distance between what you want to do and the action
       you must take to get it done. Larger the gulf of execution, the more 
       difficult to use the software.

28:00  As interface designers, our goal is to minimize the "gulf of execution" 
       and turn it into "pit of success"!

28:45  "Choose good names" API counterexample: In C++ equal_range is based on 
       equivalence, not equality! 
       
29:05  Be consistent in all kind of things: in naming, in error reporting etc.

30:15  "Be consistent" GUI counterexamples:

31:20      - "Mail Compose button" on different locations on iPhone, iPad and MAC
             OS X! Works against muscle memory...

32:28  "Be consistent" cross-device counterexamples:
           - Marriott Rewards Card. It carries numbers grouped by blanks. The web 
             UI accepts the spaces, but the server rejects the number submitted! 
             Stupid UI designers...
             
           - An ATM UI asks for cash or check deposit, but the hardware buttons 
             are placed below the wrong UI buttons! Misleading...
             
34:10      - Java container size? both "length" and "size" used!

34:40      - .NET 1.0 container size? both "Length" and "Count" used! People
             claims thanks to the IDE, no problem. But they are wrong on two 
             counts:
             1 - "L" and "C" are different letters!
             2 - Not always an IDE is used!
             Plus, as .NET supports reflection, you have to query the objects for
             more than necessary!

36:40      - C Standard Library file functions: fscanf(), fgetpos() and fseek() 
             gets the FILE pointer as the first argument. However, fgets(), 
             fputc() and freopen() gets the FILE pointer as the last argument!
             Even very very experienced C developers are confused: 
             "This inconsistency has frustrated millions of developers for more 
             than 30 years" - Ferenc Mihaly
             
37:59      - C++ Standard Library function to eliminate all container elements 
             with a given value: for 8 containers erase() and for 2 containers 
             remove() are used! I am intimately familiar with the developments in
             C++ there are reasons for it and the reasons are not good! The smart 
             people never looked at the problem at this level, but the programmers
             look at this level!
             
39:20      - C++ Standard Library: if the sort() function doesn't run in N * logN 
             time which can be detected during compilation, the code it 
             rejected! However, binary_search() either runs in logN or N. 
             Conceptual inconsistency...
             
41:20      - C++ Standard Library: have sort() and stable_sort(), however 
             list::sort() specialization is guaranteed to be stable! Inconsistent
             naming...             
             
42:30  Progressive Disclosure: discriminate between "expert" and "normal" not to 
       overwhelm the users. Not uncommon in GUI's.
       
43:45      - GUI from an app called SUPER: categorized the options. Categorization
             alone may be fine, but it is just not progressive disclosure!

44:20      - Applicable to API design, too: bundle advanced functionality into 
             separate objects. Functionality is hidden, unless such objects are 
             requested. Ken Arnold's "Programmers are People, too" article cites
             Java JButton class offering >100 methods. However, typical use only 
             a small minority! His suggestion: retain only commonly-used methods
             in JButton, bundle rarely-used method into an object accessible via
             JButton's getExpertKnobs method. Plus, bundle integration 
             functionality into an object accessible via getIntegrationHooks 
             method.

46:20  Document Before Implementing: proven way to discover interface problems.
       Unpleasant to explain -> unpleasant to use. Plus:
           - Surprising or underspecified behaviors
           - Bad names
           - Inconsistencies

47:20  If you are using a strongly typed programming language, i.e. statically 
       typed, the type system is your friend. Many errors can be prevented through
       stronger typing.
       
47:40  C++ Date class:
           Date(int month, int day, int year);
           
48:20  If in an API, any time adjacent parameters are of the same type, callers
       can pass them in wrong order! It should be avoided as much as possible. 
       Easy to use incorrectly!
       
48:45  Fix it by introducing Month, Day and Year types.
       Date d(4, 8, 2005); -> Date d(Month(4), Day(8), Year(2005)); 
       Besides preventing the user errors, the code is now easier to read.
       
49:49  Typedef's are synonyms and using them for int's make the code easier to
       read, but compiler doesn't detect errors! Programming to make you feel 
       better about yourself! You haven't improved the type safety in any way...
       
50:30  Why I fixated on 4/8/2015? The day we got "Darla". My wife and I have no 
       kids, having a dog is good!
       
51:30  Constrain values: Month(-4) is still possible! Let the Month class has
       public static 12 const Month objects per actual month and disable new 
       Month object creation, i.e. let the Month ctor be private and explicit. 
       So, Month(-4) won't even compile!
       
52:40  Addressing the day and year is harder, but it is possible.

52:52  When you design an interface, you should always ask yourself what kinds of 
       errors might people make in this interface.

53:00  Given the errors they could make, what actions can we take to prevent them?

53:15  Given the errors, the cost associated with the errors, the prevention and 
       the cost associated with the preventing them, you can make an engineering
       or business decision.
       
53:50  Even constraining values may lead to a false sense of of security. For 
       example, on the Lonely Planet web site June 31 was possible!
       
54:05  Consistency: two different methods for date specification on the Lonely 
       Planet. Bad for muscle memory!
              
54:53  Avoid over reliance on string. String is known as a type sink!

56:07  Different types facilitate type-specific type formatting and validation
       code!

56:19  Rather than using strings in your API's, you should be using something
       just descriptive about what they stand for.

57:28  Starts to answer the questions.