?

Log in

No account? Create an account

Вс, 5 сент, 2010, 01:52
Книги: август

Эндрю Стеллман, Дженнифер Грин, «Идеальные команды»

Сборник всяких историй и интервью с разными людьми про команды и всё такое на тему peopleware. Запомнилось интервью с Гради Бучем — очень толково говорит про географически распределённые команды; ещё Карл Фогель интересно рассказывает, как на работу команды влияет инструментарий. Из любопытного — интервью с музыкальным продюсером Тони Висконти и возникающие параллели с миром программирования.

Пара цитат:

  • Если успех не бывает без риска, а риск означает возможность того, что случится что-то плохое, то если вы создаёте среду, в которой риск сводится к нулю, то что ещё сводится к нулю? Возможность успеха. — Кеоки Андрус
  • В больших компаниях часто имеют дурную привычку обращаться с людьми как с винтиками в механизме. Первый признак этого — именование людей ресурсами. — Джеймс Греннинг

В целом не очень полезная книга, слишком низко отношение сигнал/шум.

Brian W. Kerginhan, P. J. Plauger, «Software Tools»

Книга 1976 года, у нас не переведённая. На примере создания утилит (от простых, типа wc, до сложных, вроде макропроцессоров) получился прекрасный учебник: учебник философии юникса, учебник стиля программирования. На глазах читателя из ничего появляются очертания стандартных библиотек для работы с файлами и строками, возникают утилиты sort и grep, изобретаются пайпы... Это завораживает и радует своей концептуальной чистотой.

К сожалению, сейчас рекомендовать эту книгу как учебник довольно трудно, поскольку все примеры в ней приведены на языке Ратфор — макрорасширении языка Фортран, которое делает его похожим на Си. Авторам, как они и сами отмечают, пришлось приложить немало усилий, чтобы преодолеть отсутствие в Фортране (того времени) структур данных, динамического выделения памяти и рекурсии. С другой стороны, любителям древностей именно этим книга и интересна в первую очередь.

Как сказал однажды кто-то из преподавателей на ВМК: «Всё хорошее в программировании уже придумал Кнут». Вот и у меня возникает ощущение, что всё уже было придумано в 60-70х годах. Например, в этой книге пропагандируется итеративная разработка, ещё не повсеместно пробившая себе дорогу и в наши дни.

Из цитат можно составить целый курс:

  • The main assurance you have that a program is correct is the intellectual effort you put into getting it right in the first place. ... Testing is still necessary, however, to check that the algorithm is valid and that the program implements it correctly.
  • Mechanical rules are never a substitute for clarity of thought.
  • Readability is the single best criterion of program quality.
  • One of the best ways to learn good programming is to read and think about actual programs, to ask questions like «Why was it done that way?» or «Why not write it like this?»
  • It is often true in large software projects that the majority of bugs arise because the pieces of the system do not go together as they were expected to, despite detailed interface specifications known to everyone from the start. And many other bugs survive elaborate checks on individual routines, surfacing only when the routine first interacts with the rest of the code.
  • A function should do what its name says, even if it doesn’t have to, because some day a programmer ... may make a change that calls on the function in a new way. Programmers have the right to be ignorant of many details of your code and still make reasonable changes.
  • In our experience, editors that presume to know too much about what you’re doing are more hindrance than help.
  • It is hard to decide how much to protect users from their own behavior, but in our experience, it is generally wisest to keep out of people’s way: assume they know what they are doing and let them do it with as few prohibitions and warnings as you can manage.
  • The design principle ... is a guideline to be applied intelligently, not an absolute rule to be followed blindly.
  • Few programs remain static over their lifetime; it is wise to plan ahead so the inevitable changes are not traumatic.
  • Whenever possible, hide details from routines that don’t need them.
  • The best procedure for obtaining efficient code is to choose a good algorithm, write a program that implements it as cleanly as possible, then measure it. The measurement will lead you directly to the one or two routines that are worth making as efficient as possible—if they are clearly written and if they hide their information properly, they will be easy to change. Sacrificing readability for efficiency earlier than this, while the bulk of code is being written, not only result in wasted effort but also leads to code that is hard to improve because it is hard to understand.
  • As much as possible we try to minimize data connections between routines. This is one of the most effective ways we know of to write code that can be easily changed. ... The important thing is to start with a good design. It is much easier to relax standards for something well written than it is to tighten them for something badly written.
  • Most of the time programmers have no real idea where time is being consumed by a program. Consequently nearly all the effort expanded (and the clarity sacrificed) for «efficiency» is wasted. We have found that the best way to avoid too-early optimization is to make a regular practice of instrumenting code. Only from such first hand experience can one learn a proper sense of priorities.
  • No program comes out a perfect work of art on its first draft, regardless of the techniques you use to write it. ... Extensive revision may sound like a costly and time-consuming luxury, but when the programs are clean and the modules small, it is not. Moreover you will find that with practice in reading and revising, your first versions get better and better, since you soon learn what to use and what to avoid, what is good style and what is not. Even so, rewriting will always remain an important part of the programming process.