Перейти к содержанию

Собор и Базар

Материал из Викицитатника
Собор и Базар
Статья в Википедии

«Собор и Базар» (англ. The Cathedral and the Bazaar; аббревиатура CatB) — эссе Эрика Рэймонда 1999 года на тему методов разработки программного обеспечения, основанное на анализе процесса разработки ядра Linux и личном опыте управления открытым проектом fetchmail.

Цитаты

[править]
  •  

Все хорошие программы появляются для личных нужд разработчиков.

  •  

Хорошие программисты знают, что можно написать; а великие знают, что можно переписать.

  •  

Характерная черта великих - это их лень. Они знают, что судят не по усилиям, а по результатам.

  •  

Почти всегда легче начать с чего-то сделанного, чем с нуля.

  •  

…Когда вы первый раз реализуете какое-либо решение, вы часто не понимаете проблему до конца. Во второй раз вы уже набираете достаточно знаний, чтобы сделать это правильно. Итак, если вы хотите написать что-нибудь стоящее, лучше хотя бы один раз начать все заново.

  •  

При правильном отношении интересная проблема найдет вас сама.

  •  

Когда вы теряете интерес к программе, ваша последняя обязанность передать ее компетентному преемнику.

  •  

Иметь пользователей - это замечательно. Не только потому что это означает, что вы предоставляете нужную услугу. Дело в том, что правильно воспитанные пользователи могут стать сотрудниками.

  •  

Если пользователи будут вашими сотрудниками, то вам обеспечены улучшение кода и эффективная отладка.

  •  

Я действительно думаю, что наиболее значительное и результативное творение Линуса - это не создание ядра Linux'a, а изобретение модели его разработки.

  •  

Выпускайте ранние релизы. выпускайте частые релизы. Слушайте своих пользователей.

  •  

При достаточном количестве бета-тестеров и сотрудников, почти любая проблема будет быстро обнаружена и окажется для кого-то очевидной.

  •  

Больше пользователей найдут больше ошибок, потому что новые пользователи добавляют новые способы отладки программы.

  •  

Согласитесь, не очень-то здорово отвечать за исправление ошибок в программе, которую ты не понимаешь.

  •  

Хорошие структуры данных и плохой код работают несколько лучше, чем хороший код и плохие данные.

  •  

Если вы относитесь к вашим бета-тестерам как к самому ценному ресурсу, очень скоро они станут вашим самым ценным ресурсом.

  •  

Иногда использовать идеи пользователей лучше, чем использовать свои идеи.

  •  

Часто самые удивительные решения приходят от понимая того, что постановка задачи была неправильной.

  •  

Когда во время разработки программы вы натыкаетесь на препятствие, когда вам приходится серьезно размышлять над следующим шагом, самое время подумать: но не над тем правильный ли вы получили ответ, а над тем правильный ли вы поставили вопрос. Возможно задачу следует переформулировать.

  •  

Не колебайтесь выбрасывать устаревшие особенности, если вы можете сделать это без потери эффективности. Антуан де Сент-Экзюпери - человек, который был летчиком и авиаконструктором, сказал: «Совершенство в разработке достигается не тогда, когда нечего добавить, а тогда когда нечего убрать».

  •  

…Обычно научная, инженерная и промышленная разработка совершается не гениями, хакерами.

  •  

Любой инструмент должен быть полезен для тех целей, для которых он разрабатывался. Великий инструмент становится полезным там, где от него ничего подобного не ожидали.

  •  

Когда вы разрабатываете gateway software, старайтесь не вмешиваться в поток данных, пока вас к этому не вынудят.

  •  

Дешевое исполнение инструкций и краткость не должны стать конечной целью. В первую очередь язык должен быть удобным для людей, а не дешевым для компьютеров.

  •  

Если ваш язык не является полным по Тьюрингу, добавьте немного синтаксического сахара.

  •  

Система безопасности надёжна, пока надёжны ее секреты. Избегайте псевдо-секретов.

  •  

По-моему не очень существенно, способен ли координатор на оригинальный дизайн. Однако, совершенно необходимо, чтобы лидер проекта был способен отличить хороший дизайн от всех остальных .

  •  

Проблема первоначального дизайна заключается в том, что вы начинаете проект, усложняя себе задачу, в то время как следует оставлять ее простой и понятной.

  •  

Чтобы решить интересную проблему, найдите проблему которая вас заинтересует.

  •  

Если у координатора разработки есть средство связи, по меньшей мере такое как Интернет, и он умеет лидировать без принуждения, то лучше пользоваться несколькими головами, чем одной.

  •  

Я думаю, что будущее свободного программного обеспечения принадлежит людям, которые знают как играть в игру Линуса, которые оставляют стиль собора и разрабатывают проекты в стиле базара. Это не означает, что индивидуальность не играет больше никакой роли. Наоборот, впереди окажутся те, кто начинал с индивидуального мастерства, а потом расширил его через эффективное создание добровольных сообществ.
Возможно, это будущее не только свободных программ. Ни один разработчик коммерческих программ не сможет сравниться с сообществом Linux в решении проблемы. Немногие смогут нанять двести человек, которые участвовали в разработке fetchmail.
Вероятно, в конце концов свободное программное обеспечение победит, не только потому что кооперация правильна с точки зрения морали, но просто потому, что коммерческий мир не сможет состязаться с сообществами free-software, которые могут бросить гораздо большие силы на решение одной проблемы.