Компьютерра - Журнал «Компьютерра» № 10 от 14 марта 2006 года

Может быть, имеет смысл не касаться некоторых тем в китайской версии? Ввести цензуру, как сделали крупные поисковики?

— Китайские власти не пытались с нами договориться… Но, в любом случае, такая договоренность крайне маловероятна. Меня, честно говоря, очень беспокоит то, что делают в этом смысле Google, Yahoo или Microsoft. Даже если они верят, что поступают правильно (Google, например, говорит, что жизненно важно предоставить китайцам доступ к информации, поэтому, видимо, можно пойти на некоторые уступки), мы-то с вами знаем, что Китай — это огромный рынок. И у очень многих компаний появляется соблазн сказать, что, мол, мы делаем это лишь для того, чтобы помочь народу Китая.

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

Думаю, что в долговременном смысле такой подход более перспективен. На нашей с вами памяти произошли невероятные изменения в России. И я не уверен, что это хорошая идея для, скажем, Google — ставить под удар свою репутацию ради достижения краткосрочных целей. Когда-нибудь в Китае все изменится, и китайцы вспомнят, кто помогал цензорам.

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

Джимми — из тех хорошо информированных оптимистов, которые не стали пессимистами. Правда, в будущее он смотрит не столько с уверенностью, сколько с интересом:

— Я могу легко предсказать будущее русской Википедии, потому что английская уже прошла все эти стадии развития. Я знаю, что бывает, когда у вас триста или пятьсот тысяч статей. Но предсказать будущее английской Википедии гораздо труднее. С нынешними темпами роста в следующем марте у нас будет два миллиона статей, а еще через год — четыре миллиона. И я даже представить не могу, на что это будет похоже.

Автор: Дмитрий Кириллов

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

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

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

В качестве вступления следует отметить, что современные методы разработки программного обеспечения позволяют достаточно четко отделить бизнес-требования к системе от программной архитектуры, а уж тем более — от исходного кода реализации... но лишь на ранних стадиях разработки. При этом серьезное изменение проекта на поздних стадиях может стать тем самым «дятлом, залетевшим в форточку и разрушившим цивилизацию».

Для того чтобы этого не произошло, опытные разработчики и архитекторы рекомендуют:

пользуйтесь шаблонами проектирования (при этом снижаются риски, связанные с неудачным выбором архитектуры);

периодически проводите ревизии проекта (забавно, что при этом зачастую происходит документирование поведения системы «пост-фактум»);