Все новости от 4 марта 2004 г.

Новая инициатива в программировании. Движение за открытую проектную документацию

Простота требует проектирования и хорошего вкуса.

Л. Торвальдс

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

Э. Дейкстра

Открытого кода уже мало. Нужна и открытая проектная документация.

Раздел «Содержание». PC Week/RE. 2003. № 40

Проект в инженерной практике предполагает разработку и выпуск проектной документации.

Недавно я стал свидетелем того, как один выдающийся программист (участник двух финалов командных чемпионатов мира по программированию, проводимых Association for Computing Machinery (АСМ), в течение весьма продолжительного времени (15 мин) не мог понять программу из шести строк на языке Си. Про нее было известно, что она решает классическую задачу о Ханойских башнях итеративно, причем ее рекурсивное решение программист знал. После этого мы вышли в Интернет и сравнительно быстро нашли работу, где был весьма внятно описан алгоритм, использованный в указанной программе.

Почему исходные тексты не решают проблему понимания программ?
Данный факт в очередной раз подтвердил мое мнение, что «Движение за открытые исходные тексты» (Open Source Software) не обеспечивает даже в этом достаточно простом (относительно реальных проектов) случае решения проблемы понимания программ. К счастью, так думаю не я один. В частности, в работе [1] отмечается, что «центральный вопрос в практике программирования – вопрос о понимании программных текстов. Всегда хорошо иметь исходники, но проблема состоит в том, что зачастую их недостаточно. Чтобы понять некоторую нетривиальную программу, обычно требуется дополнительная документация. Эта потребность растет экспоненциально с ростом объема кода. Анализ текстов программ, направленный на восстановление первоначальных проектных решений, принятых разработчиками, и понимание программ являются двумя важными ветвями технологии программирования, существование которых неразрывно связано с недостаточностью исходных текстов для понимания программ. В качестве примера попробуйте понять структуру нетривиального компилятора при условии, что вы не располагаете определением того языка, который им компилируется.

Каждый, кто участвовал в крупном проекте по реконструкции ПО, навсегда запомнит то чувство беспомощности и потерянности, которое испытываешь, когда впервые видишь гору плохо документированных (но не всегда плохо написанных) исходных текстов. Доступность исходных текстов не слишком помогает, когда отсутствует доступ к ключевым разработчикам. Если программа написана на сравнительно низкоуровневом языке типа Cи и плохо документирована, то все основные проектные решения обычно растворяются в деталях кодирования и требуют реконструкции. В таких ситуациях ценность документации более высокого уровня, такой как спецификация интерфейсов и описание архитектуры, может превышать ценность самого исходного текста.

Осознание неадекватности исходных текстов для понимания программ привело к попыткам объединить код и документацию более высокого уровня. Одна из наиболее известных попыток решения указанной проблемы была предпринята Д. Кнутом в книге «Грамотное программирование» [2].

Возможно, самой известной запрещенной в истории компьютерных наук была книга «Commentary on Unix: With Source Code» [3], содержавшая высокоуровневое описание исходных текстов UNIX наряду с используемыми алгоритмами. Она нелегально копировалась и распространялась более 20 лет с момента ее первой публикации в 1977 г.

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

И еще. «Существуют ли какие-нибудь достойные свободные программы, вид которых не вызывает отвращения? До сих пор, несмотря на обилие свободного кода, нормальных программ среди него ужасно мало» [4].

О том, к чему это приводит, хорошо сказал великий русский математик, академик Л. С. Понтрягин: «Только хорошо выполненная работа дает радость! Выполненная небрежно, она вызывает отвращение и постепенно вырабатывает в человеке аморальное отношение к труду» [5].

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

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

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

Мосты, дороги и небоскребы без документации обычно не строятся, а вот о программах этого не скажешь. Кстати, в археологии тоже нельзя копать, где и как Бог на душу положит, так как при этом могут возникать серьезные неприятности.

В программировании сложилась ситуация, определяемая вторым законом Вейнберга: «Если бы строители строили дома так, как программисты пишут программы, достаточно было бы одного–единственного дятла, чтобы разрушить цивилизацию» [6].

Почему на аппаратуру выпускается море подробной и внятной проектной документации, в которой специалист средней квалификации может сравнительно быстро разобраться и изменить ее даже через много лет после выпуска, а для программ такая документация либо вовсе отсутствует, либо она пишется чисто формально и для ее корректировки (если разработчик отсутствует) требуется специалист более высокой квалификации?

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

Во-вторых, аппаратура – «жесткая», а программа – «мягкая». Это упрощает внесение изменений в программу, но не служит основанием для того, чтобы вовсе не выпускать проектную документацию. Известно, что большинство программистов патологически не желают читать и уж тем более писать документацию [7].

Опыт показывает, что практически ни один молодой программист, даже очень толковый, не умеет писать проектную документацию. Несмотря на то, что многие программисты слушали большие и сложные курсы математики и сдавали экзамены по ним, это почти никак не отражается на логике и строгости написания документации. Они, например, никак не могут во всей документации (вне зависимости от ее размера) использовать одно и то же обозначение, поэтому один и тот же предмет называется, например, то лампа, то лампочка, то lamp, то с большой буквы, то с маленькой. И это еще не предел их фантазии!

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

Вопрос о качестве документации на программное обеспечение приобретает все большее социальное значение. Так в работе [8], опубликованной в газете «Известия», первым среди вопросов «о чем мы должны подумать задолго до того, как кончится нефть» является качество указанной документации. «Наиболее запомнившееся и поразившее меня при выполнении совместного проекта с фирмой IBM отличие состояло в том, как они относятся к документации. У них было принято, – и это соответствовало практике, – что написано в документации, то так и есть, так и работает. У нас – никогда! У них из этого проистекала корпоративная уверенность в себе – на все вопросы они находили ответ в документации, утвержденной начальством. У нас не только документация плоха, но и мысли изложить толком никто не умеет. Я много раз сравнивал их доклады и наши «доклады». Однажды мы пригласили одного из лучших переводчиков. Он потом извинялся, что не смог толком перевести на английский, но я его успокоил, что и на русском-то ничего не понял… Этому нужно научиться. Эту часть работы следует любить и уважать». Несомненно, что и у них с документацией не все так хорошо, как говорит автор, но тенденция просматривается…

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

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

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

Это во многом связано с тем, что в большинстве случаев программы пишутся, а не проектируются. «При проектировании любая техника сложнее CRC-карточек [9] или диаграмм использования [10] считается слишком сложной и не применяется. Программист всегда может отказаться от любой технологии, сказав начальнику, что он не укладывается в срок» [11].

Все это приводит к тому, что даже «пользователи не считают ошибочное программное обеспечение чем-то из ряда вон выходящим» [7].

В настоящее время в обществе сложилось мнение, что крупные здания должны проектироваться и подробно документироваться, к программному обеспечению это не относится. Поэтому возникает вопрос: почему в рамках проектов типа "Живой дом" его составляющие должны проектироваться и документироваться разнокачественно?

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

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

Можно ли учиться проектированию и реализации программ по книгам? Да, но по разным: проектированию – по одним [12], реализации – по другим [13]. Книг, в которых прослеживаются оба этих этапа, почему-то нет. Их отсутствие могут восполнить открытые проекты. При этом отметим, что понятие «проект» в инженерной практике предполагает разработку и выпуск проектной документации, что в настоящее время для программирования не характерно.

Наконец-то появилось третье издание книги [14], содержащей более 1150 страниц, в которой проектирование и реализация рассматриваются совместно на примере моделирования работы лифта для двухэтажного здания, на каждом этаже которого может находиться не более одного человека. Однако, во-первых, эта книга одна, во-вторых, этот пример один. Это напоминает библиотеку, содержащую только одну книгу. Поэтому задача создания библиотеки с большим числом открытых проектов является актуальной.

Программное обеспечение с подробной открытой проектной документацией, в которой программная документация является лишь составной частью, может рассматриваться в качестве новой разновидности паттернов проектирования [15], позволяющих достаточно просто оценить как достоинства, так и недостатки выполненных проектов. Рефакторинг (изменение структуры программы без изменения ее функциональности) [16] или перепроектирование программы в этом случае может быть выполнено значительно проще, чем при наличии только исходных текстов. Проектная документация должна содержать, в частности, формальную спецификацию, по крайней мере, на логику разрабатываемой программы, так как «то, что не специфицировано формально, не может быть проверено, а то, что не может быть проверено, не может быть безошибочным» [17], а также в связи с тем, что «если нет спецификации, то нет и ошибок» :) [18].

Кроме того, проектная документация должна содержать «протоколы (истории вычислений), которые являются конструкциями, вскрывающими механизм работы программы, и поэтому среди теоретиков программирования складывается представление, что множество протоколов лучше характеризует программу, нежели сам исходный код» [19].

Отметим также, что без качественной проектной документации одно из основных достоинств объектно-ориентированного программирования – повторное использование кода – может приводить к большим неприятностям [20].

И самое важное. Проектная документация необходима, так как из теории алгоритмов известно (теорема Райса), что, в общем случае, по тексту программы невозможно алгоритмически доказать истинность никаких нетривиальных свойств вычисляемой ей функции.

Для понимания программ (в отличие от их исполнения), следуя Тьюрингу, требуется «проницательность» и «изобретательность». Однако, так как анализ текстов программ все равно не поддается автоматизации, а анализ «вручную» требует колоссальных затрат времени, то кажется, что по одному лишь тексту программы невозможно сделать выводы о ее свойствах.

Математики нашли решение аналогичной проблемы еще в античности. Это запись доказательства понятным человеку языком, что и отличало греческую математическую школу от древнеегипетской. В последней в качестве решения геометрической задачи предоставлялся чертеж, снабженный «пояснительной» надписью «Смотри!». Это сродни представлению текста программы для определения того, что она делает.

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

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

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

Разновидности требований к проектной документации
Рисунок иллюстрирует требования, предъявляемые к проектной документации на различные виды программного обеспечения

Прокомментируем этот рисунок. Для систем управления ответственными объектами характерно, что проектную документацию на программное обеспечение можно разделить на два класса: основную, отвечающую стандартам, и дополнительную, разрабатываемую по требованиям заказчика. Остальные коммерческие проекты документируются, в основном, по требованию заказчика.

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

Некоммерческое программное обеспечение, не связанное с образованием, документируется по усмотрению разработчика. При этом отметим, что в у большинстве случаев разработчик не "усматривает" необходимости документировать проект более, чем посредством написания комментариев и применения осмысленных названий для переменных, функций и т.д. Это особенно характерно для программ с открытыми кодами.

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

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

Движение за открытую проектную документацию
Как отмечалось в предыдущем разделе, проектная документация, по крайней мере для образования, должна быть открытой. Несмотря на наличие огромного числа открытых проектов (например, на сайте http://sourceforge.net), они, в большинстве случаев, не могут быть так названы ввиду отсутствия проектной документации. Наличие такой документации на русском языке и вовсе является редкостью. В результате, мы (автор и профессор В.Г. Парфенов, декан факультета информационных технологий и программирования Санкт-Петербургского государственного университета информационных технологий, механики и оптики (СПбГУ ИТМО)) решили «вызвать огонь на себя» и объявили в ноябре 2002 г. в Санкт-Петербурге на открытии полуфинальных соревнований Северо-Восточного Европейского региона командного чемпионата мира по программированию АСМ об организации «Движения за открытую проектную документацию» (Foundation of Open Project Documentation), в поддержку которого был создан сайт http://is.ifmo.ru.

Для придания импульса этому движению я начал педагогический эксперимент со студентами кафедры «Компьютерные технологии» СПбГУ ИТМО, известной успехами на чемпионатах мира по программированию. Суть эксперимента состояла в следующем: студенты, разбившись примерно на 40 групп (из одного или двух человек), должны были выполнить заинтересовавший их проект на основе автоматного программирования (программирование с явным выделением состояний) [21], но так, чтобы работа завершилась публикацией проекта на указанном сайте.

В отличие от многих студенческих работ, «выложенных» в Интернет в соответствии с «лицензией» as is («как есть» – без ответственности за ошибки) [22], мы очень старались. Выполнение каждого проекта занимало несколько десятков часов у студентов, из них не менее десяти часов мы проводили вместе.

Это привело к тому, что эксперимент, начавшийся в осеннем семестре 2002 – 2003 учебного года, завершится (почти в полном составе от стартовавших) лишь в осеннем семестре следующего учебного года, когда появятся новые «экспериментаторы».

Перечислим некоторые проекты, реализованные или реализуемые в настоящее время:

• построение визуализаторов алгоритмов для обучения дискретной математике и программированию;
• автоматная реализация интерактивных сценариев образовательной анимации с использованием Macromedia Flash;
• обучающая и тестирующая программа с примером настройки для изучения английского языка;
• совместное использование теории построения компиляторов и автоматного программирования; скелетная анимация;
• XML-формат для описания внешнего вида видеопроигрывателя ;
• управление различными объектами (дизель-генератор, турникет, кодовый замок, банкомат, светофор, кофеварка, телефон, лифт и т.д.);
• система безопасности банка;
• клиент-серверные приложения;
• построение пользовательских интерфейсов;
• реализация сетевого протокола SMTP;
• классические «параллельные» задачи («Синхронизация цепи стрелков» и «Обедающие философы»);
• моделирование игры «Пятнашки» для робота «LEGO»;
• игры («Robocode», «Terrarium», «CodeRally», «Морской бой», «Lines», «Automatic Bomber»,»Tron», «Однорукий бандит» и «Завалинка»).

При этом отметим, что среди сотен танков для игры «Robocode» [23 – 26], только танк, разработанный нами, содержит проектную документацию. Такая же ситуация имеет место и для другой, еще более известной программистской игры – «Terrarium». Известны сотни созданных по правилам этой игры существ, но проектную документацию, похоже, разработали только мы. Из изложенного следует, что если мир начал двигаться в сторону открытых исходных текстов, то можно предположить, что со временем будет разрабатываться и открытая проектная документация. Это позволит отказаться от мучительного чтения чужих программ, заменив его рассмотрением проектной документации, а когда захочется «пошевелить» мозгами, то вместо чтения программ можно будет, например, взяться за решение японских кроссвордов.

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

Последнее нас и «погубило», так как открытая проектная документация, как отмечалось выше, весьма наглядно демонстрирует не только достоинства, но и все недостатки программы. Один выдающийся программист (призер чемпионатов мира по программированию) взглянул на этот код, и студент вновь начал переделывать проект. Это (с перерывами) продолжается уже более полугода (выполнено еще несколько корректировок), и я надеюсь, что хотя бы в этом проекте (игра «Морской бой») все будет по-чеховски прекрасно: и лицо (пользовательский интерфейс), и одежда (документация), и душа (исходный код программы), и мысли (работа программы). Отметим, что все это происходит после того, как зачет по проекту был давно получен. На основе данного примера можно представить, как выглядят программы и документация на них, если они выполнены по «лицензии» as is.

Почему документация должна быть открытой?
«Открытость» проектной документации означает, что она должна, во-первых, быть, а во-вторых, быть доступной для дальнейшего использования и, возможно, модификации. «Движение за открытую проектную документацию» – свободное, однако находится в другой плоскости по сравнению с «Движением за свободное программное обеспечение» (Free Software Foundation) или «Движением за открытые исходные коды» (Open Source Foundation), так как результаты и идеи нашего Движения могут быть применены не только к свободному программному обеспечению, но и к коммерческим, секретным и к другим программам.

Заключение
Из-за высокой трудоемкости технологии, включающие создание качественной проектной документации в «программистском шоу-бизнесе» вряд ли привьются. Они являются «тяжелыми», в то время как сейчас все шире пропагандируются «легкие» и «шустрые» (agile) технологии [28], например, экстремальное программирование.

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

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

Автор полагает, что даже если движение и не получит значительной поддержки, то создание аналога Третьяковской галереи на сайте http://is.ifmo.ru, несомненно, полезно: «Для меня, истинно и пламенно любящего живопись, не может быть лучшего желания, как положить начало общественного, всем доступного хранилища изящных искусств, принесущего многим пользу, всем удовольствие» (П. М. Третьяков).

«Движение за открытую проектную документацию – это действительно то, чего разработчикам не хватает. К сожалению, практически вся документация в коммерческих проектах является собственностью заказчика, который не торопится ее обнародовать. Поэтому в Интернете так мало примеров реальных проектов. Сайтов с исходными текстами – море, а сайтов с примерами проектных решений – единицы. Я тут же залез в документацию в разделе «Проекты» вашего сайта и сравнил свои решения в аналогичных проектах с решениями, предложенными авторами. Жаль, что у меня не было доступа к этим текстам раньше. Я бы потратил на разработку меньше времени!» [29].

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

Работа выполняется при поддержке Российского фонда фундаментальных исследований по гранту № 02-07-90114 «Разработка технологии автоматного программирования».

Литература:

1. Безруков Н. Повторный взгляд на «собор» и «базар» //BYTE/Россия. 2000, № 8.
2. Literate Programming. Stanford: Center for the Study of Language and Information, 1992.
3. Lions J. Lions’ Commentary on UNIX: With Source Code. Annabooks, 1977.
4. Протасов П. Снизу //Компьютерра. 2003. № 19.
5. Исследователь «руля» //Информатика. 2003. № 11.
6. Блох А. Закон Мерфи //ЭКО. 1983. № 1–3.
7. Демин В. Проблемы выхода российских разработчиков на Запад //PC WEEK/RE. 2001. № 32.
8. Скрипников А. Когда кончится нефть // Известия. 09.09.2003.
9. Бадд Т. Объектно-ориентированное программирование. СПб.: Питер, 1997.
10. Буч Г., Рамбо Д., Джекобсон А. UML. Руководство пользователя. М.: ДМК, 2000.
11. Фаулер М. Новые методологии программирования //www.spin.org.ua
12. Буч Г. Создание будущего //Подборка статей на тему «Программы следующего десятилетия» в журнале «Открытые системы». 2001. № 12.
13. Страуструп Б. Язык программирования C++. М.: Бином, СПб.: Невский диалект. 2001.
14. Дейтел Х.М., Дейтел П.Дж. Как программировать на C++. М.: Бином, 2003.
15. Гамма Э., Хелм Р., Джонсон Р., Влиссидис Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.: Питер, 2001.
16. Фаулер М. Рефакторинг. М.: Вильямс, 2003.
17. Зайцев С.С. Описание и реализация протоколов сетей ЭВМ. М.: Наука, 1989.
18. Аллен Э. Типичные ошибки проектирования. СПб.: Питер, 2003.
19. Ершов А.П. Смешанные вычисления //В мире науки. 1984. № 6.
20. Тэллес М., Хсих Ю. Наука отладки. М.: КУДИЦ-ОБРАЗ, 2003.
21. Шалыто А.А., Туккель Н.И. Программирование с явным выделением состояний //Мир ПК. 2001, № 8, 9. http://is.ifmo.ru, раздел «Статьи».
22. Романовский И.В. Дискретный анализ. СПб.: БХВ-Петербург, Невский Диалект, 2003.
23. Шалыто А.А., Туккель Н.И. Танки и автоматы //BYTE/Россия. 2003. № 2. http://is.ifmo.ru, раздел «Статьи».
24. Озеров А. Четыре танкиста и компьютер //Магия ПК. 2002. № 11. http://is.ifmo.ru, раздел «О нас».
25. Туккель Н.И., Шалыто А.А. Система управления танком для игры «Robocode». Вариант 1. Проектная документация. http://is.ifmo.ru, раздел «Проекты».
26. Кузнецов Д.В., Шалыто А.А. Система управления танком для игры «Robocode». Вариант 2. Проектная документация. http://is.ifmo.ru, раздел «Проекты».
27. Марков С.М., Шалыто А.А. Система управления травоядным существом для игры «Terrarium». Проектная документация. http://is.ifmo.ru, раздел «Проекты».
28. Cockburn A. Agile Software Development. NJ: Addison-Wesley, 2001.
29. Трофимов С. info@caseclub.ru.

Анатолий Шалыто — доктор технических наук, профессор Санкт-Петербургского государственного университета информационных технологий, механики и оптики. Победитель конкурса исследовательских проектов в области автоматизации проектирования интегральных схем, который проводился в СНГ в 2003 г.

 В продолжение темы:

Обсуждение и комментарии

	литовец - litoveclitva.lt 4 Mar 2004 11:56 AM
Прекрасная статья, по существу.
	Дмитрий 4 Mar 2004 12:29 PM
Прекрасное решение. Именно не открытый код, а открытая проектная документация. Фактически именно это требуется на сегодняшний день. Конечная реализация - не столь важно, главное - алгоритмы и решения, заложенные в систему.
	Дмитрий 4 Mar 2004 12:32 PM
Елки-палки, да именно такие свежие решения сейчас нужны, а не эта бесконечная майкрософтовская "инновационная" гонка.
	Троль 4 Mar 2004 12:51 PM
Слова правильные, но не из этой жизни.
	Евгений 4 Mar 2004 12:55 PM
Статья прекрасная, однако все признают правоту, повосхищаются. но никто ничего делать не станет, все останется как и было.
	SuperBizon 4 Mar 2004 12:57 PM
Бред сивой кобылы. > Таким образом, технический прогресс привел к менее ответственному >программированию. само собой.программирование стало не только менее ответственное но и более дешёвое что гораздо важнее. >В конечном счете, в цивилизованной стране средний программист не должен >получать больше среднего школьного учителя. Интересно автор задавался вопросом сколько стоит подготовить среднего программиста??? > Во-первых, аппаратуру разрабатывают одни люди (организации), а >изготавливают другие. С программами так не получится от этого ещё дядька Страуструп предостеригал
	Black Bat 4 Mar 2004 1:04 PM
to SuperBizon: _Интересно автор задавался вопросом сколько стоит подготовить среднего программиста???_ не дороже среднего школьного учителя
	- 4 Mar 2004 1:08 PM
2SuperBizon: Да, не получится. Об этом еще раньше дядя Фредерик Брукс писал. Программирование - принципиально сложно.
	Сергей Середа - serge_seredahotmail.com 4 Mar 2004 1:16 PM
Статья отличная. Инициатива хороша. Но я бы добавил законодательную обязанность предоставлять корректную и качественную документацию как обязательное условие продажи программного продукта. Формально, правда, такая обязанность присутствует в законе о защите прав потребителя, но на неё предпочитают не обращать внимание. P.S. Так, значит, всё-таки, программирование есть технология, а не "свободное творчество", раз здесь не обойтись без программирования и документации. Опять не повезло поборникам "свободы творчества" ;-) С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 4 Mar 2004 1:19 PM
Пардон, опечатка вышла. Я имел ввиду: "P.S. Так, значит, всё-таки, программирование есть технология, а не "свободное творчество", раз здесь не обойтись без ПРОЕКТИРОВАНИЯ и документации." С уважением, Сергей Середа Движение "ПОтребитель"
	- 4 Mar 2004 1:23 PM
2Сергей Середа: Это только так кажется. Когда есть технология - автоматизация - отсутствие необходимости программировать. Программировать стоит только то, где еще нет технологии и невозможна автоматизация.
	Сергей Середа - serge_seredahotmail.com 4 Mar 2004 1:31 PM
В таком случае программировать нечего. В любых проектах (не "Hello world!") без технологии не уедешь никуда. Поэтомиу я и сравнивал программирование свободного ПО с кустарными ремёслами (пайка кастрюль, вязка лаптей и т.п.). Нет технологии - получается нечто недоделанное. Что мы все и имеем возможность наблюдать. С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 4 Mar 2004 1:36 PM
Позиция автора статьи отражает ГРАМОТНЫЙ подход. Отсюда можно логически вывести, какой же подход отражает позиция (уверен, очень многочисленных) оппонентов. С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	- 4 Mar 2004 1:42 PM
2Середа: >Позиция автора статьи отражает ГРАМОТНЫЙ подход Я бы не сказал. Посмотрел программу. За void z200_2() убивал бы не глядя. Прочитав несколько страниц документации так и не понял алгоритм поведения робота. Несколько строчек в начале других программ говорят больше, чем 16 страниц в его документации.
	- 4 Mar 2004 1:48 PM
2Сергей Середа: > В таком случае программировать нечего. В любых проектах (не "Hello world!") без технологии не уедешь никуда. Это совсем не так. Есть технологии правописания. Есть даже приблизительное понимание как надо писать книги. Однако, процесс существенно творческий. С программами точно так же. Точное повторение технологии позволит лишь получить точно такую же программу. Которая уже есть.
	Сергей Шишкин - sashnsx.ru 4 Mar 2004 2:02 PM
Позиция российского школьного учителя. "Натаскать" вместо того, что бы научить нестандартно мыслить... Для "совковых функционеров" может это и счастье, а для преодоления возростающей сложности - не решение проблемы.
	Andy 4 Mar 2004 2:22 PM
Имхо, наличие и объёмы проектной документации не может быть критерием качества/сопровождаемости проекта. В долгоживущем проекте в процессе его развития часть документации обязательно будет устаревать, а отслеживать актуальность документации на порядок сложнее, чем актуальность исходников. Лучше не иметь никакой документации, чем иметь не соответствующую действительности. А лучше всего - иметь красиво и грамотно написанный исходник с подробными комментариями в ключевых местах. Имхо.
	me - userinternet.com 4 Mar 2004 2:35 PM
>> В конечном счете, в цивилизованной стране средний программист не должен получать больше среднего школьного учителя Честно говоря, хочется надеяться, что в цивилизованной стране не будет никому приходить в голову определять кто сколько должен получать. Да и термин "средний" тоже чем-то подозрительным отдаёт. Скачал супер программу :)). Удивлён не был, однако. Хотя местами смешно: //=== // Класс "Стрелок". // public class gunner_t extends Object ... // Конструктор. gunner_t() ... (я тоже так люблю писать. ради хохмы) // Начало раунда. public void begin_round() // Начало шага. public void begin_turn() // Реализация автомата А1. private void A1( int e ) Много кто писал об этом (Страуструп, например): комментарии нужны там, где поведение программы неочевидно, а в остальных местах не нужны вообще. А, ну да, есть же ещё "сопроводительная документация" :))). Главный вопрос вот в чём: сколько денег отдали пользователи, чтобы наблюдать битву гигантов? Кажется, я знаю ответ...
	Qrot 4 Mar 2004 2:36 PM
куча цитат, несколько банальные истин - еще что то есть в этой статье? а тезисы про увольнение и зарплату программистов подкупают своей "новизной". в корзину.
	Андрей 4 Mar 2004 3:37 PM
Проектирование ПО снижает РОЛЬ программиста до уровня тупого кодера, каким программист и должен быть. Куча веливовозрастных психопатов в порыве выплевывания своих незрелых мыслей сразу в код порождают массу ошибок . Ну детки - если вы пишите для долбаной помойки детскую программу - плевать на ее работоспособность. А если это бухгалтерия - спасибо , кушали уже не раз. Достало получать по мозгам за великовозрастных детей, не умеющих элементарно организовать свою работу. Если кто из современных щенков-кодеров хотя бы 2 дня поработал в лет 10 назад оборонке, его бы быстро научили родину любить. Только вот обидно, КАК делать - я знаю , а вот к как порядку приучить молодых психопатичных и обидчивых. Чуть сказал, что при проверке фигня выходит - визг, писк, вопли - ВЫ козлы тупые юзеры... и.т.д.
	Yuri 4 Mar 2004 4:30 PM
> В долгоживущем проекте в процессе его развития часть > документации обязательно будет устаревать, а отслеживать > актуальность документации на порядок сложнее, чем > актуальность исходников. Лучше не иметь никакой > документации, чем иметь не соответствующую действительности. Вот чтобы этого не происходило, и существуют специализированные системы проектирования программных продуктов (типа той же Rational Rose), позволяющих поддерживать техзадания, спецификации, проектную документацию, сам код, базу чейндж-реквестов, багов и т.п. в виде единой синхронизированоой системы. К сожалению, системы эти пока что явно слишком тяжелы и недостаточно удобны, но перспективность именно такого подхода для хоть сколько-то сложных проектов несомненна. > А лучше всего - иметь красиво и грамотно написанный исходник > с подробными комментариями в ключевых местах. Имхо. Его надо иметь в любом случае. Но сам по себе такой исходник достаточен только для достаточно простых задач.
	Dmitry 4 Mar 2004 4:41 PM
Странное логическое рассуждение - если заставить программиста работать больше (писать документацию), то платить ему можно будет меньше. Ну да, если десятерых посадить делать то, что сейчас делает один - то и на документацию время останется. Хорошие, востребованные учителя, (иностранных языков, например) получают никак не меньше программистов. Отличие же хорошего программиста от плохого учителя в том, что первый работает на результат, а второй на время.
	#$% 4 Mar 2004 4:56 PM
А что тогда значит "специально для ZDNet" (как не эксклюзивность), если я эту статью, вроде как, в "Открытых системах" читал? :)
	Dmitry 4 Mar 2004 4:57 PM
Подобное "Проектирование ПО" оставляет только тупых программистов, которые зарабатывают как "средний учитель", под началом одного гениального высокооплачиваемого проектировщика. Правда, до провала первого же проекта.
	00alex 4 Mar 2004 5:13 PM
2 Сергей Шишкин: > Позиция российского школьного учителя. "Натаскать" вместо > того, что бы научить нестандартно мыслить... Для "совковых > функционеров" может это и счастье, а для преодоления > возростающей сложности - не решение проблемы. Одни гнут палку в одну сторону, Вы - в другую. Не надо научать только нестандартно мыслить. Нужно и то и другое - и натаскивать на поведение в стандартных ситуациях и научать мыслить в нестандартных... 2 Андрей: > "Куча веливовозрастных психопатов..." > "Ну детки..." > "великовозрастных детей..." > "современных щенков-кодеров..." > "Только вот обидно, КАК делать - я знаю , а вот к как > порядку приучить молодых психопатичных и обидчивых. > Чуть сказал, что при проверке фигня выходит - визг, писк, > вопли - ВЫ козлы тупые юзеры... и.т.д. " Наболело, да? Боюсь, пока Вы не охладите свой пыл, Вы все же не способны научить "щенков-кодеров". 2 Автору: А я вот не пойму, неужели Вы не читали книжки по проектированию, раз говорите, что их нет? Вроде там на западе уже как лет 10, а может и больше только с этим и носятся. Всякие Rational Software и т.п. Диаграмы Буча (или как их там?). Если честно, я не увидел новизны ни в постановке проблемы ни в предложениях по её разрешению. Или от меня по ходу чтения статьи ускользнул основной смысл написанный в теме - "...движение за открытую документацию" и Вы предлагаете сделать реестр ПО в виде проектных документаций?
	00alex 4 Mar 2004 5:18 PM
2 Автору: да и это... даже ГОСТЫ или ЕСПД в СССР было на разработку ПО. мы когда эту тему в институте (МИФИ) изучали меня аж мурашки пробирали :) Так уж заумно и далеко от жизни были те стандарты. Может Вы все-таки у Вас решение есть, а мы тут все болтаем?
	Dmitry 4 Mar 2004 5:26 PM
>Наболело, да? Боюсь, пока Вы не охладите свой пыл, Вы все же не способны научить "щенков-кодеров". Не надо никого учить - увольте этих, наймите нормальных. Если нет денег на нормальных - уж извините, на то вы и Проектировщик (с большой буквы), чтобы тупых программистов окучивать.
	00alex 4 Mar 2004 5:29 PM
2Dmitry. - давайте купим фанеры? - а нафига нам фанера? - а построим ераплан и улетим отседа к чертовой матери... Все какие-то бескомпромисные варианты предлагаются...
	Andrey 4 Mar 2004 5:38 PM
На мой взгляд есть еще одна проблема: В программировании нет единого стандарта на проектную документацию. Возьмем например электронику, принципиальные схемы разработанные в одной стране (даже в Китае, с примечаниями написаным на китайском), электронщик в другой прочитает достаточно легко, потому что схематические обозначения примерно одни и те же. В программировании немного не так. Возьмите превосходно написанную проектную документацию и если она написана на китайском, то вам её не осилить, (если вы не специалист в китайском). Нет единого обозначения, нет единых стандартов. Да есть системы для проектирования програмных продуктов (например Rational Rose). Но разве они утверждены как стандарты?А сколько лет они развиваются? А ведь есть проекты, которые длятся по 10 лет и более лет и сколько систем (подобных Rational Rose) сменилось с тех пор и сменится пока проект будет развиваться. Без единого стандарта на проектную документацию и обозначения никуда ... Есть еще проблема. Мы пишем на разных языках. Попросите программиста, который перед этим писал только на Basic разобраться в документации, написанной хорошо и грамотно, програмного продукта, который пишется на Java. Как быстро и хорошо у него это получится? :-)
	- 4 Mar 2004 5:38 PM
2 00alex: Все ищут каких-то компромиссов, поскольку наиболее хорошего решения пока не найдено. Однако, автор статьи предложил один из старых вариантов в качестве свежего. Народ недоволен.
	Dmitry 4 Mar 2004 5:39 PM
2 00alex Каков вопрос, таков ответ. Andrey, судя по всему, тоже не большой любитель компромиссов: >Проектирование ПО снижает РОЛЬ программиста до уровня тупого кодера, каким программист и должен быть. Мне, как программисту, такое читать весьма обидно. Знаем мы таких проектировщиков - напроектируют фигни всякой, потом пять лет не разгребешь. Я же считаю, что любой программист, должен быть проектировщиком (в рамках своей ответственности и компетентности), а любой проеектировщик - программистом. По сути - это одна и та же профессия. А что такое тупой кодер и чем он может быть занят при разработке программного обеспечения, я не знаю.
	- 4 Mar 2004 5:41 PM
2Andrey: Наиболее полная и точная документация на программу это сама программа. Это факт и от этого никуда не уйдешь. Все остальное - повышение уровня абстракции. Если высоко поднимешь - поведение останется не ясным. Слишком низко - трудоемкость понимания будет такая же как у программы. А зачем, спрашивается, нужна еще одна программа, только в виде документации?
	Dmitry 4 Mar 2004 6:01 PM
Согласен - имеет место быть принцип разумной достаточности. Замечательно, если твоя программа хорошо и полно документирована. Но что с того толку пользователю, да и тебе, если она из-за этого вышла на полгода позже и стоит в три раза дороже чем у конкурентов. Останешься без штанов, однако. Вот из-за этого много проблем. С другой стороны, в ответственных приложениях (типа программ управления ядерными реакторами), там где это реально нужно - документация давно есть, стандартизирована и используется. А в бухгалтерии - что там документировать, если там правила и нормы меняются с ужасающей скоростью, зачастую проще все с нуля переписать, чем развивать существующую систему.
	Dmitry 4 Mar 2004 6:07 PM
Вдогонку. Замечательно, если твоя программа хорошо и полно документирована - но лучше, если она хорошо и правильно написана! Поэтому каждый программист должен быть проектировщиком, а каждый проектировщик - программистом.
	MOHTEP 4 Mar 2004 6:20 PM
Когда прикрыть аргументы нечем, то остается писать "Это факт и от этого никуда не уйдешь". Подбросим еще фактов, от которых "никуда не уйдешь": 1. Убогие языки программирования типа С и С++ породили новую породу - программист-шифровальшик. Вместе они открыли двери большинству современных вирусов прочих червей. Вывод - запретить и разогнать! 2. Чукча не хочет быть читателем, он хочет быть писателем. Это девиз линуксоидов. Заветная мечта их - получать деньги за то, что они ПОМНЯТ команды программы, которую написал 20 лет назад, какой-то студент. Вывод - пусть платят SCO за украденный у низ код. 3. Open Source - движение неудачников, которые не способны изобретать новое и зарабатывать на этом деньгм. Они дружно ненавидят тех, кто все это может - особенно Била Гейтса, который все это может особенно хорошо. Миллионы глаз присматривающих за кодом на поверку оказались парой сотен глаз, пытающихся расшифровать свой собственный код трехмесячной давности. Вывод - отойти и не пачкаться.
	Dmitry 4 Mar 2004 6:33 PM
Когда хочется опровергнуть очевидный факт, то остается писать: " Когда прикрыть аргументы нечем, то остается писать "Это факт и от этого никуда не уйдешь" Насчет C/C++ - зато наши программы заканчиваются до обеда :)
	torvic 4 Mar 2004 6:36 PM
Manifesto for Agile Software Development: ... WORKING SOFTWARE over comprehensive documentation ... Если не вешать ярлыки "шоу-бизнес" "легкие технологии" и вспомнить, что IID(Iterative and Incremental Development) зародилось в 30-х годах прошлого века, то возможно все окажется не так уж и печально.
	Dmitry 4 Mar 2004 6:48 PM
сущность Agile Software Development - пишите программы как умеете; если Вы хороший программист - у Вас получится. С этим трудно спорить :)
	нц 4 Mar 2004 6:52 PM
2 MOHTEP! Браво!!! Бурные продолжительные апплодисменты :)
	xacid 4 Mar 2004 7:12 PM
2 Монтёр а ВЫ то тут причём? если у билли по вашим словам что то там получается (что еще далеко не факт - у Киркорова тоже много чего получается, но это еще не значит что он гений а остальные имбецилы), то даже если закрыть глаза на все попытки билли внушить юзерам что они (билли) "работают" над повышением качества своего когда (по поводу секюрности), то всё равно остается непонятно причем тут вы (Монтёр) и чем линуксоиды вам мешают проектировать ваши программы и писать их так как вы того хотите или умеете или еще что там у вас... если вы конечно вообще что то умеете... программы писать например....
	Хрю 4 Mar 2004 7:13 PM
Из статьи: "среди теоретиков программирования складывается представление, что..." Извините, но среди практиков программирования складывается представление, что "теоретики программирования" питаются булками, растущими на березах. При этом не забывая высказывать свое компетентное мнение о том, сколько денег должен получать "средний программист". Из статьи: "Один из наших проектов после восьмой (что далеко не рекорд)корректировки(которая привела к тому, что мой ... студент..." и далее про это "проект": "Это (с перерывами) продолжается уже более полугода (выполнено еще несколько корректировок), и я надеюсь, что хотя бы в этом проекте(игра «Морской бой») все будет по-чеховски прекрасно:" Вот и придет этот студент на работу с умением спроектировать и написать морской бой с аккуратненькой документацией всего за каких-то полгода :( И будет удивлятсья что денег он получает гораздо меньше чем предсказывали "теоретики программирования"...
	Andrey 4 Mar 2004 7:28 PM
Я согласен, что хорошо написанная программа сама по себе является хорошей документацией, но до известных пределов (пределы условные и каждый их определяет для себя сам), например: Программа до 1000 строк - легче просто изучить программу. Программа до 10000 строк - наверно надо бы посмотреть в документакцию. Более 10000 строк - все-таки надо почитать документацию в первую очередь. Но есть еще несколько условий, одно из них, что если ваша программа используется в каком-то достаточно большом программном продукте, то документация на неё необходима, какого бы размера она не была.
	Ишо монтер 4 Mar 2004 7:37 PM
2xacid у Киркорова тоже много чего получается, но это еще не значит что он гений а остальные имбецилы Если некто добился в некоей области успеха, значит он гений. Если он лично Вам не нравится (мне тоже ;)), значит Вы с ним просто в разных областях. А с Билли Вы в одной области. P.S. Наконец-то громко прозвучало, что от мегабайтов исходников мало-мальски сложного софта толку с хрен да чуточку. Если, конечно, их изучение и развитие не есть основное занятие. Миллионы глаз блин...
	me - userinternet.com 4 Mar 2004 7:50 PM
>> Программа до 1000 строк, 10000 и так далее Не надо ля-ля. Есть только один вопрос, который сразу необходимо задать (или прочитать где-нибудь): что программа должна делать. Оставьте подсчёт строк тем, кто пишет диссертации. >> Убогие языки программирования типа С и С++ породили новую породу - программист-шифровальшик. "А лопаткой по е##лу?" :))) Зато эти шифровальщики написали кучу программ для написания вот таких вот статей, а хаятели - морской бой и танчики.
	Andrey 4 Mar 2004 8:05 PM
To me: Я предложил один из критериев (а их много), и полагаю, что прежде чем начинать читать исходники программы, надо естественно ознакомиться, а что же программа делает и для чего она нужна.
	Дмитрий 4 Mar 2004 8:11 PM
Andrey says: > Я согласен, что хорошо написанная программа сама по себе является хорошей документацией, но до известных пределов (пределы условные и каждый их определяет для себя сам), например: Программа до 1000 строк - легче просто изучить программу. Программа до 10000 строк - наверно надо бы посмотреть в документакцию. Более 10000 строк - все-таки надо почитать документацию в первую очередь Ню-ню. Это с каких таких пор программа стала сама себе документацией. Широко известно, что отсутствие надлежащих комментов в теле программы является как минимум дурным тоном. Фи, Андрюша. К тому же Анатолий Шалыто прямо привел прекрасный пример, когда долго не могли понять программу на Си из 6 (!) строк. Верю. Ну прям случай из практики любого программера, имеющего несчастье разбираться в чужом коде; случай, встречающийся нередко в текущей работе. Ну а сколько нервов стоит программеру эта процедура, и говорить не стоит (REM прошу прощения за каламбур). от автора: "В центре Парижа из-за отказа компьютерной системы управления в новом дорогом автомобиле чуть не погибли люди, так как кондиционер перестал работать, двери не открывались, а бронированные стекла даже снаружи удалось разбить далеко не сразу" Ну это еще не самый яркий случай из практики багов... В 1985-м на одном из участков советского национального газопровода был боооольшой барабум, и как оказалось, из-за "ошибки" в промышленном ПО, намеренно вставленной Пентагоном в рамках холодной войны. Прога была штатовская. Ссылку искать сейчас не буду, лень; - позавчера была новость от Washington Post.
	Дмитрий 4 Mar 2004 8:13 PM
2 me: > "А лопаткой по е##лу?" Это на Си, что ли, написено?
	Дмитрий 4 Mar 2004 8:15 PM
2 me: прокомментируйте вашу программу, пожалуйста. И проектную доку на стол к понедельнику.
	Mraer -> Хрю 4 Mar 2004 8:38 PM
>Вот и придет этот студент на работу с умением спроектировать и >написать морской бой с аккуратненькой документацией всего за >каких-то полгода :( И будет удивлятсья что денег он получает >гораздо меньше чем предсказывали "теоретики >программирования"... Этот студент мой приятель. Он выдающийся программист. Вот этот студент уже и пришел на работу и денег получает достаточно, в частности потому, что умеет делать проектную документацию. Вы лучше посмотрите на сайте http://is.ifmo.ru раздел "Проекты" и попробуйте так оформить свои. Хорошо оформить проектную документацию трудно, особенно в первый раз.
	Шалыто -> Dmitry 4 Mar 2004 8:41 PM
>сущность Agile Software Development - пишите программы как >умеете; если Вы хороший программист - у Вас получится. С этим >трудно спорить :) Желаю Вам или самому этому хорошему программисту почитать такие программы лет через пять.
	me - userinternet.com 4 Mar 2004 8:43 PM
Это на си-шарпе, Дмитрий. >> долго не могли понять программу на Си из 6 (!) строк Не верю.
	Шалыто -> MOHTEP 4 Mar 2004 8:46 PM
>3. Open Source - движение неудачников, которые не способны >изобретать новое и зарабатывать на этом деньгм. Они дружно >ненавидят тех, кто все это может - особенно Била Гейтса, >который все это может особенно хорошо. Миллионы глаз >присматривающих за кодом на поверку оказались парой сотен глаз, >пытающихся расшифровать свой собственный код трехмесячной >давности. Вывод - отойти и не пачкаться. Позавчера приехал с Linux Summit'а. Его участники мне неудачниками не показались. А Линус Торвальдс он как по-вашему, неудачник? Почитайте книгу "Ради удовольствия" Линуса Торвальдса и тогда, может быть, много чего поймете.
	me - userinternet.com 4 Mar 2004 8:46 PM
>> Вы лучше посмотрите на сайте http://is.ifmo.ru раздел "Проекты" и попробуйте так оформить свои. Хорошо оформить проектную документацию трудно, особенно в первый раз. А вы лучше посмотрите на сайте раздел "проекты" и попробуйте их продать.
	Шалыто -> 00alex 4 Mar 2004 8:49 PM
> Может Вы все-таки у Вас решение есть, а мы тут все болтаем? Посмотрите, пожалуйста, сайт http://is.ifmo.ru, раздел "Проекты".
	Шалыто -> 00alex 4 Mar 2004 8:55 PM
2 Автору: А я вот не пойму, неужели Вы не читали книжки по проектированию, раз говорите, что их нет? Вроде там на западе уже как лет 10, а может и больше только с этим и носятся. Всякие Rational Software и т.п. Диаграмы Буча (или как их там?). Если честно, я не увидел новизны ни в постановке проблемы ни в предложениях по её разрешению. Или от меня по ходу чтения статьи ускользнул основной смысл написанный в теме - "...движение за открытую документацию" и Вы предлагаете сделать реестр ПО в виде проектных документаций? Вы пробовали спроектировать программу со сложным поведением с использованием UML? На указанном выше сайте мы показываем более эффективный путь. Кроме того, в этих книгах про реализацию ни слова, а там, где есть про реализацию - ни слова про проектирование.
	Шалыто -> Андрей 4 Mar 2004 9:00 PM
>Если кто из современных щенков-кодеров хотя бы 2 дня поработал >в лет 10 назад оборонке, его бы быстро научили родину любить. Родину учат любить в оборонке и сегодня. И разговоры там не про бабки, а про то полетела ли ракета или нет, и куда полетела. Это для настоящих мужчин значительно серьезнее. И еще. В фильме "Офицеры" такая фраза: "Есть такая профессия - Родину защищать". А когда защищаешь Родину не до бабок.
	me - userinternet.com 4 Mar 2004 9:03 PM
>> На указанном выше сайте мы показываем более эффективный путь Я, конечно, извиняюсь, что я не 00alex. Из всей писанины, называемой "проектной документацией" можно более или менее нормально читать графы состояний. Самый типичный UML, между прочим. Графоманские изыски читаются терпимо просто потому, что не программисты их писали.
	Шалыто -> Евгений 4 Mar 2004 9:07 PM
>Статья прекрасная, однако все признают правоту, повосхищаются. >но никто ничего делать не станет, все останется как и было. А у нас количество проектов будет возрастать. Люди смогут учиться по хорошим проектам и доказывать другим, что у них плохие проекты. Никакого другого пути для обучения, кроме как на открытых примерах не существует.
	Шалыто -> me 4 Mar 2004 9:09 PM
Продавать будете Вы с Биллом Гейтсом, а я буду учить толковых мальчиков, что в жизни есть цели, кроме того, чтобы продать и купить.
	Mraer -> me 4 Mar 2004 9:13 PM
Графоманские изыски читаются терпимо просто потому, что не программисты их писали. Странно, но я считал, что я не графоман, а профессиональный программист :) Также считает и мой начальник. Кончайте дурить - ничего в реальной жизни мы не документируем. И это надо честно признать и закончить перепалку.
	Black Bat 4 Mar 2004 9:15 PM
to me: _Есть только один вопрос, который сразу необходимо задать (или прочитать где-нибудь): что программа должна делать_ м-да, если вы таки пишете программы, по отношению к которым можно дать такой определённой ответ - то ладно, можете не писать документацию. Тут люди о совершенно других масштабах говорят.
	Bulat - rootbulat.f0.ru 4 Mar 2004 9:59 PM
Ошибки в программах во многом отнюдь не от отсутствия проектной документации. А от того что обычно не осуществляется формальное доказательство корректности алгоритмов и доказательство их соответствия формализованным представлениям задач (такие представления, кстати, и сами обычно отсутствуют). P.S. Статью не читал, но вторую часть заголовка поддерживаю в том смысле, что если у кого есть проектная документация - публикуйтем ее тоже, а не только исходники.
	torvic 4 Mar 2004 10:24 PM
> Тут люди о совершенно других масштабах говорят. А это самое agile development с неба свалилось что-ли? Оно и выросло из реальных крупных проектов, где классическая модель водопада облажалась в 75% случаев с КПД 2%. ---- >сущность Agile Software Development - пишите программы как >умеете; если Вы хороший программист - у Вас получится. С этим >трудно спорить :) --- А этой самой лопаткой по попе??? Не говорится пишите "как умеете", наоборот основной принцип: цель проектирования - ИСХОДНЫЙ КОД. И не надо так убиваться по поводу документации и "проектирования больше нет". Просто утверждается, что грамотно написанный и закомментированный код сам по себе - лучшая документация, и проектирование никуда не делось, просто размазалось во времени и пространстве. >А от того что обычно не осуществляется формальное доказательство корректности алгоритмов и доказательство их соответствия формализованным представлениям задач. Да-да-да, а позвольте поинтересоваться как вы собираетесь это доказывать? Единственный вариант в случае с императивными языками, который я себе предствляю, это построение КА и трассировка всех его возможных состояний. Вы не Дункан Маклауд в реале? Или все строем на декларативные языки?
	MOHTEP 4 Mar 2004 10:45 PM
Линус - типичный неудачник. В америке на работу еле устроился. На шлюниксе не разбогател, но до сих пор продолжает клепать новые версии. Книжку написал про онанизм (см. название). А ведь началось все с того, что начал он язык С изучать, потом С++, и покатился...
	Хрю 5 Mar 2004 12:38 AM
2Mraer: "Этот студент мой приятель. Он выдающийся программист...Вы лучше посмотрите на сайте http://is.ifmo.ru раздел "Проекты..." Учел. Зашел. Посмотрел. Вот top 10 проектов из этого раздела (для тех кто поленился сходить по урлу): 1. Туккель Н.И., Шалыто А.А. Система управления танком для игры "Robocode". Вариант 1. Объектно-ориентированное программирование с явным выделением состояний 2. Кузнецов Д.В., Шалыто А.А. Система управления танком для игры "Robocode". Вариант 2 3. Добрицкий И.О., Куликов А.А., Шалыто А.А. Игра "Lines" 4. Хокканен А.В., Шалыто А.А. Имитатор игрового автомата класса "Однорукий бандит" 5. Марков C.M., Шалыто А.А. Система управления травоядным существом для игры "Terrarium" 6. Пенев В.П., Степаненков В.В., Сучкоусов Е.А., Шалыто А.А. Компьютерная игра "Automatic Bomber" 7. Подтопельный М.А., Чеботарева А.А., Шалыто А.А. Робот, ищущий выход из лабиринта 8. Лопатухина А.Д. Модель искусственного интеллекта игрового "бота" 9. Южаков Е.М. Построение автономного виртуального робота на основе автоматного подхода (на примере игры «CodeRally», предложенной на Java Challenge туре чемпионата мира по программированию по версии ACM 2003 г.) 10. Веденеев В.В., Соловьев П.С. Система управления текстовой игрой "Завалинка". Комментарии излишни, я думаю? 2Шалыто "а я буду учить толковых мальчиков, что в жизни есть цели, кроме того, чтобы продать и купить." А также покушать и покакать? А "толковых мальчиков" я кажный день на на работе наблюдаю. Многие и впрямь толковые. Вот только "теоретики программирования" так сильно зомбировали их РУПами и ЮМЛами что помогает только шоковая терапия в виде _реальных_ проектов_ (типа _не_ open source Морской Бой)
	me - userinternet.com 5 Mar 2004 1:45 AM
>> Тут люди о совершенно других масштабах говорят. Само собой. Люди тут говорят об игре "Морской бой". Думают, как бы его задокументировать получше. >> и доказывать другим, что у них плохие проекты Собственно, с этого и надо было начинать статью. А то кое-кто впал в эйфорию от очередной серебряной пули.
	Проходящий мимо - xwarlockmail.ru 5 Mar 2004 7:49 AM
С точки зрения заказчика: 1)Любое ПО должно быть документировано. Если ПО заказное - то документация предоставляется заказчику в полном объеме. Если нет (скажем розничные продажи) - то в объеме, достаточном для понимания функциональности, алгоритма работы, и потенциальных опасностей. 2)Объем этой документации может варьироваться, но должен быть стандартизован. 3) В настоящее время , все еще действует ЕСПД , являющаяся обязательным документом!!! :)) Она конечно устарела, и ее надо бы привести в соответствие с реалиями. 4) На продажу ПО AS IS должен быть наложен (IMHO) законодательный запрет. Т.е. либо за деньги - с документированием, либо AS IS но только бесплатно.
	Проходящий мимо - xwarlockmail.ru 5 Mar 2004 7:56 AM
2Mraer "Кончайте дурить - ничего в реальной жизни мы не документируем." Попробуйте с таким подходом прийти на взрывопожароопасное производство - сразу узнаете о себе много интересного :)))
	С. Коротких - svkmicex.com 5 Mar 2004 10:30 AM
Резон в рассуждениях есть и немалый. Однако, пеняя на "неумение изложить свои мысли" и неаккуратность, автор сам же и демонстрирует в статье образчики неаккуратности и небрежности (нумерация ссылок на источники "съехала", упоминая греческую и египетскую школу и поставив вначале греческую, он относит подход "Смотри" к "последней", то есть, получается - египетской). Ну, и насколько качественной может быть документация студентов такого преподавателя:)
	me - userinternet.com 5 Mar 2004 10:41 AM
>> Кончайте дурить - ничего в реальной жизни мы не документируем Именно. Мы лишь пишем комментарии и читаем чужие. В крайнем случае задаём вопросы типа "Чё за ботва?". То, что получаются не танчики - не беда. Заказчик не их просит. >> Любое ПО должно быть документировано А никто и не спорит. Вопрос в том, когда считать, что ПО задокументировано достаточно. Кроме того, автор статьи почему-то считает проектировщиков небожителями, которые не ошибаются никогда и всё-всё-всё способны предусмотреть. Очевидно, что литература 60х годов (или когда там Брукс писал своего человеко-месяца?) была ему недоступна. >> На продажу ПО AS IS должен быть наложен законодательный запрет А вот эти совковые замашки ты брось, дорогой друг. Не к лицу они.
	Вадим Гуров - vgurovevelopers.com 5 Mar 2004 10:49 AM
Судя по комментариям, своей статьей автор затронул действительно серьезную проблему, единого решения которой на данный момент не существует. Авторам комментариев, отмечающих простоту проектов представленных на сайте is.ifmo.ru, хочу напомнить принцип суперпозиции: сложная сущность есть суперпозиция множества простых.
	Andy 5 Mar 2004 10:51 AM
2Проходящий мимо: "Любое ПО должно быть документировано. Если ПО заказное - то документация предоставляется заказчику в полном объеме. " Всё это хорошо. Но по-прежнему существует возможность нагенерить ворох вордовских файлов, которые методом контекстной замены (названия проекта) + косметической доработки напильником (одному человеку на два дня) будут превращаться в документацию по ЛЮБОМУ проекту. А определить насколько эта кипа документов непригодна к практическому использованию непросто, надо как минимум этот весь объём тщательно изучить. Так что, имхо, запреты и предписания тут помочь не могут. Да и ещё - не стоит смешивать проектирование и проектную документацию. Это далеко не одно и то же.
	Владимир Габриель - gabrieldigdes.com 5 Mar 2004 11:01 AM
А что, мне нравится идея, если бы ZDNet выступил бы в качестве площадки то я бы был готов начать открывать документацию и процесс разработки www.docsvision.com
	СтранниК 5 Mar 2004 11:19 AM
2Хрю Я бы на вашем месте еще суда посмотрел. http://www.softcraft.ru/auto.shtml
	Шалыто - Коротких 5 Mar 2004 11:20 AM
Хорошо Вам, Вы точно знаете кто ошибки делает! Даже мысли не допускаете, что сдвиг нумерации может произойти не только по вине автора текста. Главное вмазать, правда?
	Шалыто - Qrot 5 Mar 2004 11:27 AM
Очень похоже на правду, но не правда, так как не прочли главного - кроме утверждений и цитат мы делаем открытые проекты, с которыми могли ознакомиться, но Вам это не важно, правда? Вы этого просто не заметили! Но полить первое дело! Очень по нашему, по-совковому!
	СтранниК 5 Mar 2004 11:36 AM
А насчет темы, на мой взгляд у автора есть более работы. Например эта: http://is.ifmo.ru/?i0=works&i1=tech_aut_prog И начать бы как раз стоило с нее.
	Шалыто - Хрю 5 Mar 2004 11:39 AM
Не понял юмора про топ -проекты! Если Вы подобное найдете еще где-нидудь в русском Интернете сообщите! А про игру Robocode - из десятков тысяч танков только у нас есть проектная документация, поэтому их легко модифицировать, что было сделано во втором варианте танков при обучении детей студентом Д.Кузнецовым во Дворце творчества юных. Но Вам, ведь, наплевать на это и на юных и кто их будет учить и как? Главное - пожрать и ... А Денис, между прочим, двухкратный призер командного чемпионата МИРА по программированию, но Вам и это неважно! Главное - хрю!
	Шалыто - Проходящий мимо 5 Mar 2004 11:43 AM
Мы выразились некорректно - в реальной программистской жизни практически ничего не документируется, а не вообще в жизне. Хотя не не уверен, что ПО во взрывоопасных системах хорошо докуметирован. А Вы уверены!
	Шалыто - me 5 Mar 2004 11:47 AM
Да читал я Брукса и даже тогда! Почитайте новое издание Брукса и там сказано, что к серебрчной пуле приближается только подход Харела, а у нас подход лучше! Вот и все!
	СтранниК 5 Mar 2004 11:52 AM
На мой взгляд основные идеи ( может я конечно заблуждаюсь, да простит меня автор ) которые я подчерпнул из некоторых работ автора: 1. Переход на автоматное программирование состояний, позволит индурстрии ПО создавать программные продукты с гарантированным качеством, на не "AS IS" и соответственно отвечать за качество , чего очень многим этого бы не хотелось. 2. Возможность автоматической генерации программ на основе графов состояний , позволит больше уделять времени проектированию и в свою очередь отпадет проблема лицензирования исходного кода, как такова. Кому нужен автоматически генерируемый код? Когда основная идея это схема графов состояний. 3. Возможно опадет проблема патчей, как таковых. Однако я очень сильно сомневаюсь, что производители ПО заинтересованы в качественном ПО. Они не на этом деньги зарабатывают.
	Шалыто - Габриелю 5 Mar 2004 11:59 AM
Спасибо за поддержку! Хочу отметить, что понятие "проект" в жизни и в инженерной практике сильно отличаются. Проект "Фабрика звезд" напоминает программный проект, но сильно отличается от проекта корабля или самолета = в основном объемом проектной документации! В одной книге по ПО было написано, что самолет полетит, когда его вес сравняется с весом его проектной документации! И так на самом деле! Хотяи и на самолетах, я думаю, что с документацией на ПО далеко от идеала! И последнее! На сайтах с открытми исходниками лежат десятки тысяч программ, а не проектов, так там практически нигде нет подробной, хорошо написанной проектной документации!
	00alex -> Шалыто 5 Mar 2004 12:08 PM
>> 2 Автору: >> А я вот не пойму, неужели Вы не читали книжки по >> проектированию, раз говорите, что их нет? Вроде там >> на западе уже как лет 10, а может и больше только с этим >> и носятся. Всякие Rational Software и т.п. Диаграмы Буча >> (или как их там?). >> Если честно, я не увидел новизны ни в постановке проблемы >> ни в предложениях по её разрешению. >> Или от меня по ходу чтения статьи ускользнул основной >> смысл написанный в теме - "...движение за открытую >> документацию" и Вы предлагаете сделать реестр ПО в виде >> проектных документаций? > Вы пробовали спроектировать программу со сложным поведением > с использованием UML? Пробовал ;-) У вас, например, есть проект "однорукий бандит", а мы проектировали многопользовательское онлайн казино с разными играми, и работать ПО должно было на нескольких серверах ;-) > На указанном выше сайте мы показываем более эффективный путь. Нет. Не показываете. Вы говорите, что знаете этот путь, но не показываете - показываете примеры "как кто-то прошел". Людям нужны и примеры и МЕТОДИКА! Как в какой последовательности заниматься. > Кроме того, в этих книгах про реализацию ни слова, а там, > где есть про реализацию - ни слова про проектирование. Согласен. Ответ на вопрос как заниматься проектированием (а не составлением проектной документации) - ни в одной книжке я пока не нашел. Даются рекомендации, советы, выдвигаются гипотезы, приводятся примеры. Но нет алгоритма, с чего начать, и как двигаться дальше. Вот возьмем пример решения дифференциальных уравнений. Кто-то умный придумывает метод, потом проверяет, потом рассказывает - все его осваивают. UML (по аналогии с решением дифф.уров) - это просто язык математической записи. Вот если бы Вы, Анатолий, придумали достаточно простую методику позволяющую упростить задачу проектироавния - индустрия сказала бы Вам спасибо, возможно выдав гранты для работ Ваших студентов. Придумывать сложную методику, которая по своей сути сложнее, чем решаемая задача - смысла нет. Возьмем Ваш пример "бота для игры в стрелялки" - 80% описания к программе (исключая правила игры (Тех.требования), диаграммы состояний и связей, и пары вводных предложений зачем все это нужно) - можно внести в код. Перед описанием каждого класса описать зачем он нужен и с какими связан. Второй момент, который для меня представляет интерес в поставленной Вами проблеме - создание реестра алгоритмов на основе метаязыка - понятно описывающего алгоритм, а не конкретную реализацию в языке. (Сразу скажу, что диаграммы состояний, как машине Тьюринга тут не подходят - слишком большое количество самих состояний и алфавита - необходимы разумные упрощения) Последнее. Попросите какого-нибудь своего знакомого, который не знает о Вашем сайте, зайти туда и посмотреть и рассказать о чем он. У меня не хватает терпения внимательно изучить все материалы, проблемы возможно: а) в отсутствии четкой цели/задачи сайта б) в плохом анонсировании в) плохой навигации Коротко: его сложно использовать В остальном, желаю удачи! :)
	Шалыто - Страннику 5 Mar 2004 12:12 PM
Все, что Вы написали - это идеал! К этому мы стремимся и работаем! Если сможем протянуть на энтузиазме еще лет пять, то посмотрим, что будет! Кстати, посмотрите чей портрет рядом с моим и прочтите его статью! Озаботился, что талантов надо растить и методы программирования надо создавать! И я об этом! И уже несколько лет делаю и буду делать вне зависимости будут платить или нет и что себе думают производители коммерческого ПО! На прошлой неделе я выступал после Ричарда Столлмана (www.linuxsummit.org), он уже держится с 1983 года и кое-чего добился и я с мальчиками добъюсь! Даже не сомневаюсь! Только бы здоровья и талантливых мальчиков хватило!
	Шалыто - 00alex 5 Mar 2004 12:21 PM
Вот и разговор, наконец, пошел в другом тоне! Спасибо за добрые пожелания! Как вести проектирование для программируемых логических контроллеров я знаю. А для того чтобы разобраться про ООП с автоматами я и веду проекты. Пока сею, потом буду собирать урожай. Мальчики начали делать работы, обобщающие и классиыфицирующие проекты. Так, что мне осталось, день простоять и ночь продержаться! Надеюсь удастся, я очень много работаю, а ребята - супер!
	Qrot 5 Mar 2004 12:22 PM
Шалыто: да нет у вас проектов на сайте. с таким же успехом вы могли бы hello, world! документировать и называть это "проектом". уверен, что не одно поколение студентов получило бы на этом зачет автоматом. лично я (и думаю господин Хрю) с гораздо большим бы уважением отнесся к коммерческим проектам - ограничения по сроком, постонно меняющиеся требования. где такие проекты на вашем сайте? я думаю после первого же практического применения вашей методы, у вас бы несколько поубавилось спеси и нетерпимости.
	СтранниК 5 Mar 2004 12:26 PM
2Шалыто Больше всего меня поразило в ваших работах, так это то, что создание программ не отличается от проектирования схем электроприводов. Я просто когда-то учился по специальности "Электропривод и автоматизация производственных процессов" и мне всегда казалось, что Теория автоматического управления , где-то не далеко от программирования , больше того изучение этого курса очень сильно мне помогло в дальнейшем. Когда в одной из статей промелькнуло имя академика Ляпунова, я понял, что круг замыкается. С удовольствие читаю материалы на сайте: http://www.softcraft.ru/auto.shtml Желаю вам крепкого здоровья и удачи в осуществлении ваших планов.
	СтранниК 5 Mar 2004 12:32 PM
2Qrot Вот тут нам недавно статистику приводили, о том что 90 процентов коммерческих проектов не вписывается сроки. А уж про перерасходы бюджета я вообще молчу. А сколько среди них успешных? По статистике в лучшем случае 10%. Это сегодняшний день. Так чем же здесь гордится? Что есть у вас, что позволит коммерческому проекту вписаться в отведенные сроки и сумму проекта?
	Qrot 5 Mar 2004 12:47 PM
СтранниК: > Что есть у вас, что позволит коммерческому проекту вписаться в > отведенные сроки и сумму проекта? здравый смысл как при оговаривании сроков и сумм, так и при разработке. и я призываю вас отнестись к этому инструменту со всей серьезностью. но этот вопрос вобщем мало относится к статье - критерием успешности там объявляется качественная (красивая) документация, а не выполнение проекта в срок.
	Dmitry 5 Mar 2004 12:49 PM
Dmitry -> Шалыто >Желаю Вам или самому этому хорошему программисту почитать такие программы лет через пять. В чем проблема? Сейчас вношу изменения в программу, написанную 4 года назад. Реальный проект в несколько сот тысяч строк. Все достаточно тривиально. Еще раз повторяю свою мысль для непонятливых - в реальном мире мы всегда имеем дело с ограниченными ресурсами. Я предпочитаю потратить их на написание хорошего кода, чем на избыточное документирование плохого (типа это конструктор, это деструктор, здесь присваиваем переменной a_102_18 значение переменной b_104_25). Людям из академического мира этого, конечно, не понять. Они могут позволить себе тратить годы на создание и документирование программки, которую можно написать и вылизать до блеска за неделю. Если же заказчик желает получить полную проектную документацию и готов заплатить за ее наличие двойную цену - нет проблем (часто заказчик не готов). Кроме того, имею опыт работы с документацией на продукты сторонних производителей. И часто приходит мысль, как хорошо было бы выкинуть эту [censored] документацию к чертям и взглянуть на исходный код. Сам я не против разумного (разумного) документирования. Так документ - описание концепции, содержащий рассмотренные, принятые и отклоненные архитектурные решения, неочевидные трудности, возникшие при реализации, может быть краткое описание базовых классов, полезен всегда. Все остальное есть в коде.
	Хрю 5 Mar 2004 12:55 PM
2Шалыто: "Не понял юмора про топ -проекты!" Не удивительно. Ведь я как раз и пытался толсто намекнуть на пропасть между программированием "теоретическим" и практическим. "...из десятков тысяч танков только у нас есть..." А вы еще и продолжаете смешить :)))) "..при обучении детей студентом Д.Кузнецовым во Дворце творчества юных. Но Вам, ведь, наплевать на это и на юных..." Так может быть вам следует точнее определить целевую аудиторию своих статей? Вы говорите о проектировании _чего_? Текстовой игры "Завалинка"? Кому? Пионерам? Тогда о чем мы тут спорим? Это в мурзилку. Вы хотите говорить о проблемах проектирования и документирования серьезных коммерческих проектов? Тогда давайте аргументы и ссылочки посерьезней чем опын-сорц-морской-бой.
	Dmitry 5 Mar 2004 12:58 PM
>здравый смысл как при оговаривании сроков и сумм, так и при разработке. Полностью согласен. Принцип разумной достаточности
	Andy 5 Mar 2004 1:03 PM
2Dmitry: "Кроме того, имею опыт работы с документацией на продукты сторонних производителей. [...skipped...] Все остальное есть в коде." Согласен на 100%!
	СтранниК 5 Mar 2004 1:04 PM
2Qrot здравый смысл как при оговаривании сроков и сумм, так и при разработке. и я призываю вас отнестись к этому инструменту со всей серьезностью. но этот вопрос вобщем мало относится к статье - критерием успешности там объявляется качественная (красивая) документация, а не выполнение проекта в срок. === Просто я бы не рассматривал качественную документацию как само-цель, однако вы наверно слышали как у Чехова: "У человека(читай проекта) все должно быть красиво и душа(цель проекта достигнута) и тело ( своевременно и в срок и за оговоренные деньги) и мысли( документация в порядке)" А теперь вопрос, при хронически опаздывающих проектах чем в первую очередь жертвуют? Как правило документацией.
	Хрю 5 Mar 2004 1:09 PM
2Шалыто: "На прошлой неделе я выступал после Ричарда Столлмана ... Только бы здоровья и талантливых мальчиков хватило!" Верно. Для последователей Троцкого (тьфу ты, Столлмана.. шо ж я все время их путаю то, а?) "талантливые мальчики" являются расходным материалом. Мальчики подрастают, перестают играть в танчики, знакомятся с симпатичными девочками, цветы жизни.. туда-сюда... и им начинает хотеться денюшки... А Троц..т.е. Столлман не велит. Вот и расходуются мальчики. Только бы их хватило на очередной танчик!
	me - userinternet.com 5 Mar 2004 1:19 PM
>> 1. Переход на автоматное программирование состояний, позволит индурстрии ПО создавать программные продукты с гарантированным качеством Почитал бы теорию алгоритмов, что ли... Раз уж теоретик. 2. Возможность автоматической генерации программ на основе графов состояний , позволит больше уделять времени проектированию Вот она, пуля-то :))). 3. Возможно опадет проблема патчей, как таковых. Для начала предлагаю позакрывать все ремонтные мастерские. Потом будем говорить про патчи.
	Хрю 5 Mar 2004 1:22 PM
2СтранниК: "А теперь вопрос, при хронически опаздывающих проектах чем в первую очередь жертвуют? Как правило документацией. " Часто ею пожертвовать невозможно (Денюшку презренную не заплотют, волки). Тогда документация превращается в отмазку :(. И не мы такие, а жизнь такая. ЗЫ: Юмор ситуации в том что я прям щас торчу в инете оттягивая тот неизбежный момент, когда мне придется начать писать документацию и уже написанному и работающему проекту :) Еще бы пару часиков продержаться а там уже и пьянка за восьмое марта начнется :)))
	- 5 Mar 2004 1:23 PM
2Шалыто: когда делают серьезную аппаратуру, ее программируют на языке verilog, а не конечными автоматами описывают. Наверное, не без причины. Простые вещи можно сделать как угодно, хоть через колено, хоть через автоматы. Документацию можно сделать больше, чем программа. И т.д. Сложные вещи поднимают проблемы, которую вы так и не решили. Или я что-то так и не понял в статье.
	Сергей 5 Mar 2004 1:32 PM
Если программы пишутся для программирования (самого лучшего в МИРЕ) нужна документация на программу. Если для решения задач, нужна постановка задачи, включая методы верификации результатов (в том числе кода), чему посвящено много книг стандартов и системы поддержки этих процедур. Для крупных проектов изучение RUP или ЕСПД не самое сложное. Свалка документации ничем не лучше свалки программ, а их качество и втом и в другом случае сильно зависит от авторов.
	- 5 Mar 2004 1:34 PM
2Шалыто: Например, написание wisywig текстового процессора совместимого с MS-WORD требует как минимум десять человеко-лет. Напишите такой двумя студентами за два года, вам не только спасибо скажут, но и ваш метод автоматически победит. Потому что это будет прямое доказательство увеличение производительности труда. А пока это абстрактные рассуждения, что не плохо было бы документировать проекты...
	Andy 5 Mar 2004 1:41 PM
2-: " написание wisywig текстового процессора совместимого с MS-WORD требует как минимум десять человеко-лет" да вы оптимист!
	СтранниК 5 Mar 2004 1:48 PM
2Хрю ЗЫ: Юмор ситуации в том что я прям щас торчу в инете оттягивая тот неизбежный момент, когда мне придется начать писать документацию и уже написанному и работающему проекту :) Еще бы пару часиков продержаться а там уже и пьянка за восьмое марта начнется :))) ==== А прикол в том, что когда проект уже готов, а доки еще нет, то ее приемлемой уже и не будет. Потому как с момента кодинга уже все вылетело. А перечитывать свои исходники для написания доки "крутые програмисты" не приучены.
	- 5 Mar 2004 1:49 PM
2Andy: не совсем. На kword в koffice со средней совместимостью примерно столько и потрачено, если не меньше.
	Ron 5 Mar 2004 1:52 PM
>> "И разговоры там не про бабки, а про то полетела ли ракета или нет, и куда полетела." А недавно, помницца, она дважды вообще никуда не полетела. Видать, одной вашей любовью к родине и разговорами её куда надо лететь не заставишь.
	Wintermute - devnul.ru 5 Mar 2004 1:55 PM
Прочитал статью, думаю: "О! Ну, наконец-то!". Залез на сайт, почитал посмотрел, думаю: "У-у-у..." Почитал комментарии, особено ответы автора критика (ну, это, "Родину защищать"), думаю: "Е-е-е!!!" Насмотрелся я, в свое время, когда был "мальчиком", на таких вот деятелей, на продукты их деятельности, на процесс высасывания государственных денег под продолжение этой деятельности... Автору - не буду желать вам успеха в вашем ненужном труде. Читателям - не заморачивайтесь, мужик себе кормушку нашел.
	Хрю 5 Mar 2004 2:06 PM
2СтранниК: "А прикол в том, что когда проект уже готов, а доки еще нет, то ее приемлемой уже и не будет. Потому как с момента кодинга уже все вылетело. А перечитывать свои исходники для написания доки "крутые програмисты" не приучены." Верно. Так чаще всего и бывает. Но мне, похоже, придется-таки писать доку. И достаточно съедобную. Кто бы знал как ломает :)
	Dmitry 5 Mar 2004 2:19 PM
>А прикол в том, что когда проект уже готов, а доки еще нет, то >ее приемлемой уже и не будет. А у Вас есть опыт параллельного написания кода и документации когда сроки поджимают? А поджимают они, как известно, всегда :) Вот только вчера в практически готовом проекте я изменил один из интерфейсов. Это заняло пять минут. Если бы я этот интерфейс предварительно задокументировал - это бы заняло минимум полчаса. И так во всем. Так что написание проектной документации для заказчика после кодирования - это, по моему, единственно здравый метод. Существует и другой - написание документации до кодирования, но это при условии что спецификации не будут изменены (а это уже из области фантастики) :)
	Qrot 5 Mar 2004 2:27 PM
2СтранниК: > А теперь вопрос, при хронически опаздывающих проектах чем в > первую очередь жертвуют? > Как правило документацией. не обязательно. скорее найдут разумный компромис по функциональности. просто при разумном объеме документации - ТЗ, форматы данных, основыне алгоритмы, принципы работы, жертва оной не даст сколько-нибудь заметно выигрыша.
	добрый 5 Mar 2004 2:29 PM
вот и Гатес плачется - нема талантливых мальчиков, Лонгхорн дописывают старики и обкуренные индусы. Куда ж они деваются-то - от Столмена уходят, а до Гатеса почему-то не доходят?
	СтранниК 5 Mar 2004 2:32 PM
2Dmitry Вот сообственно это одна из причин почему марсоходы и теряются,ракеты не долетают. А теперь резонный вопрос. Вы хотели бы жить в доме проектная документация по которому будет выполнена после строительства?
	Хрю 5 Mar 2004 2:50 PM
2СтранниК: "А теперь резонный вопрос. Вы хотели бы жить в доме проектная документация по которому будет выполнена после строительства?" Вопрос _не_резонный. Разницу между строительством и программированием (практическим а не "теоретическим") обкашляли уже не раз. И не раз уже сказано - практическое программирование это искусство компромиса. Не имеет смысла требовать идеала. Идеал элементарно вылетит за рентабельность и проекта не будет вовсе. Никакого - ни с докой ни без. И проги разбегуться без зарплатки. И граница компромиса зависит от прикладухи (сроков, денюшки) - одно дело управление стержнями в атомном реакторе, другое заказами в инет-гамазине.
	Dmitry 5 Mar 2004 2:56 PM
2СтранниК >Вы хотели бы жить в доме проектная документация по которому будет выполнена после строительства? А что тут такого? Например, на даче я живу в доме на который вообще нет никакой проектной документации. И как-то от этого не страдаю :) Все хорошо к месту. Мы живем в конкурентном мире, в котором заказчик, как правило, не готов платить полную стоимость документации, как отдельного продукта интеллектуальной деятельности. Но какую-то документацию он получить зачастую хочет. Вот и получает не более чем какую-то. Я бы сказал еще так - есть внутренняя документация, которая не самоцель, а средство для лучшего понимания и организации процесса разработки, а есть документация, как продукт, который нужно поставить заказчику. И надо понимать, что это далеко не одно и то же.
	Dmitry 5 Mar 2004 3:26 PM
> Разницу между строительством и программированием (практическим а не "теоретическим") обкашляли уже не раз. И не раз уже сказано - практическое программирование это искусство компромиса Не совсем так. Программирование, как и строительство - это инженерная деятельность, которая как раз и есть искусство компромисса. Однако, строительство, во-первых, имеет отношение к безопасности людей, и, соответственно, имеет жесткую законодательную базу, во-вторых, строители все же имеют дело с твердой материей и пространство для маневра у них куда меньше. Поэтому строителям приходится искать компромисс при несколько более жестких ограничениях. Заставьте программистов писать документацию раньше начала кодирования законодательно и они будут ее писать. Только программы будут создаваться дольше, уметь меньше и стоить больше :) Кстати, не надо сравнивать программистов со строительными рабочими, скорее с проектировщиками/архитекторами, у которых проект - это результат работы, как у программиста код. Кстати, большая часть новостроек в Москве начинает строиться, не имея проекта. Более того, часто проект и то что получилось совсем разные вещи. Например, фундамент заложен под девятиэтажный дом, а этажей построили пятнадцать и т.д. и т.п. Однако народ покупает.
	СтранниК 5 Mar 2004 3:34 PM
Qrot 2СтранниК: > А теперь вопрос, при хронически опаздывающих проектах чем в > первую очередь жертвуют? > Как правило документацией. не обязательно. скорее найдут разумный компромис по функциональности. просто при разумном объеме документации - ТЗ, форматы данных, основыне алгоритмы, принципы работы, жертва оной не даст сколько-нибудь заметно выигрыша. === Просто и я и мои знакомые не раз сталкивались с ситуацией , когда продукт готов и запущен поставшиком ( компанией разработавшей софт), а документации на него нет, или есть но не соответствующая действительности ( типа от старой версии). Вот недавно товарищ жаловался на комерческий продукт автоматизации супермаркетов. Это при том что клиентов у этой поставшика уже достаточно много. То есть факты экономии над докой все же имею место быть.
	СтранниК 5 Mar 2004 3:38 PM
2Dmitry Кстати, большая часть новостроек в Москве начинает строиться, не имея проекта. Более того, часто проект и то что получилось совсем разные вещи. Например, фундамент заложен под девятиэтажный дом, а этажей построили пятнадцать и т.д. и т.п. Однако народ покупает. === Ну тогда для Москвы должна быть нормальной ситуация типа "Трансвааля" не так ли? Только мне что-то смеяться не хочется.
	Dmitry 5 Mar 2004 3:51 PM
>Просто и я и мои знакомые не раз сталкивались с ситуацией , когда продукт готов и запущен поставшиком ( компанией разработавшей софт), а документации на него нет, Я не имел в виду руководство пользователя. Это святое :) Я имел в виду проектную документацию, которую ты даешь заказчику, чтобы он мог взять исходники, нанять программистов и развивать продукт, если с тобой или твоей фирмой что-то случится. >Только мне что-то смеяться не хочется Я к чему - если уж строители у нас плюют на проектную документацию, что можно требовать от разработчика бухгалтерской проги, например? Прибыль и доля рынка превыше всего. Пока это так, все будут делать не очень хорошо, зато быстро :)
	Qrot 5 Mar 2004 3:53 PM
СтранниК: > Просто и я и мои знакомые не раз сталкивались с ситуацией... а с чего вы взяли, что документация в этих проектах вообще планировалась? :) сформулируйте кратко тезис который в защищаете в этом споре, а то я уже не знаю против чего/за что вы спорите :)
	СтранниК 5 Mar 2004 4:29 PM
2Qrot Я утверждаю, что: - того состояния с документацией которое сейчас есть в большинстве продуктов явно недостаточно. И не важно это отностится к Oracle или к компаниям по проще - Проблема качества ПО не решена и не решается никак и никто на мой взгляд даже не собирается решать ее на сегодня для программных продуктов. То есть большинство продуктов ( наверно 99%) при выпуске релиза не обеспечивает декларируемого функционала. - Низкое качество ПО не позволяет потребителям ПО хоть как-то стимулировать призводителя ПО на выпуск качественных продуктов. - Производитель ПО не несет никакой ответственности за брак и ничего не делает ( и не заинтересован в исправлении ситуации никак). - Я согласен с утверждением, что документация это не все, "немытье рук перед едой не всегда приводт к заболеванию дезинтреией, однако мы каждый раз моем руки перед обедом". - Отсутствие документации часто связано с плохим проектирование, когда на этапе кодирования приходится менять логику. То есть большинство пишется "с головы вольными художниками". - Дальще проблемы по мере роста проектов будут только нарастать и проблемы с Марсоходом у американцев - один из ярких тому примеров. Так будет продолжаться до тех пор пока число жертв таких подходов не привысит определенный порог. Как пример дорожные знаки на дорогах, часто ставять только тогда, когда случается с десяток аварий с жертвами. Что касается этой статьи, то мне кажется, что у автора есть шанс и именно это меня радует. Покрайне мере подходы которые я нашем в его статьях на это указывают.
	Qrot 5 Mar 2004 4:31 PM
ой мамо. кратко, я же просил :)
	me - userinternet.com 5 Mar 2004 4:37 PM
>> тогда для Москвы должна быть нормальной ситуация типа "Трансвааля" Что Сергей Середа, что автор этой статьи ратуют за то, чтобы программисты писали софт так же, как и промышленники производят свою продукцию. "Если бы строители строили дома..." - не надо обольщаться, они именно так и строят, как программисты пишут программы: за деньги.
	СтранниК 5 Mar 2004 4:43 PM
2Dmitry Я к чему - если уж строители у нас плюют на проектную документацию, что можно требовать от разработчика бухгалтерской проги, например? Прибыль и доля рынка превыше всего. Пока это так, все будут делать не очень хорошо, зато быстро :) === Это потому, что: - с культурой бизнеса у нас тугова-то. - низкая культура потребления, то есть пока большинство устраивает "паленая водка" и недоделанные дома так и будет. Ну и как заключение. Вы же не считаете, что такое всегда будет "прокатывать", рано или поздно за все придется платить. В одном случае деньгами, в другом жизнями людей , в третьем еще чем-нибудь. Многим кажется, что их эта чаша минет. Диспечер кажется Швецарского аэропорта который столкнул грузовой самолет с с самолетом с детьми "Казахских авиалиний", тоже думал так как и вы, однако один отец потерявший всю семью по его вине так не думал. Он доказал авиадиспечеру, что в жизни не все так просто и за все приходтся расплачиваться. Он просто убил авиадиспечера пырнув ножом ранним утром. Как вы думаете какое это теперь имеет знаечение? Или кому от этого стало лучше? А теперь как вы думаете, чем чаще будут падать дома, не будет ли это способствовать появлению таких "отчаявшихся отцов"? Может сверх прибыли не стоят человеческих жизней?
	СтранниК 5 Mar 2004 4:44 PM
2Qrot Ну как умеем так и пишем.
	Дмитрий 5 Mar 2004 4:49 PM
Народ, да нельзя же быть такими закоренелыми пох...стами, блин. Речь уже пошла о том, чтобы вообще забить на проектную документацию к программам, - а в конечном счете и на эффективность и работоспособность этих программ. Зато сколько визга по поводу ошибок в ПО от Майкрософт. Дебилизм полнейший.
	Хрю 5 Mar 2004 4:54 PM
"Он просто убил авиадиспечера пырнув ножом ранним утром. " Коллеги! Нам уже ножами угрожают (ну намекают прозрачненько) :)))
	Дмитрий 5 Mar 2004 4:57 PM
Вот такие же пох..сты выгуливали собак рядом с Трансваалем в день катастрофы, посматривали на полуголых людей, ищущих под завалами своих, и посмеивались. Честное слово, кое-кому в этом треде у меня уже чешутся руки морду набить. Даже не в Трансваале дело, а в том, что МОЖЕТЕ СЕБЕ ПОЗВОЛИТЬ "забить" на такие вещи. Пусть даже и на проектную доку. Отсюда все и начинается.
	Qrot 5 Mar 2004 4:57 PM
СтранниК: в принципе, я ничего не могу/не хочу оспаривать из нижеприведенного. только хочу сказать, все не так плохо как вам кажется, по крайней мере если судить по моему опыту.
	Хрю 5 Mar 2004 5:03 PM
А вот уже и морду бить собрались... "Теоретическое программирование" оказывается страшная сила :)))
	Dmitry 5 Mar 2004 5:04 PM
>Может сверх прибыли не стоят человеческих жизней? С этим сложно спорить. Но к качеству программного обеспечения, тем более к наличию документации это имеет отдаленное отношение. Просто каждый должен думать своей головой и понимать к чему его действие/бездействие может привести. Как здесь уже говорили - здравый смысл прежде всего.
	СтранниК 5 Mar 2004 5:07 PM
2Qrot Если честно, то я рад за вас,потому что у меня такого опыта нет и я не встречал его у других. Да, сейчас можно частично смягчить удары( не платить за коммерческий софт ) заменяя его там где можно опен-сорсными продуктами, но это лишь частичное решение или я бы сказал просто попытка что-то сдвинуть с мертвой точки. Потому как по-большому исходники это не все. Может вы поделитесь своими мыслями, если возможно?
	СтранниК 5 Mar 2004 5:09 PM
2Dmitry ну хоршо, давайте мельче возьмем. Тут недавно кто-то привел пример с оказом кондиционера и блокировкой замков в автомобиле по причине отказа ПО. Я хотел бы знать что есть мера сдравого смысла? Как например вы ее для себя определяете?
	me - userinternet.com 5 Mar 2004 5:11 PM
>> Речь уже пошла о том, чтобы вообще забить на проектную документацию Ошибаешься. Речь идёт о том, что проектная документация - не панацея и не гарантия работоспособности и надёжности. Программисты её пишут, если это действительно необходимо (например, для того, чтобы новые работники не задавли совсем уж глупых вопросов) и есть время (вот сейчас сижу и посматриваю в UML диаграммы, кем-то ранее нарисованные). Уверен, что в Трансваале было столько проектной документации, что её мало кто прочитал всю. Судя по последним новостям (об ошибке _проектирования_), все эти документы только скрывали принципиальные недочёты и откровенную халтуру.
	Дмитрий 5 Mar 2004 5:11 PM
2 Хрю: будешь много хрюкать, дойдет и до практического ;-) У меня опыт более 10 лет в программировании.
	Dmitry 5 Mar 2004 5:15 PM
>Даже не в Трансваале дело, а в том, что МОЖЕТЕ СЕБЕ ПОЗВОЛИТЬ "забить" на такие вещи. Пусть даже и на проектную доку. Отсюда все и начинается. На какие такие вещи мы можем "забить"? Не передергивайте, за это тоже морду бьют.
	Дмитрий 5 Mar 2004 5:22 PM
2 me: да причем тут проектная документация Трансвааль Парка. Халтура - вот о чем речь. Если программеры не пишут проектную или сопроводительную доку к своим программам или хотябы подробные комментарии в тексте, то это халтура. Ну ведь сами же через год разобраться не могут. В своих же прогах. И они же, еще раз повторю, больше всех визжат о багах в МСном ПО. Халтура она и в ПО халтура, и в строительстве. Если из-за халтурного ПО не случается столько неприятностей, как из-за халтурной стройки, то это еще не повод, чтобы халтурить при создании ПО, не так ли? Привычка - великое дело.
	Дмитрий 5 Mar 2004 5:24 PM
2 Dmitry: > На какие такие вещи мы можем "забить"? На качество проектирования программных продуктов.
	Dmitry 5 Mar 2004 5:33 PM
>Тут недавно кто-то привел пример с оказом кондиционера и блокировкой замков в автомобиле по причине отказа ПО. Хорошо. Во-первых, это вроде был тестовый образец (не уверен, правда); во-вторых, Вы никогда не слыхали, сколько автомобилей отзывают производители в год по причине потенциально опасных ошибок в конструкции? Ни разу не слышал, чтобы кто-то отзывал автомобили из-за отказов в ПО. Понимаете, инженерная деятельность не может быть безошибочной, в принципе. Все учесть невозможно. Поэтому, например, в строительстве делают десятикратный запас прочности, потому что если дом обвалится и кто-нибудь погибнет, то отвечать будет строитель. Если хотите, то такой же запас прочности можно заложить и ПО, но стоить оно будет в 10 раз больше. Вопрос: всегда ли это нужно? Для ПО кардиостимулятора - да, для ПО тормозной системы автомобиля - да, для медиаплейера в автомобиле - может быть, для какого-нибудь веб-сайта - вряд ли и так далее. Все ведь упирается в целесообразность.
	Дмитрий 5 Mar 2004 5:35 PM
Может, я действительно передергиваю, просто пофигистское отношение народа к своей работе, к своему быту, к окружающим событиям почему-то достает меня в последние месяцы запредельно...
	Qrot 5 Mar 2004 5:38 PM
СтранниК: я могу рассказать, как мы решаем проблему документации у себя. технологи получают от заказчика вводную, пишут ТЗ, согласовывают его с программистами, потом с заказчиком. в зависимости от количества дурости в голове технолога, возможно до 2-х таких итераций. технолога, который превысил эту цифру, уволили 2 года назад, пока все нормально. параллельно с согласованием ТЗ, программистами разрабатывается внутренния документация - форматы данных, принципиальные алгоритмы (это кстати была наша инициатива а не технологов). все принципиальные алгоритмы должны быть согласованы с технологами - это касается разделения ответственности за ошибку. собственно на этом документация заканчивается, и начинается реализация в коде, на который, кстати, тоже существуют правила кодирования. далее сдача софта технологам, потом сдача софта заказчику. все. лично проверено на 2х крупных проектах, сданных городу, все сейчас успешно эскплуатируются. не могу сказать что все было так уж безоблачно, но - проекты сдавались в срок, поддержка осуществляется в минимальном размере, обучить нового человека не является большой проблемой.
	Qrot 5 Mar 2004 5:46 PM
СтранниК: что интересно, при внедрении такой системы мы столкнулись с нежеланием технологов отвечать за какие либо ошибки софта вообще. получалась интересная ситуация - с одной сторны они вроде бы получают зарплату за разработку, а с другой не имеют к ней никакого отношения :) вот такие они, программисты-теоретики.
	С. Коротких - svkmicex.com 5 Mar 2004 5:47 PM
2Шалыто Не во "вмазать" дело. Просто уже замучили "находчики серебряной пули" из академических либо вузовских кругов. Я не поленился сходить на Ваш сайт и почитать как ваши статьи, так и результаты "проектов". Ну хорошо, понимаю я, что нравится Вам моделирование с помощью конечных автоматов. Но надо же понимать, границы применимости подобного рода моделей. Где-то они очень хороши, в других случаях более адекватными будут другие модели. Гибче надо быть. Почитайте внимательно того же Буча. У него в "Объектно-ориентированном анализе и проектировании" превосходный пример подбора для разных по содержанию задач различных метафор. И еще - Вы когда нибудь участвовали в реализации по-настоящему крупного проекта? Думаю - нет, в противном случае значительно лучше представляли бы себе сложности документирования программных продуктов такого рода, да еще и в условиях высокой динамичности требований к проекту и, как следствие, реализации. В необходимости качественного документирования никто не сомневается, проблема в том, как найти разумный компромисс между качеством документации и затратами на ее создание, да при этом еще обеспечить поддержание ее в актуальном состоянии при разумном уровне затрат ресурсов и сжатых сроках реализации как начального проекта, так и последующих изменений. На эти вопросы Вы ответа не даете. Хорошо жить в башне из слоновой кости:)
	Вlack ibm.* 5 Mar 2004 5:54 PM
2 Странник когда же наконец какой маньяк убюет Билла гейста как главного диспечера. хотя пока от него явныйх жервт нет. ---- вообще то с статьей вообщет то согласен. но елси программытс быдут писать документации ( то эти документации не сильно не будут отличатся от их программ .. вс еравно никто не разберется.). но ввобщето любой ПО проетк начиается с проекат и какая то ДОКА существую хотя бы виде блок схем.( но коненоч не алогритма) а взаимодействия блоков и так далее. без этого не напишишь вобще ничего. потом уже начиантеся детализаций... А вот тут аналогии с стоителстов не катят.. НУ кто при строительстова будет описывать например технология получения арматуры ? хотя это тоже своего рода детализация просто возмут ТИПОВУЮ ( вот в чем фишак строитества) АРМАТУРЫ. подходящую по параматерам( где уже на заводе есть точно описание произовдства ее).. их те же болты в машиностроении.. и болт это еще самоцу мелкое. скажите что и в программирование есть библиотеки? да возжнонэто аналоги типовых конструкций. не зню не видел строительный пректов .. но могу представить.. технолгию- архитектор рисует эскиз.. потом отправляет проектировщику.. то ището что типовое.. исправляте общитывает.. потом созадются чертежы. НО чертежы это и есть ПРОГРАММА для стрителей. потому как чертеж можно сделать так что разобрать будет сложно другому кто не участовал в проекте. НО ТОЛЬКО благодаря детализации.. те это рабочией делат это это это ( чем не копилятор) ВСЕ Это в конце концоы собиратется. те есть самый верхний уровень Архитектор( вот и у программитов есть такое понятие архитектор проекта) потом проектировщик- потом уже созадеть черетежей.( по каждому оъекту те один одно делай другой другое-) и уроветяь исполнителей.... то что прозазумечает под документаций в стаьею есть самы верхний уровень искиза проекта... НО НИКА НЕ ЧЕРТЕЖ... ЧЕРТЕЖ ЭТО ПРОГРАММА.. просто исполнитель компилятор а не человек. хотя не спою о необходимость сопроводительно документации.(кторая в машиностроиее тоже пристуствует отдель от чертежа --
	Dmitry 5 Mar 2004 5:57 PM
>> На какие такие вещи мы можем "забить"? > На качество проектирования программных продуктов. Я как раз говорил обратное. Документация - не самоцель и является полезной, только если позволяет улучшить процесс разработки программного обеспечения. Лучше, в условиях ограниченных ресурсов, написать хорошую программу, чем плохую документацию + плохую программу. Лучшая документация к коду - сам код. Документация должна быть разумной и содержать вещи, которые невозможно понять из кода - архитектурные решения, рассмотренные варианты, может быть краткое описание базовых классов, неочевидные трудности реализации. Все. Сам код должен быть написан так, чтобы все остальное можно было бы легко подчерпнуть из него. Более того, если вероятность ухода разработчика за время пока программа используется помноженная на вероятную стоимость найма ему замены и ввода в курс дела меньше стоимости написания документации, то внутреннюю документацию можно вообще не писать. Если законом или контрактом определено, что писать документацию нужно - то писать ее нужно, но как отдельный продукт и такую документацию нельзя путать с внутренней документацией.
	svart 5 Mar 2004 5:58 PM
открытая проектная документация :)) - попытка объять необъятное, и, по-моему, на-халяву получать технологии
	Владимир Габриель - gabrieldigdes.com 5 Mar 2004 6:01 PM
Анатолий, видимо Вы не поняли моего предложения, в силу моей краткости. Повторюсь. Я руковожу проектом по созданию коммерческого продукта, про который можно прочесть и получить исполняемый код на www.docsvision.com Я готов потратить время/силы, на то, чтобы сделать этот продукт, продуктом не только с открытым кодом, но и с открытым процессом разработки = проектной документацией. Однако, естественно, чтобы это было осмысленно и полезно/познавательно, этим необходимо заниматься регулярно, у меня нет сейчас сил для поддержки такого ресурса в интернете. Не хотите ли вы подключить своих студентов к такому проекту? Тогда уже никто не сможет обвинить Вас в оторванности от жизни и излишнем академизме, т.к. опубликована будет не документация к программе hello world, а реальный проект, который продается на рынке, у которого есть пользователи и т.д. Надеюсь смысл предложения теперь более понятен. Спасибо,
	Вlack ibm.* 5 Mar 2004 6:04 PM
пардон за ошибки. вообщето необходиомть язяка пргграммиирорван для документаци действительно нужна. ведь не на русском/английсок языке писать.. прошу прощения за ошибки :). ведь это еще не понятнее чем на C будет. соори за свой бред /5 копеей в такой сероьзном обсуждении.
	Вlack ibm.* 5 Mar 2004 6:10 PM
ладно вы все про программы. а представте кака дкупентации для разработчиков пентиумов? вообще сейчас созание микросхем сродни написанию программ.. ДА ДА приницпиальны схемы только кто в них разберется.. и поможет ли документация? я к тому что документации должна дополнять сиходники/чертежы/принипиальные схемы. но не перекрывать их. исходя из стаьй мысль была что программу должно -можно написать по документации.. елси такие требования к документации то такую доку ТЕМ более никто не поймет. хотя в приницпе можно было написать. только разбирать будет в ней гораздно сложне чем просто исходнике. другое дело что не все по исходнику понятно.. на это и есть комментарии.. а одтельная дока это что казсатся общей архитектуры описнаие структур и полей и так делее.. это действителньо на этапе проектировки прорамы делается. НО ЭТО НИКАК НЕ ЗАМЕНИТ саму программу
	me - userinternet.com 5 Mar 2004 6:39 PM
>> да причем тут проектная документация Трансвааль Парка. Не знаю. Ты, вроде, сам приплёл сие заведение. >> Если программеры не пишут ... хотябы подробные комментарии в тексте, то это халтура. Но я-то пишу. И много кто пишет (сам видел). На ведьм охотимся? >> Ну ведь сами же через год разобраться не могут. Как я уже говорил чуть раньше: почитав готовую документацию от автора этой статьи я мало чего понял сверх того, что было написано в коде (только граф состояний мне и пояснил кое-что, а остальное - сочинение второклассника). >> И они же, еще раз повторю, больше всех визжат о багах в МСном ПО. Найди-ка среди своих оппонентов тех, кто визжит... >> Халтура она и в ПО халтура, и в строительстве. Золотые слова. Но вот подробнейшая документация не ликвидирует халтуру. Почему-то :)).
	xacid 5 Mar 2004 6:39 PM
2Qrot коммерческие проекты в подавляющем своем большинстве - это не проекты вообще... а просто ПОПСА. попса - это то что сделано исключительно ради денег и без всякой идеи. то есть вместо содержания там ЖАДНОСТЬ. а форма... а вместо формы - мимикрия....
	Вlack ibm.* 5 Mar 2004 6:44 PM
2 xacid ну ну в условиях не коммунизма все делается ДЛЯ ДЕНЕГ. даже исходники открываются. хотя конечно нужно оделять жадность. те деньги как само цель. ну тогда вообще не будут писать комментарии... МНЕ ЭТО как программситу не выгодно. :).
	Вlack ibm.* 5 Mar 2004 6:57 PM
и еще >>>а остальное - сочинение второклассника)>>> вот то то и оно... что это дока для вида .. а почему. да потому что НЕт в принипе какого нибут стандарта на докуменцаии ПО.. и если он будет то скорее он бдует больше похож на какой нибуть язык программирования. кто будет опредялеть насколько качетсвенная документация? можно вообще такую лабуду написать.. и какой тогда в ней смылс? а можно написать просто хороший комментраия в программе.. и никая документация не нужна.( а так чаще всего и происходит при нормальной разрботке).. другое дело что при сроках какието изрващеных именениях программеры и комеенты не удосуживаются делать. но что поделаешь.-> но доку заставить напсиать еще сложнее.. и бесполезнее. хотя опять же скажу. полность согласен о необходимости обще проектых эскизов блох схем построения всего проекта..( без этого ни один проект не делается) и если эти вещи теряются востановить это своего рода реверс инженеринг делать.. и это уже будет невозможно без привлечения самих разработчиков. НО документировать каждую функцию это маразм. да как себе и представлю описать функици init - инициальзирует перменный a,b,c в значение 0. и так делее.. зачем? и по названию функции ясно.. тут даже коментарий будет лишним. зато описать где эти переменны использоыет будет логичее. опять бред написал.
	xacid 5 Mar 2004 7:28 PM
2Шалыто Анатолий, не обращайте внимание на местных "шакалов" и не ждите от них какого либо "признания" или даже хотя бы просто конструктивной критики или дискуссии... от голодных ждать хоть капли разума просто бессмысленно, у них другие проблемы - как бы поэффективнее "оттереть" "конкурентов" от "кормила"... насчет Вашего подхода - он верен, но помоему не достаточен мало открыть проектную документацию - в этом смысле она ничем не лучше просто исходных текстов. проблемы более менее теже самые остаются и никуда не деваются. мне кажется тут требуется что то более радикальное. а именно - общепризнанные базовый открытый инструмент проектирования и обмена проектной информацией и мета-информацией (например паттернами).... имхо пока такой инструмент в каком то виде не будет создан проблемы останутся и решать их можно будет только методом "грубой силы", чем в данный момент и занимается большинство тех кто хоть чем нибудь еще занимается в действительности, а не создает видимость работы под видом клепания тонн "работающего" кода...
	Dmitry 5 Mar 2004 7:40 PM
Хм. Попса, шакалы - уровень не выше начальной школы. Анатолий, Вы с такими "талантливыми" мальчиками много дел наделаете. Желаю удачи. Все.
	Yuri 5 Mar 2004 7:40 PM
2"Проходящий мимо": > 4) На продажу ПО AS IS должен быть наложен (IMHO) > законодательный запрет. Т.е. либо за деньги - с > документированием, либо AS IS но только бесплатно. Ну, и будут в этой документации писать всякую не относящуюся к делу чушь, создавая что-нибудь типа "Инструкции по эксплуатации изделия 'ручка для швабры деревянная'" на 5 листах или той "документации" в виде набора из сотни скриншотов экранов, которые нередко и сейчас можно увидеть. Это что, кому-то реально надо?
	Вlack ibm.* 5 Mar 2004 7:57 PM
а вообще нужно писать ПО так что бы без хелпа можно было ей пользоваться и писать исходники с такими коментариями что бы документация не понадобилась.
	Yuri 5 Mar 2004 9:00 PM
2Хрю: > Часто ею пожертвовать невозможно (Денюшку презренную не > заплотют, волки). Тогда документация превращается в отмазку > :(. И не мы такие, а жизнь такая. Ага. Несколько лет назад сдавали большой проект зарубежной фирме. Для создания документации затребованной формы пришлось написать програмку, которая попросту прошлась по всем исходникам и автоматически сгенерировала несколько тысяч страниц доки. Основная проблема потом состояла в том, что все это пришлось распечатать, и на каждой странице должна была еще стоять подпись, а на некоторых и не одна :-( И для доставки всего этого хозяйства пришлось потом арендовать еще специальный микроавтобус :-O. Но зато документация была полной. Правда, ее потом никто никогда не прочтет, но это уже и не важно :-)
	Yuri 5 Mar 2004 9:05 PM
2Andy: > " написание wisywig текстового процессора совместимого с MS- > WORD требует как минимум десять человеко-лет" > да вы оптимист! Ну, если требуется только совместимость, то можно уложиться и в гораздо меньший ресурс. Вот ежели нужна полная поддержка той же функциональности - тогда да, все становится уже гораздо сложнее.
	Yuri 5 Mar 2004 9:14 PM
> А прикол в том, что когда проект уже готов, а доки еще нет, > то ее приемлемой уже и не будет. > Потому как с момента кодинга уже все вылетело. > А перечитывать свои исходники для написания доки "крутые > програмисты" не приучены. Это не страшно. Зато будет вполне осознанное наконец программистом описание того, как по его мнению программа в конце концов должна была бы работать :-). Которая может послужить неплохой стартовой площадкой для создания следующей версии :-)
	Шалыто -> Dmitry 5 Mar 2004 9:47 PM
Неужели у Вас язык поднимается так говорить о людях? Один из моих мальчиков летит сейчас в самолете на двухдневное интервью "к Биллу Гейтсу", пройдя три телефонных интервью, на двух из которых ему по-английски говорили: "Диктуй код". Так что, если у Вас есть какое-либо мнение, оставьте его при себе. И еще. Проектную документацию действительно, видимо, не нужно делать, т.к. мой опыт показывает, что никто не умеет логически мыслить в этом направлении. Хорошую документацию написать очень трудно и это отнимает много сил и времени. Вот все и выкручиваются, что не надо и находят разные причины. А причина в одном - в отсутствии культуры письма, речи и т.д. Даже мои хорошие мальчики никогда в филармонии не были, что уже говорить о плохих. А сходили бы раз на симфонию Чайковского, которую исполняют великолепные музыканты, получающие три тысячи рублей (!) в месяц, многое бы поняли, что такое хорошо, а что такое плохо. И т а к о й дискуссии по поводу документации, наверное, бы не было.
	Max K.>Шалыто - maxim.korotkovmobile-review.com 5 Mar 2004 10:52 PM
--- Даже мои хорошие мальчики никогда в филармонии не были --- Прям уж так все и не были? Я был.
	Max K.->Black ibm - maxim.korotkovmobile-review.com 5 Mar 2004 10:52 PM
--- а вообще нужно писать ПО так что бы без хелпа можно было ей пользоваться и писать исходники с такими коментариями что бы документация не понадобилась. --- а если в программе реализован алгоритм (ну хоть какой-нибудь) то мы запишем ОБОСНОВАНИЕ применения этого алгоритма (с диаграммами, графиками и пр.) в комментарии? Может лучше наоборот все вынести наружу? а комментарии по минимуму. А раговор о том, что нужно объяснять не толко как программа работает, но и почему выбрано такое решение.
	Max K.->xacid - maxim.korotkovmobile-review.com 5 Mar 2004 10:53 PM
--- попса - это то что сделано исключительно ради денег и без всякой идеи. то есть вместо содержания там ЖАДНОСТЬ. а форма... а вместо формы - мимикрия.... --- Большинство некоммерчских сделано для себя. Документация в некоммерчских продуктах хуже еще на порядок (если сравнивать бесконечно малые). В некоммерческих продуктах она написана программистами для программистов. Если кто сомневается могу прицитировать кусок ДОКУМЕНТАЦИИ к одному из пакетов ТеХ. "Если по каким-либо причинам это не работает, попробуйте пересобрать документ еще раз-другой"
	Max K. -> С. Коротких - maxim.korotkovmobile-review.com 5 Mar 2004 11:06 PM
--- В необходимости качественного документирования никто не сомневается, проблема в том, как найти разумный компромисс между качеством документации и затратами на ее создание, да при этом еще обеспечить поддержание ее в актуальном состоянии при разумном уровне затрат ресурсов и сжатых сроках реализации как начального проекта, так и последующих изменений. --- Рекомендую поставить эксперимент. Просто документировать часть большого проекта. Понятно, что не везде удается написать сначала документацию, а потом программу (заказчик не хочет чиать доку, он хочет кнопочки пощелкать). Но никто не мешает документировать, например eXtreme Programming проект. Просто документация тоже будет "экстремальная". Наличие структурированного описания проекта поможет корректно вносиь в него изменения (особенно другими людьми через продолжительный отрезок времени). Про хороший код. Пру месяцев назад получив на модификацию код проекта от заказчика я понял следующее, программа написана хорошо. Я понимаю что она делает (когда смотрю на экран кода), но я не понимаю ЗАЧЕМ.
	me - userinternet.com 6 Mar 2004 1:53 AM
>> я не понимаю ЗАЧЕМ Нормальные люди не забивают себе голову такими вопросами. Так можно и до поисков смысла жизни докатиться.
	glassy 6 Mar 2004 7:12 AM
Признаться честно, мне не нравится словосочетание "хорошие мальчики", либо это не то, что рассказывают по Евроньюс, либо автор действительно очень давно не смотрел новости. Имхо г-ну Шалыто не дают покоя лавры БГ, хочется стать тоже немножко великим архитектором ПО. А кодеров -- поувольнять, кодирование будет автоматическим (я ведь верно мыслю?) Издержки уменьшаются, багов нет, патчей нет, сиди рисуй диаграммки... 2Max K.: помнится у нас был предмет "Метрология ПО", и там в качестве одной лабораторной надо было в графе расписать какую-нибудь свою курсовую, подсчитать число циклов, ветвлений, состояний. Если бы ты попробовал сделать что-нибудь подобное, то искренне посоветовал бы взять не курсовую, а лабораторную работу напаскале с первого курса, а для рисования графа воспользоваться Автокадом, ибо только в нем можно примерно ровно разместить 150 маленьких кружочков с номерками. "но я не понимаю ЗАЧЕМ." Документацию писать, говоришь? Правильно! Подучить пунктуацию, и писать. Хорошо, хоть в филармонии был. Я тоже был. Недавно. Там еще были мамы с грудными и дошкольного возраста детьми. Ты ведь не мама? предлагаю фигней не страдать, читать /usr/src/linux/Documentation/CodingStyle до просветления.
	AT 6 Mar 2004 9:44 AM
Хе-хе ... Спор ни о чем .... Скачал "Документацию" для Lines - 28 страниц из 30 оказалось текстом самой программы, и еще 3 или 4 страницы примером протокола отладки :o) С такой "документацией" далько можно уйти... Сам вопрос о стандартах и необходимости документции очень легко решаеться на уровне любой фирмы. Первый - самый важный вопрос - что необходимо документировать ?? Надо ли документировать циклы, функции или операторы которые есть в программе или надо задокументировать те требования, информацию или решения принятые заказчиком, на совещаниях или между разными программистами ?? Как по мне так второе гораздо важнее. Результатом хорошей работы должна быть программа которая удолетворяет заказчика, или по крайней мере такая которая работает как заказчик изначально захотел. Мало какой заказчик будет читать TechHelp с описанием всех внутренних функций внутри программы, от силы будет необходима документацию внешних интерфесов - как программных так и окошек... Более подробная документация остаеться на вкус разработков или директора их фирмы. Если будет издан указ по фирме - всем писать документацию в исходниках, MS Word, Rational или еще чем-небуть - то каждый кто не захочет должен будет пояснять почему, чаще проще бывает в таком случае сделать как требуют. На счет OpenSource проэктов - вроде как в уперк ставиться что нету мол документации к OS проэктам, вроде как мы одни такие хорошие .... Берем лучший проэкт февраля месяца с SourceForge - Compiere ERP + CRM Business Solution (http://www.compiere.org/), документация есть - и стоит денег чтобы ее получить .. Многие другие OS проэкты просто не требуют внутренней документации - т.к. самих программистов в них раз два и обчеслся ... Если говорить что на самом деле необходимо - почему никто не думает о такой простой вещи как тесты для программ ?? Почему опять же в тех же OS проэктах нету автоматических тестов ? Аа ... забыл - пользователи как те же обезьянки сами проверят все когда очередная Beta версия выйдет. Вот эти же обезьянки и готовы читать исходники если надо что-то подправить ... В случае если же руководтсво какой-то фирмы решит что и тесты важны, оплатит работу соответсвующих программистов - то ничего не мешает их существованию. Все дело в пользовательской и прораммесрской документации, тестах, исходниках - в целесообразности. Принятие любых стандартов - например программы только с исходниками, ограничивает свободу, а не предоставляет ее ...
	AT 6 Mar 2004 9:46 AM
С точки зрения обучения - вообще-то хорошо что студенты учаться не только код писать. В будущем _возможно_ пригодиться.... P.S> Со-о-ррии - не так все плохо ... Не 28 страниц из 30, а всего 18 ..
	Хрю 6 Mar 2004 3:28 PM
Вот так дискутирует профессор, доктор наук Шалыто: "...мой опыт показывает, что никто не умеет логически мыслить..." "А причина в одном - в отсутствии культуры письма, речи и т.д." "Так что, если у Вас есть какое-либо мнение, оставьте его при себе." А вот прикол каких мало: "А сходили бы раз на симфонию Чайковского, которую исполняют великолепные музыканты, получающие три тысячи рублей (!) в месяц, многое бы поняли..." Чего ж удивляться что некоторые "защитники документирования" порою бьются в истерике и бросаются на окружающих с кулачками за святое дело.... Дискусии действительно не получилось :(
	Wintermute - devnul.ru 6 Mar 2004 7:37 PM
2 Хрю: Я же говорил - забейте на тему. Мужик обеспечил себя работой за счет налогоплательщиков (расшифровываю - наш с вами) на долгие годы. Таких "деятелей" в системе Академии Наук очень много, чересчур много. Поделать с этим ничего нельзя, это система.
	VOVIX 7 Mar 2004 12:34 AM
При наличии качественной проектной документации программист не сможет «управлять» менеджерами. После его увольнения на продолжение проекта можно нанять человека с более низкой квалификацией и зарплатой, а не с более высокой, как это обычно бывает. В конечном счете, в цивилизованной стране средний программист не должен получать больше среднего школьного учителя. Таким образом, это открытый заговор против программистов. К счастью, мы люди пока еще достаточно свободные, чтобы избегать организаций с таким подходом к нашей деятельности. Конечно, проектированию есть место - но только в консервативных проектах, в которых аппаратная часть намного дороже программной и высок риск аварии. Т.е. в управлении ядерными, химическими, медицинскими объектами. К счастью, есть множество отраслей, где консерватизм вреден. И их число только увеличивается. Так что все спокойно. Вообще, тенденция такова, что количество кода все более возрастает. Следовательно, его нужно реиспользовать. А смысл ООП в том, что использующий объект не обязан знать его внутреннюю реализацию. Таким образом, тотальное документирование - попросту нереально. Это как писать Word на ассемблере. И затрат труда оно возьмет столько, что никто на такое не пойдет. Уже лучше шароварщиком за пару регистраций в месяц сидеть, чем под таким колпаком...
	VOVIX 7 Mar 2004 12:35 AM
да, и еще, если программер получает намного больше учителя - значит надо повысить з.п. учителям, а не искать крайних.
	flocken - flockenmail.ru 7 Mar 2004 3:38 AM
2Шалыто: >>5 марта, 2004, 21:47 - Шалыто -> Dmitry >>Неужели у Вас язык поднимается так говорить о людях? Один из >>моих мальчиков летит сейчас в самолете на двухдневное >>интервью "к Биллу Гейтсу", пройдя три телефонных интервью, на >>двух из которых ему по-английски говорили: "Диктуй код". а) Билл Гейтс не будет тратить два своих дня на интервью с потенциальным сотрудником, для этого у него есть высокооплачиваемые менеджеры по персоналу. б) Вряд ли приглашение на это интервью было спровоцировано «умением писать проектную документацию», скорее – умением находить оптимальные алгоритмы и корректно воплощать их в коде. В противном случае талантливому мальчику говорили бы по-английски : «Диктуй проектную документацию». Это были просто риторические замечания. А по существу вопроса хотелось бы заметить следующее. Если ваша основная цель – «педагогическими приемами» развить участников движения, и создать «музей» проектной документации – честь вам и хвала. Но заявления общего характера типа «проектная документация… должна быть открытой» - это претензия на универсальность ваших рекомендаций, каковые в современном мире даже близко не являются универсальными. А в случае, если такие рекомендации, не дай бог, силовыми методами будут введены в качестве «обязательных» - то вреда от них будет на порядок больше, чем пользы. Упрощая, можно сказать, что попытки составлять «великолепную проектную документацию» в большинстве программных проектов, которые сегодня осуществляются, привели бы к их провалу. Вследствие перерасхода выделяемых на проект ресурсов. Это может быть не критично для (в лучшем случае 10% от общего числа) «образовательных», «показательных», или «жизненно критических» проектов. Но в подавляющем большинстве случаев заказчик, как человек разумный и реально смотрящий на вещи, не захочет платить лишние 20-50% стоимости проекта за «великолепную документацию». Заказчику прежде всего нужен работающий продукт, затраты на который сопоставимы (но при этом всегда меньше!) с эффективностью его использования. У военных есть термин – «сверхуничножение». Это когда на маленькую деревушку сбрасывают 2 (!) атомные бомбы. Конечно, в данном случае, я утрирую, но, тем не менее, это намек в нужном направлении. То же самое говорит и один из мудрецов древности: «Хорошо обрабатывать землю НЕОБХОДИМО, а превосходно обрабатывать землю УБЫТОЧНО». Поэтому позволю себе совет практика теоретику. Не предлагайте своих услуг для создания коммерческих проектов – тогда у вашего потенциального заказчика будет гораздо меньше шансов разориться. И, будьте честным – назовите свое движение адекватно имманентно присущим ему ограничениям - «Движение за открытую документацию В НЕКОММЕРЧЕСКИХ ПРОДУКТАХ». С уважением, Коммерческий программист. P.S.: Dmitry – respect.
	AT - 220220pager.icq.com 7 Mar 2004 10:36 AM
2Шалыто: На счет диктуй код - вы же вроде как опытный человек. Код просили продиктовать наверняка для какой-то простой задачки типа сложить два чилса или найти среднее арифметическое.. Вся суть такого вопроса - не в самом коде который человек продиктует, а во всех крайних ситуациях которые он продумал в своей голове. Вроде как переполнения при суммировании или делении на ноль .... Тут на самом деле не код - а то как человек продумал все более важно ... Надеюсь что не открыл новую истину и это было известно всем до этого ....
	o 7 Mar 2004 10:08 PM
2 flocken: к "Биллу Гейтсу" - Анатолий Шалыто имел в виду компанию Майкрософт. 2 Wintermute: > Мужик обеспечил себя работой за счет налогоплательщиков (расшифровываю - наш с вами) на долгие годы. Таких "деятелей" в системе Академии Наук очень много, чересчур много К сожалению,совсем немного. Таких мужиков, учеников которых пригдашают в Майкрософт на личное собеседование. 2 Хрю: > А вот прикол каких мало: "А сходили бы раз на симфонию Чайковского, которую исполняют великолепные музыканты, получающие три тысячи рублей (!) в месяц, многое бы поняли" Это не прикол, тупица. Если симфонию Чайковского исполняют великолепные музыканты, получающие три тысячи рублей в месяц, то это говорит о том, что для них качество работы и исполнения музыкальных произведений превыше всего. Даже превыше мизерной зарплаты в 100 долбаных у.е. Надо бы у них поучиться. 2 all: хватит поливать грязью Анатолия Шалыто, тем более что он этого абсолютно не заслуживает. Скорее наоборот, если не дотягиваете до уровня вопросов, о которых говорит Анатолий, то нужно больше работать над собой.
	Хрю 7 Mar 2004 10:46 PM
Ой! Я думал здесь все уже потухло. Ан нет: o: "Это не прикол, тупица. Если симфонию Чайковского исполняют великолепные музыканты, получающие три тысячи рублей в месяц, то это говорит о том, что..." Еще раз хорошо отсмеялся. Ну что-ж, давайте продолжим. Предлагаю обсудить как зазвучал бы, скажем, Рахманинов если его исполнять по четыре с половиною тысячи рублей в месяц. Или Моцарт по две с полтиной штуки :)
	Дмитрий 7 Mar 2004 10:54 PM
2 Wintermute: > Мужик обеспечил себя работой за счет налогоплательщиков (расшифровываю - наш с вами) на долгие годы. Таких "деятелей" в системе Академии Наук очень много, чересчур много За такие слова нужно отвечать, и отвечать серьезно.
	VOVIX 9 Mar 2004 3:33 AM
Идея статьи была о том, чтобы в открытый код вставляли побольше комментариев, документировали его. И ни в коем случае - не о замене открытого кода на тотальную документацию. Хороший код сам себя документирует. Если кому-то и этого недостаточно, значит, проблема в тупости и бесполезности кода, который он пишет. Т.е. создает кучу наворотов типа абстрактных классов Custom*, интерфейсов *Dispatch или свойств Right/Bottom в простейших программках вроде ноутпада, по всем рекомендациям M$ и в результате использовать поставляемый таким "кодером" код все труднее и труднее. О размере скомпилированного кода я просто умолчу.
	Wintermute - devnul.ru 9 Mar 2004 9:25 AM
2 Дмитрий, o: Я работал в системе РАН, был "мальчиком". Тему дальше развивать не буду, поскольку тогда мне придется назвать имена и фамилии конкретных людей, на что у меня нет права.
	Шалыто - Qrot 9 Mar 2004 9:54 AM
Проектов-то может быть и нет, но даже их почему-то никто раньше, чем с третьего раза сделать не может, и это при том что все работают программистами. Ни в одной книге даже таких проектов нет! А учить-то нрод надо - так что делали проекты и делать будем! Через год студенты уже говорят спасибо. И Вы бы сказали...
	Шалыто - Страннику 9 Mar 2004 9:58 AM
Теории автоматического управления более 150 лет и там многое устоялось. Программирование в три раза моложе - поэтому все ошибки молодости, которые я стремлюсь преодолеть.
	Шалыто - Qrot 9 Mar 2004 10:03 AM
Неужели через 10-15 лет при необходимости внести изменениz в программу Вас будет интересовать сдали Вы ее вовремя или на месяц позже. Но Вам ,конечно, не интересно, что будет через столько лет. Почитайте статью на моем сайте "Об автоматизации "стиральных" машин".
	Qrot 9 Mar 2004 10:07 AM
Шалыто: ну так вы определитесь, вы "мальчиков" учите или народу новую методу разработки и сопровождения предлагаете. а то в статье заявлено про всеобщее щастье, а на деле все только вокруг обучения студентов крутится и все больше похоже, что назвать статью стоило бы "новая инициатива в преподавании программирования"... с соответсвующим изменением содержимого.
	Шалыто - Хрю 9 Mar 2004 10:09 AM
Да как же можно документировать сложные проекты, когда никто не может внятно документировать даже учебные! Причем здесь мурзилка?
	Qrot 9 Mar 2004 10:11 AM
Шалыто: > Неужели через 10-15 лет при необходимости внести изменениz в > программу Вас будет интересовать сдали Вы ее вовремя или на > месяц позже я не пойму, вы предлагаете моей семье голодать, пока я буду документацию расписывать?
	Шалыто - Qrot 9 Mar 2004 10:12 AM
А Вы думаете, что если это получится только в преподавании это мало? Мне хватит! Когда эти ребята помудреют (умные они уже сейчас) мы может быть сделаем технологию, в сложных проектах.
	Шалыто 9 Mar 2004 10:20 AM
Язык verilog применяют при аппаратной реализации программируемых матриц, уже там автоматы как язык спецификаций применяются лет 50. Почитайте документацию на эти матрицы. Так что я хочу что программы проектировались как схемы. Вирт сейчас предлагает как методы программирования применять к схемам, а наоборот!
	Шалыто -Qrot 9 Mar 2004 10:25 AM
Я предлагаю не голодать, а прочитать мою статью о стиральных машинах! А то, что ПВО США работает само по себе, так как нет ни тех людей, ни документации Вас не смущает? И Вы думаете такая ситуация только у ПВО США? Я знаю о примерах поближе!
	Шалыто -Ron 9 Mar 2004 10:31 AM
Нет еще нужны методы проектирования программ. Почитайте справа Гейтса - наконец, он об этом заговорил. А будет проектирование, будет и документирование, и следующие ракеты полетят правильно даже через 10 лет после завершения проекта.
	Шалыто - Wintermute 9 Mar 2004 10:35 AM
Про кормушку это неплохо! Приходите, поделюсь. Только думаю Вас сумма не устроит - три тысячи рублей на двоих!
	Шалыто - Хрю 9 Mar 2004 10:42 AM
А в автоматизированном доме как будет? Дом будет построен по проекту, а все программы автоматизции в нем будут написаны кок-как? Пока, видимо, так, но скоро они будут проектироваться одинаково!
	Шалыто - Dmitry 9 Mar 2004 10:45 AM
Если дом зимний, то я Вам не завидую, когда что-нибудь будет с проводкой или зашитыми трубами!
	Шалыто - Dmitry 9 Mar 2004 10:53 AM
Качество строительства в последние годы не требуют комментариев! То что происходит, к сожалению, не конец, а начало! В все из-за качества проектирования и документирования. И так будет везде, где будет применяться вычислительная техника для управления, если управляющие программы не начнут проектировать по-человечески!
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 10:55 AM
"Бей профессоров - они гадюки!" А я вот подумал: "А зачем вообще учиться?" Могу яму копать, могу не копать. Таблицу умножения знаешь - доллАры посчитаешь. Правда, с таким подходом нужно срочно учиться делать каменные топоры и наконечники для стрел. Только вот проблема: гориллы уж больно здоровые - непросто будет их из джунглей выгнать и их место занять... С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Шалыто - Кортких 9 Mar 2004 11:08 AM
Тридцать лет занимаюсь автоматизацией ответстветнных объектов! На аппаратуру выпускаем море качественной документации и поэтому и через 15 лет по ней можно вести изготовление с небольшой корректировкой по комплектующим! С программами еще такой культуры нет! Но будет! На ответственные проекты будет выпускаться море качественной проектной документации. И не понятно о чем здесь спорить! Дело времени и только!
	Qrot 9 Mar 2004 11:12 AM
> А Вы думаете, что если это получится только в преподавании это > мало? Мне хватит! вот и занимайтесь проподаванием. и пока не опробуете свою теорию в жизни - вам, кстати, уже предложили где - даже и не пытайтесь рассказывать про всеобщее щастье.
	Wintermute - devnul.ru 9 Mar 2004 11:21 AM
2 Шалыто: "Только думаю Вас сумма не устроит - три тысячи рублей на двоих!" Это да, это, конечно, сильно сказано. Это, само собой, аргумент в две тонны. Это проходит, особенно на митингах. Так и видишь гнусного Wintermute с бегающими глазами и волосатыми пальцами, за пригоршню долларов продавшего Идеалы. И, что самое интересное, Вы сказали правду, начсет трех тысяч на двоих. Мальчиков.
	Шалыто - flocken 9 Mar 2004 11:26 AM
Никому не предлагаю делать коммерческие проекты для безответственных систем. А для ответственных систем все равно так будет - рано или поздно!
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 12:01 PM
2 Шалыто: Вы совершенно верно упомянули строительство. Там, если использовать нынешний "программёрский" подход, то получится не дом, а братская могила. Не сразу, так через месяц-год. Но совершенно неотвратимо и объективно. Примерно так же дело обстоит в вопросах автоматизации (ГАП и АСУ ТП, etc.) Но совсем иное дело - кустарное программирование. Здесь совершенно смело можно спроектировать базу левой ногой, а реализовать ПО - правой. Заказчик, как правило, в этом ничего не смыслит, технадзора с его стороны нет, приёмки - тоже. Да и самой большой бедой здесь будет падение програмы и потеря одного-двух рабочих дней, что нынче широко принято объяснять Заказчику "появлением нового вируса", который, дескать, и виноват в сбое, а совсем не безграмотность "творческой личности", сляпавшей программу на коленке за ночь. Разумеется, люди, привыкшие зашибать деньгу в условиях подобного бардака, никогда не примут Ваших доводов. И они субъективно правы. Другой вопрос, что они не правы объективно. Но, как правило, доводы желудка всегда сильнее доводов мозга... :-( А вообще, вопрос упирается в наведение общего порядка (экономика, налоги, наука, искусство, технологии и т.п.) И нежелание этого порядка, так же закономерно. С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Хрю 9 Mar 2004 12:17 PM
2Сергей Середа: "Бей профессоров - они гадюки!" Насколько мне известно в медицине, например, существует принцип - если ты профессор или даже академик там какой, ты тем не менее должен практиковать как врач - т.е. вети больных, делать операции и т.п. Причем с применением методик, которым ты учишь своих студнтов. Иначе доверие к твоему учению... несколько снижается. Вот бы такой принцип и в преподавании программирования ввести. А то безусловно талантливые мальчики, не оперировавшие ничего кроме лягушек со скальпелями на живих людей лезут... энтузиасты, блин... Вот прям щас наблюдаю как вполне неглупые ребята зарезали проект РУПами джавами да ЮМЛями...
	Andy 9 Mar 2004 12:19 PM
2Сергей Середа: Браво! Всё должно быть подстрижено, побрито, посыпано песком и покрашено зелёной краской.
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 12:33 PM
2 Andy: === 2Сергей Середа: Браво! Всё должно быть подстрижено, побрито, посыпано песком и покрашено зелёной краской. === А каковы будут Ваши предложения? Сидеть в ..., ну в том, в чём сидим и в ладоши хлопать? С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Хрю 9 Mar 2004 12:35 PM
2Сергей Середа: "Разумеется, люди, привыкшие зашибать деньгу в условиях подобного бардака, никогда не примут Ваших доводов. " Ваше отношение к практикующим программистам вполне в традиции "теоретического программирования". И оно взаимно. Прикладные программисты очень не любят и откровенно опасаются "теоретиков" за их способность подкидывать идейки вроде патентования софта. Мы-то прекрасно понимаем возможные катострофические последствия, т.к. знаем из чего булки делаются. А вот "теоретик" понять не способен. Да и не утруждается. Ему надо на диссертацию насобирать, а там хоть трава не расти. А нам здесь жить и после того как он диссертацию напишет.
	AT - 220220pager.icq.com 9 Mar 2004 12:45 PM
Опять надеюсь что не открою истину, а скажу то что всем известно. Процесс разработки ПО для систем в которых важно чтобы оно работало 100%, а не 99 и сколько-то там девяток уже есть и достаточно давно применяеться. Возьмите то же самое NASA, (http://satc.gsfc.nasa.gov/). Они наверняка не просто написали программку, запустили ракету и забыли. Пусть даже проблеммы там со Спиритом и ему подобными есть - однако они думали о том как правильно писать программы и чтобы автобус переехавший программиста не помешал полету далекой ракеты. Не верю ((с) Станиславский) что в статье на ZDNet.ru открылась истина недоступная умным людям из NASA работающим чуть побольше чем за 3000 руб. в месяц. Но думаю что найдеться кое-что полезное у NASA для читателей ZDNET. А вот хотя бы такой простой факт - оказываеться, в НАСА не просто думают о том как писать документацию на программы, а еще у них есть такие ужастные вещи как документация к требованиям, тестам, и даже отдельная документация к изменениям вносимым в систему. Не буду даже упоминать о возможных рисках и реакциях на кричискее ситуации. Полистайте пусть немного общие - но правила которые NASA исспользует и сравните с тем что есть сейчас. Т.е. то что сейчас сделали студенты (пускай те же >60% их докуметации оказалось самой программой) оказываеться лиш малая толика того что на самом деле необходимо делать. Что до цивилизованных стран еще ползти и ползти. И что то если нам делают вид что платят - то мы так и делаем вид что работаем. Для справки - если в NASA таки находят баг в чем-то на стадии тестирования - то его не просто проверяют, а делают выводы - что позволило багу появиться и усиленно ищут все возможные которые могут появиться похожим способом. Думаю если бы виноват был программист попавший под автобус - за ним на тот свет следователя или чревовещателя отправлять не будут - почитают что же он написать на английском языке за время жизни успел. Так что уровень соответствия тому как должно быть и как получаеться - пока что остаеться на совести руководства любой фирмы где ставяться цели зарабатывания денег, а не производтва продукции. А на счет открытости - вперед. Позвоните NASA и скажите что вы бы хотели помочь им с проблеммами Спирита или Оппортунити, но для этого вам нужны все чертежи и открытая документация, причем обязательно под GPL ;o) Хорошо сделанная работа всегда стоит денег, и чаще всего больших. Вот только привычка не платить за труд осталась, вот и довольствуйтесь "AS IS", OpenSource и т.п. Требовать что-то (качественную документацию) не давая ничего в замен просто абсурдно !
	Andy 9 Mar 2004 1:07 PM
2Сергей Середа: Да, судя по Вашему описанию Ваших проектов в предыдущих постах, сидите Вы действительно в ... в не очень-то хорошем месте Вы сидите :( Но не отчаивайтесь, Вам просто не повезло.
	Andy 9 Mar 2004 1:21 PM
2AT: "Так что уровень соответствия тому как должно быть и как получаеться - пока что остаеться на совести руководства любой фирмы где ставяться цели зарабатывания денег, а не производтва продукции." И это правильно. Именно зарабатывание денег - наилучший стимул оптимизировать объёмы документации. Будет документации слишком мало, время(=деньги) будет теряться в попытках разобраться "что же это я тут имел в виду?"; слишком много - в процессе заполнения никем никогда не читаемых документов + поисках нужной информации среди второстепенных подробностей.
	СтранниК 9 Mar 2004 1:22 PM
2AT Истина - это то что вы хотите видеть. Я все чаше убеждаюсь в другом: "Не боги горшки обжигают". Так вот если снять рекламную мишуру и прочий налет, то окажется что народ просто использует тривиальные решения. Мне недавно народ рассказывал про программку для управления Цисок с графическим интерфейсом за которую ломили 20к, а для тех кто знает это было всего лишь 4 команды. Главное не сотворить себе кумира. По-моему, в треде все чаще начали появляться мнения "обиженных программистов". "Хорошо сделанная работа всегда стоит денег, и чаще всего больших. Вот только привычка не платить за труд осталась, вот и довольствуйтесь "AS IS", OpenSource и т.п. Требовать что-то (качественную документацию) не давая ничего в замен просто абсурдно !" Назовите, на сегодня по вашему мнению серьезный качественный коммерческий продукт, который с ходу отвечает всем заявленный в рекламных буклетам требованиям ? Я уже давно не слышал о таких. А вот про то, что большинство продктов не рекомендуется ставить до выхода сервис-пака мне уже просто уши прожужали? Так за какое качесто платить то?
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 1:27 PM
2 Хрю: Ваше отношение, не спорю, во многом обоснованно. В то же время, я, при всём своём уважении к профессиналам в области как такового программирования, не могу принять безграмотного подхода к разработке программного обеспечения. === Ваше отношение к практикующим программистам вполне в традиции "теоретического программирования". === Мне очень лестно, что Вы меня относите к теоретикам программирования (к ним относятся, например, Кнут, Дейкстра и Анатолий Шалыто). Однако, к сожалению, моего образования недостаточно для того, чтобы иметь моральное право им называться. === И оно взаимно. Прикладные программисты очень не любят и откровенно опасаются "теоретиков" за их способность подкидывать идейки вроде патентования софта. === Может я и обижу кого-то, но укажу, что люди ограниченные вообще боятся тех, кто может "подкинуть идейки". Именно поэтому все изобретатели и выдающиеся учёные были людьми гонимыми. Ну не охота массам снимать шоры с глаз и выходить из привычного стойла. === Мы-то прекрасно понимаем возможные катострофические последствия, т.к. знаем из чего булки делаются. === Что-то, пока ни один булочник ничего дельного по производственному процессу предложить не смог, больше технологи. Думаю, это потому, что "булочники" - люди трудовые, у них и так дел по горло. А вот технологам и так делать не хрен, вот они и придумывают всякую фигню. Я верно Вас понял? ==== А вот "теоретик" понять не способен. Да и не утруждается. Ему надо на диссертацию насобирать, а там хоть трава не расти. А нам здесь жить и после того как он диссертацию напишет. === 5 баллов! Думаю, году этак в 1917, именно так и рассуждали. Ну я уже писал про "революционных матросов", командующих банками и заводами. И ничего, взамен перстрелянной враждебной народу интеллигенции вырастили новую и за какие-то 20-30 лет, с её помощью всё восстановили. Но "практика" историческими примерами не проймёшь! Чё там думать! Делать надо! Вперёд, в 17 век!!! Ну и т.д. и т.п. А вообще, страшновато становится после знакомства с подобными рассуждениями. Вот они-то как раз и могут привести к тем самым "катастрофическим последствиям". P.S. Хотя, чего надрываемся-то. Как писал Сирилл Норкотт Паркинсон, "ваши стронники не нуждаются в убеждении, а убеждать ваших противников бесполезно". С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	torvic 9 Mar 2004 1:29 PM
2 Шалыто Прочитав тред так и не понял предмет спора. Никто ведь, по-моему, не спорит, что при прочих равных наличие проектной документации лучше ее отсутствия. Насколько я понял, (возможно ошибочно), прочитав упоминание agile development в контексте «программистского шоу-бизнеса», полемизируется один из его тезисов: Working software over comprehensive documentation. Поскольку, внятные аргументы против так и не прозвучали + акцент на документирование, вполне естественно показалось, что как альтернатива опять выступает классическая водопадная модель разработки. Поскольку здесь на форуме большинство - практики, то и соответствующая негативная реакция.
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 1:38 PM
2 Andy: === 2Сергей Середа: Да, судя по Вашему описанию Ваших проектов в предыдущих постах, сидите Вы действительно в ... в не очень-то хорошем месте Вы сидите :( Но не отчаивайтесь, Вам просто не повезло. === Спасибо! Пожалели. А денег не вышлете? P.S. Если Вы считаете наличие развитого ума невезением, то вынужден с Вами не согласиться. Я считаю как раз наоборот. А что самое главное, что так считаю не я один... С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Хрю 9 Mar 2004 2:05 PM
2Сергей Середа: "при всём своём уважении...не могу принять безграмотного подхода к разработке программного обеспечения." Что дает вам основание считать меня и моих коллег (которых здесь немало, как легко заметить по постингам) безграмотными? Учитывая что вы сами (как опять же легко заметить по постингам) отношение к практическому программированию если и имеете, то коссвенное. "..Кнут, Дейкстра и Анатолий Шалыто.." :))) Ну прекратите же меня смешить... Я и так уже животик надорвал над вашим пафосом.. Или вы хотите ответа в стиле Хрю, Qrot и Денис Ритчи? "..ограниченные вообще боятся тех, кто может "подкинуть идейки". Именно поэтому все изобретатели и выдающиеся учёные были людьми гонимыми. " Боже-ж мой... Ну вам то самому не ай-яй-яй числить оппонентов ограниченными людьми, а себя причислять к "выдающимся ученым"? "Что-то, пока ни один булочник ничего дельного по производственному процессу предложить не смог, больше технологи." Вот я и говорю что, не зная как на самом деле делаются дела, вы сильно заблуждаетесь. В нашем деле как раз все существенные технологтческие решения придумываются "булочниками". Или по крайней мере теми, кто недавно от печки. Потому что не представляя процесса реальной разработки ничего путного придумать невозможно. Для начала попробуйте продумать как будет выглядеть цикл прикладной разработки софта в условиях, например, тотального патентования софта, сторонником которого вы являетесь. "Если Вы считаете наличие развитого ума невезением, то.." :))) Ну вот, опять! :))) Заметьте - у практических программеров такое самомнение не в моде :)
	- 9 Mar 2004 2:10 PM
2AT: ну да, пишут документацию, то-се. А толку? Есть огромный список загубленных космических проектов нам миллиарды долларов по вине программистов. Вон, марсоход пришлось перезагрузить. И никак до людей не дойдет - такова индустрия. Все новое, в любой области может содержать ошибки. Программирование - индустрия по производству НОВОГО.
	- 9 Mar 2004 2:11 PM
Насчет Билла Гейтса, у меня больше десятка знакомых на него работает. Это так себе, средний показатель. Самые лучшие работники не к Биллу уезжают.
	me - userinternet.com 9 Mar 2004 2:19 PM
>> Именно поэтому все изобретатели и выдающиеся учёные были людьми гонимыми. Но далеко не все гонимые были изобретателями и учёными. Помни об этом, дорогой друг. >> Назовите, на сегодня по вашему мнению серьезный качественный коммерческий продукт, который с ходу отвечает всем заявленный в рекламных буклетам требованиям? Windows? :)) Странник, ты правильно поставил поставил вопрос: покажите продукт, который делает то, что заявлено. Карандаш подойдёт? Не, не то: ломается от чиха. Может, тогда какой-нить домик, выстроенный стройбатом (это те, что с изменяемой геометрией стен, потоклов и сантехники) не за капиталистические ценности, столь нелюбимые "теоретиками", а "за идею, во имя прогресса человечества". А что, вполне подойдёт. Жить в нём можно - проверенный факт. Давайте так же писать и программы тогда. Ура, товарищи.
	СтранниК 9 Mar 2004 2:30 PM
2me На крепкость карандаша наверняка есть требовония ГОСТ-а, которым он должен соответствовать. А вот нерабочий новый автомобиль ,вы вряд ли захотите забрать из магазина? Или все же заберете? По поводу стоительства. Если вы вселитесь в такой дом ( с нарушенной геометрией), то кто ж вам доктор? Как потребитель вы имеете требовать устранения недоделок или предоставления равноценной жилой площади .
	torvic 9 Mar 2004 2:53 PM
Ну епрст, сколько же можно строительных аналогий? Сравнивали же уже 1001 раз, док-ли, что нельзя сравнивать, Фаулера перечитайте.
	СтранниК 9 Mar 2004 3:01 PM
2torvic То есть сравнивать нельзя , а деньги значит платить нужно? Паршивое качество программных продуктов и завышенные на него цены с одной стороны - а сдругой банальное пиратство. Но похоже это всех устраивает , или точней большинство.
	me - userinternet.com 9 Mar 2004 3:13 PM
>> Если вы вселитесь в такой дом Так если виндовс глючит, то, может, не надо его покупать, а? Весь мир уже десять лет кричит об ошибках в виндовс, но откуда тогда у МС деньги? Чудо? >> На крепкость карандаша наверняка есть требовония ГОСТ-а, которым он должен соответствовать. :)) Смешно, чес-слово.
	me - userinternet.com 9 Mar 2004 3:14 PM
Можно сравнивать, можно. Как машину со столбом.
	torvic 9 Mar 2004 3:20 PM
2 СтранниК Никого это не устраивает. Но и строительным путем (ТЗ - проектирование - разработка и тестирование) уже ходили. Кроме гор документации без продукта ни к чему не пришли. Как рез-т как раз теперешняя ситуация: когда зачастую уже наплевать как, лишь бы как-нибудь.
	СтранниК 9 Mar 2004 3:41 PM
2torvic Я за то чтобы каждый отвечал , за то что он сделал. И не важно строитель он или программист.
	Хрю 9 Mar 2004 4:18 PM
2СтранниК: "Я за то чтобы каждый отвечал , за то что он сделал. И не важно строитель он или программист. " Кроме "теоретиков", естественно ? :)
	СтранниК 9 Mar 2004 4:23 PM
2Хрю А причем здесь "теоретики" ? Теория подтверждется практикой.
	Хрю 9 Mar 2004 4:32 PM
СтранниК: "Я за то чтобы каждый отвечал , за то что он сделал. И не важно строитель он или программист. " Хрю: "Кроме "теоретиков", естественно ? :)" СтранниК: "А причем здесь "теоретики" ? Теория подтверждется практикой." О том и спич :) Причем здесь "теоретики"? Их прерогатива давать ценные указания и считать практиков умственно отсталыми :)))
	Wintermute - devnul.ru 9 Mar 2004 4:45 PM
2 СтранниК: "Мне недавно народ рассказывал про программку для управления Цисок с графическим интерфейсом за которую ломили 20к, а для тех кто знает это было всего лишь 4 команды." Гонишь, двацарик она стоит в комплекте с самой циской :) На круг она около штуки стоит. А насчет 4 команд - святая правда. Может, и не 4, а 8, но порядок верный. Причем факт, что эта графическая прога заменяет 4 или 8 команд, отражен в ее документации.
	Wintermute - devnul.ru 9 Mar 2004 4:54 PM
2 AT: Спасибо за ссылку, очень интересно.
	СтранниК 9 Mar 2004 5:00 PM
2Хрю Знаете я мог бы привести кучу примеров, когда проблемы решали имеено "теоретики", однако судя из ваших постов наверно это бесполезно. Вы хоть помните, чему учил ваш первый учитель в институте? Он ведь тоже "теоретик", или вы сразу родились "в рубашке и со знаниями"? Если вы конечно присутствовали на лекциях, а не зарабатывали деньги на сборке компов. Я таких "практиков" уже в вдоволь насмотрелся. Я склоняю голову перед преподавателями, которые учили меня решать инженерные задачи. И вырожения о "теоретиках" , тоже слышал и не раз, но тут уж "каждый стремится к своему уровню некомпетентности".
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 6:10 PM
2 Хрю: === Что дает вам основание считать меня и моих коллег (которых здесь немало, как легко заметить по постингам) безграмотными? === Разговор был не Вашей безграмотности (о которой я судить не могу), а о безграмотности модного нынче подхода к разработке ПО. Во-первых, Вы как 3-хлетний ребёнок воспринимаете всё только на свой счёт. "- Если тот, кто украл со стола сливы, съел их с косточками, то он непременно умрёт. - А я косточки выплюнул." Второе. Вы и ваши коллеги можете быть (да и являетесь, наверно, раз так громко кричите ;-) прекрасными специалистами в области прикладного программирования. Тем не менее, это совсем не говорит о том, что Вы из-за этого автоматически сможете проектировать программные комплексы. Да, у одного из сотни это может получиться в силу природной склонности. Но научиться владеть операторами if-then-else, for/while/until, goto и структурами данных - это совсем ещё не значит стать квалифицированным специалистом по разработке ПО. Так же, как знание букв и знаков препинания, не сделает Вас писателем. Для этого нужно много учиться. Попытка же судить о необходимости или ненужности проектирования ПО без квалификации в этой области, это совершенно то же, что и суждения о ненужности проектирования самолётов прекрасными специалистами, скажем, по сборке. Да, специалисты они прекрасные, но в другой области. И какими бы они грамотными в своей области ни были, такой их подход будет безграмотным. Да, бывают исключения (иногда с проблемой специально знакомят неспециалиста, чтобы получить "свежий взгляд"). Но в данном случае, в результате можно получить свежую идею, но никак не новую концепцию или технологию. Она будет создана специалистами. === Учитывая что вы сами (как опять же легко заметить по постингам) отношение к практическому программированию если и имеете, то коссвенное. === Вы имеете ввиду, что я не кидаюсь листингами? А зачем? Кроме того, что Вы подразумеваете под "отношением к практическому программированию"? Я пишу на Ассемблере, Дельфи (Паскаль), С/С++, Перл, встроенном языке 1С, ФоксПро, Клиппер'87, про Бейсик можно и не упоминать... (Пишу, если мне очень нужно или за денажки.) Вам что, мой Curriculum Vitae нужен? Будем меряться длиной написанных программ? Так я вышел из того возраста. С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 6:10 PM
2 Хрю: === Что дает вам основание считать меня и моих коллег (которых здесь немало, как легко заметить по постингам) безграмотными? === Разговор был не Вашей безграмотности (о которой я судить не могу), а о безграмотности модного нынче подхода к разработке ПО. Во-первых, Вы как 3-хлетний ребёнок воспринимаете всё только на свой счёт. "- Если тот, кто украл со стола сливы, съел их с косточками, то он непременно умрёт. - А я косточки выплюнул." Второе. Вы и ваши коллеги можете быть (да и являетесь, наверно, раз так громко кричите ;-) прекрасными специалистами в области прикладного программирования. Тем не менее, это совсем не говорит о том, что Вы из-за этого автоматически сможете проектировать программные комплексы. Да, у одного из сотни это может получиться в силу природной склонности. Но научиться владеть операторами if-then-else, for/while/until, goto и структурами данных - это совсем ещё не значит стать квалифицированным специалистом по разработке ПО. Так же, как знание букв и знаков препинания, не сделает Вас писателем. Для этого нужно много учиться. Попытка же судить о необходимости или ненужности проектирования ПО без квалификации в этой области, это совершенно то же, что и суждения о ненужности проектирования самолётов прекрасными специалистами, скажем, по сборке. Да, специалисты они прекрасные, но в другой области. И какими бы они грамотными в своей области ни были, такой их подход будет безграмотным. Да, бывают исключения (иногда с проблемой специально знакомят неспециалиста, чтобы получить "свежий взгляд"). Но в данном случае, в результате можно получить свежую идею, но никак не новую концепцию или технологию. Она будет создана специалистами. === Учитывая что вы сами (как опять же легко заметить по постингам) отношение к практическому программированию если и имеете, то коссвенное. === Вы имеете ввиду, что я не кидаюсь листингами? А зачем? Кроме того, что Вы подразумеваете под "отношением к практическому программированию"? Я пишу на Ассемблере, Дельфи (Паскаль), С/С++, Перл, встроенном языке 1С, ФоксПро, Клиппер'87, про Бейсик можно и не упоминать... (Пишу, если мне очень нужно или за денажки.) Вам что, мой Curriculum Vitae нужен? Будем меряться длиной написанных программ? Так я вышел из того возраста. С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 6:12 PM
Тысяча пардонов. По техническим причинам (связь в самый интересный момент оборвалась) запостил дважды.
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 6:44 PM
2 Хрю: Сперва не заметил: === Вот я и говорю что, не зная как на самом деле делаются дела, вы сильно заблуждаетесь. В нашем деле как раз все существенные технологтческие решения придумываются "булочниками". Или по крайней мере теми, кто недавно от печки. Потому что не представляя процесса реальной разработки ничего путного придумать невозможно. === Почитайте сперва что-то по ТРИЗ. Хотя бы 4-5 книг. Потом Вы сможете со мной об этом спорить. Пока же, увы. === Для начала попробуйте продумать как будет выглядеть цикл прикладной разработки софта в условиях, например, тотального патентования софта, сторонником которого вы являетесь. === А этот цикл никак не изменится. Кроме того, я лично, не знаю, что скрывается за жаргонным выражением "патентование софта", а знаете ли это Вы? Я же писал о патентовании технических решений, связанных с ПО. Кроме того, я в гораздо большей степени сторонник отмены авторского права на ПО, чем патентования способов обработки данных. Если хотите, я могу Вам изобразить примерный список этапов разработки ПО, хотя это в любом учебнике есть. С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Хрю 9 Mar 2004 7:19 PM
2Сергей Середа: "Вы и ваши коллеги можете быть (да и являетесь, наверно, раз так громко кричите ;-) прекрасными специалистами.." Собсно, а кто и где это "кричал"? Я просто поинтересовался с чего бы вы в этом сомневаетесь. "Попытка же судить о необходимости или ненужности проектирования ПО без квалификации в этой области, это совершенно то же, что и..." А где и у кого вы нашли мысль о "ненужности проектирования"? А что вам дает основание судить о наличии "квалификации в этой области"? Давайте говорить о том что говорится, а не о своих домыслах и предположениях. "...не новую концепцию или технологию. Она будет создана специалистами." Хмм... это какими же такими мифическими специалистами? Которые в университетах сидят? "Я пишу на Ассемблере, Дельфи (Паскаль), С/С++, Перл, встроенном языке 1С, ФоксПро, Клиппер'87, про Бейсик можно и не упоминать... (Пишу, если мне очень нужно или за денажки.)" Ну ладно, беру свои слова условно назад. Хотя мне по-прежнему не понятно как человек, знакомый с практикой программирования может выступать за патентование ПО. Как вы себе представляете процесс разработки в такой ситуации? 1.Придумал, 2.произвел патентный поиск, 3.while нашел do снова думай и делай патентный поиск, 4. запатентовал, 5. написал? Не похоже на разумный подход к разработке, не правда ли? Отсюда и мои сомнения насчет вашего отношения к практикам. Впрочем, довольно пикироваться. Странно, что никто не среагировал на мысль насчет практикующих профессоров. В смысле как в медицине - _обязать_ профессоров (ну вообще "теоретиков") вести реальные коммерческие проекты. Такой "академический аутсорсинг". Сразу станет ясна цена идеям и методикам. Да и денежка появится. А с нею и понимание почем обходится лишний пучок убитых енотов. И "талантливые мальчики" повысят свою практическую ценность (а с нею и рыночную стоимость). Оперируют же больных академики от медицины. И даже симпатичный доктор Брандт в телеке продолжает резать людишек. Или защитников "теоретического программирования" не греет мысль самим написать что-то полезное (ну и ответить за написанное :))?
	Хрю 9 Mar 2004 7:24 PM
2Сергей Середа Предыдущий постинг не углядел. "Почитайте сперва что-то по ТРИЗ. Хотя бы 4-5 книг. Потом Вы сможете со мной об этом спорить. Пока же, увы." Слушайте, ну когда же вы перестанете пальцы-то гнуть? Ну, "теоретик", ладно, понимаю. Но уж и спорить то с вами никто не моги... Такая спесь неприятно выглядит _даже_ у людей, которые могут ее подтвердить чем-то реальным.
	Шалыто -> Хрю 9 Mar 2004 7:51 PM
А если диссертацию уже защитил и не одну, то как? Я просто вижу, как люди пишут програмы для ответственных объектов, и сердце кровью обливается. Культура и подход один - что для интернет магазина, что для самолета. Так что когда что-нибудь падает или тонет, не удивляйтесь. Это делали Ваши "братья".
	Шалыто -> torvic 9 Mar 2004 7:56 PM
Никакого Фаулера перечитывать не буду. Автоматизированный дом от Билла Гейтса или LG. Весь дом по чертежам, а проги кое-как. Или я в чем-то не прав?
	Шалыто 9 Mar 2004 7:59 PM
Что мы вообще обсуждаем? Единственный продукт, который в России считается товаром без гарантий качества, это коробочное ПО. Идея бандитская: не нравится - не покупай. Вы хотите приобрести еще что-либо с такими гарантиями. Кто хочет, может поливать меня далше.
	Хрю 9 Mar 2004 8:01 PM
2Шалыто: "А если диссертацию уже защитил и не одну, то как?" А вот мои слова про "практикующих профессоров" (9 марта, 2004, 19:19 - Хрю) - это скорее в ваш огород. Как вы к этому относитесь? "Культура и подход один - что для интернет магазина, что для самолета. Так что когда что-нибудь падает или тонет, не удивляйтесь. Это делали Ваши "братья"." Ну во-первых (на самом-то деле уже в двадцать пятых) на надо вешать на прикладных прогов все что падает и тонет :). Часовню на холме тоже не мы порушили. Это до нас... Во-вторых никто и не спорил что с качеством ПО есть... как бы это цензурно сказать... большие проблемы. Вопрос не в этом, а в том КАК предлагается их преодалевать. А как предлагается? Что - опять никак? Опять умозрительные гипотезы из окна кабинета? Тогда не стреляйте в пианиста. Играет как может. Есть идеи? Продемонстрируйте! (только не на примере Морского Боя)
	xacid 9 Mar 2004 8:06 PM
2Max.K >Большинство некоммерчских сделано для себя. Документация в некоммерчских продуктах хуже еще на порядок (если сравнивать бесконечно малые). В некоммерческих продуктах она написана программистами для программистов. Если кто сомневается могу прицитировать кусок ДОКУМЕНТАЦИИ к одному из пакетов ТеХ. "Если по каким-либо причинам это не работает, попробуйте пересобрать документ еще раз-другой" во-первых, я не против коммерции как таковой - на СВОЕМ месте она необходима и полезна но на СВОЁМ, а не ВЕЗДЕ всему своё место, и если коммерцию принимать за универсальный принцип то в итоге получим полный маразм (который уже наглядно виден в реале) коммерция должна заниматься коммерцией а наука наукой сейчас же мы видим что коммерция пытается заполонить всё и вся причём самое интересное - ОНА ПРОТИВ СВОБОДНОГО РЫНКА еще раз повторяю - КОММЕРЦИИ ПРИ ОПРЕДЕЛЕННЫХ УСЛОВИЯХ СВОБОДНЫЙ РЫНОК СМЕРТЕЛЬНО ОПАСЕН потому что на действительно свободном рынке конкуренция никогда не прекращается та же коммерция которая уже не хочет ни с кем конкурировать начинает изобретать разные способы как ограничить конкуренцию со стороны других игроков рынка и тут на сцене начинают появляться различные "интеллектуальные права собственности", патенты, лицензии, торговые марки... и начинаются слёзные жалобы государству и обществу о "чьейто" "нечестной" конкуренции... начинаются рыдания в жилетку про "огромные" "убытки"... начинаются просьбы "навести порядок" в этом ужасном "хаосе" (который раньше почему то устраивал, и который по сути они же сами и сделали более хаотичным к слову...) эти явления в экономической теории давно известны и называются кратко - попытка монополизация в экономической теории давно известен тот факт что никакая монополия НЕВОЗМОЖНА без должной на то помощи со стороны государства, которая своими вмешательствами "наводит" "порядок" а на деле просто применяет силу и власть, нарушая естественные экономические процессы....
	Шалыто 9 Mar 2004 8:06 PM
Ничего более ругательного, чем теоретик не придумать? А вы знаете кто отец русской авиации? Не Туполев, и не Яковлев, а Жуковский, и поднялся он в воздух один раз и не на самолете, а на воздушном шаре на ярмарке. А в свое время конкурс по раскрытию парусов выиграл не капитан и не моряк, а 18-летний мальчик по фамилии Эйлер. Так что не все теоретики дурные. И можно пукало поменять с теоретика или профессора, например, на очкарика.
	torvic 9 Mar 2004 8:22 PM
> Весь дом по чертежам, а проги кое-как Да не ради бога, не перечитывайте. Просто тогда не надо упоминать всуе вместе с "шоу-бизнес", "кое-как" ...
	xacid 9 Mar 2004 8:36 PM
2Max.K >Большинство некоммерчских сделано для себя. Документация в некоммерчских продуктах хуже еще на порядок (если сравнивать бесконечно малые). В некоммерческих продуктах она написана программистами для программистов. Если кто сомневается могу прицитировать кусок ДОКУМЕНТАЦИИ к одному из пакетов ТеХ. "Если по каким-либо причинам это не работает, попробуйте пересобрать документ еще раз-другой" во-вторых - а давайте задумаемся над тем "а почему так"? и если отбросить смешные и наивные объяснения "потому что программисты безграмотные, ленивые, эгоистичные, глупые итд итп" (ведь они почему то были достаточно грамотные, трудолюбивые, альтруистичные, умные и тд итп, чтобы вообще СОЗДАТЬ эти некоммерческие продукты), к тому же не думаю что они вообще не проектировали свои творения, и что от отсутствия проектирования они якобы получили какой то выигрыш во времени реализации или трудоёмкости - думаю, наоборот они были бы СЧАСТЛИВЫ вместе с исходным текстом своих детищ предоставить и их проектные сердце и душу - но здесь встаёт весьма практический вопрос - А КАК ЭТО СДЕЛАТЬ? причём не просто сделать, а сделать это простым, надёжным, открытым, всем понятным, не требующим сложного ПО, сложного обучения и временных затрат способом? может быть Вы укажете пальцем на этот волшебный способ? легче всего объявить кого нибудь дураком и с довольной рожей считать что этим всё объясняется... мне кажется что совсем не в этом дело что в коммерческой что в не коммерческой среде уровень IQ думаю достаточно высок (другое дело что с моральными и духовными мотивами деятельности для представителей этих сред разница будет более значительной, но это уже вопрос другой - думаю что кому будет нужно это поймут и оценят... потомки например... и думаю что не только они... но не буду об этом говорить здесь) так вот, если отбросить глупые предположения о чьейто глупости, то останется одна весьма конкретная проблема - КАК ЖЕ ВСЁ ТАКИ НА ПРАКТИКЕ ПРОЕКТИРОВАТЬ СЛОЖНЫЕ СИСТЕМЫ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ? возможно кому то ответ на этот вопрос покажется простым. можно ему позавидовать. наверное он просто никогда не пытался СПРОЕКТИРОВАТЬ процесс проектирования. может возникнуть вопрос - а зачем это вообще делать? может быть и не нужно, не спорю. но тогда пожалуйста ответте мне на такие вопросы как хранить проектную информацию? как обрабатывать проектную информацию? как получать совместный доступ к проектной информации? как обмениваться проектной информацей? и наконец наверное главный вопрос - КАК ПОВТОРНО ИСПОЛЬЗОВАТЬ ПРОЕКТНУЮ ИНФОРМАЦИЮ И СВЯЗАННУЮ С НЕЙ СТРАТЕГИЮ РЕАЛИЗАЦИИ ДЛЯ ОБНАРУЖИВАЕМЫХ В СИСТЕМАХ ПОЛИМОРФНО ПОДОБНЫХ СТРУКТУРНЫХ ПАТТЕРНАХ? может быть вопрос звучит странно или не внятно, допускаю, но пока иначе сформулировать не смог, а сказать хотел вот что - лично я постоянно встречаюсь с тем что уже реализованный кусок кода очень хорошо подходит для целой области задачь, но так же необходима и последовательная правка этого кода, одним словом хорошо известная всем практикам парадигма "вырезать и вставить" и к сожалению ООП без этого самого необходимого проектирования эти случаи свести к одному общему базовому коду просто не может эти случаи известны науке как паттерны и это уже хорошо не хватает только инструмента как бы эти сами паттерны формализовать и поставить на поток повторного использования и синергетического взаиморазвития всех элементов систем и по сути то ничего действительно сложного в этой проблеме нет все элементы необходимые для реализации хотя бы макета подобного инструмента уже имхо присутсвуют... требуется только это всё правильно спроектировать:)
	- 9 Mar 2004 9:02 PM
2Шалыто: никто не против теоретиков или проектирования или документации. Все против "теоретиков", "проектирования" и "документации". А пока вы своей статьей и прочей аргументацией не убедили никого, что вы не относитесь к числу "теоретиков".
	Шалыто -> Хрю 9 Mar 2004 9:03 PM
Да зачем мне практиковать, если я работаю с 60 студентами, которые каждый день до обалдения практикуют. Должен хотя бы один не обалдевать, а думать?
	xacid 9 Mar 2004 9:07 PM
в-третьих, как то смешно и опять таки глупо требовать от разработчиков ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ проектировать это программное обеспечение и составлять ПРОЕКТНУЮ документацию ВРУЧНУЮ!!! Вам не кажется это парадоксом? то что опыт проектирования никак не ФОРМАЛИЗУЕТСЯ как же Вы тогда собираетесь открывать проектную документацию если просто нечего открывать? это подобно тому как пытаться открыть код системы написанной в машинных кодах - машинные коды это и есть код системы, открывать тут более нечего и незачем - это ничем не поможет перенести систему на другую аппаратную платформу, особенно если система была изначально создана в этих самых машинных кодах так же точно и с проектированием - если нет инструментов, то проектирование неизбежно сведётся к рисованию на бумаге стрелочек и кружочков и поиску просветления.... и как то потом зафиксировать это в виде пригодном для реинжиниринга или портирования просто не представляется возможным - это то же самое что потребовать всякий раз при написании новой программы в очередной раз изобрести новый способ изложения того что программа делает... то что уже есть в виде стандартов (государственных или каких нибудь прочих) или готовых программных продуктов просто не пригодно на практике изза своих собственных внутренних и внешних ограничений, изза которых в итоге не только не снижается трудоёмкость проектирования, а повышается в разы, что делает подобные попытки их использования просто бессмысленными... и еще раз повторю - я ОЧЕНЬ сомневаюсь что сегодня НИКТО не проектирует своих создаваемых программных продуктов. без этого этапа написать что нибудь сложнее хрестоматического хеллоуорлда просто не реально... проблема вся только в том что проектирование ПО как правило остаётся интуитивным неформальным процессом которому нет адвекватного выражения в какой либо общепринятой знаковой системе естественно, всегда останется неформализуемая интуитивная творческая часть этого процесса, безусловно, но пока что какого либо естественного способа фиксации результатов этого процесса кроме как непосредственно в коде НЕСУЩЕСТВУЕТ для того чтобы понять самим суть решаемой Вами проблемы просто попробуйте сами изложить проектную информацию какой либо своей системы, но ТАК чтобы: а) Вас понял каждый, а в идеале - вас поняла программа б) применение Вашей нотации возможно на любых аппаратных средствах, включая самые примитивные текстовые терминалы в) применение Вашей нотации не требовало больших трудозатрат, а в идеале - сводило трудозатраты к минимуму ведь по сути для реализации требуемой системы не нужно ничего иного кроме корректного и полного её проекта и учёта особенностей используемого в реализации аппаратного и программного обеспечения. описываемая мной идеальная система проектирования должна обеспечивать автоматическую генерацию всех необходимых для получения готового продукта исходных текстов, включая эксплуатационную документацию, а так же обеспечивать замкнутый цикл разработки, когда ошибки выявленные в процессе тестирования уже готового продукта справляются в самом ПРОЕКТЕ, а не в исходном тексте, и готовая исправленная система получается путем перегенереции необходимых модулей, а не путем внесения исправлений в проектную документацию задним числом. иначе этим способом разработки никто пользоваться не будет (и не пользуется сейчас, потому что поддержка вручную всей цепочки промежуточных этапов от проектной документации до результирующего исходного кода многократно повышает трудоёмкость, а следовательно стоимость и временные показатели)
	- 9 Mar 2004 9:11 PM
2xaccid: "а) Вас понял каждый, а в идеале - вас поняла программа" Это будет просто язык высокого уровня. Который снова надо будет документировать. :))
	VicTor 9 Mar 2004 9:12 PM
2 Хрю: > Странно, что никто не среагировал на мысль насчет практикующих профессоров. В смысле как в медицине - _обязать_ профессоров (ну вообще "теоретиков") вести реальные коммерческие проекты. Такой "академический аутсорсинг". Хрю, ну кто ж Вам мешает? Сделайте шаг вперед, пригласите на разработку студентов от профессора Шалыто, заплатите им за сделанную работу, а проектную документацию пусть делают в свободное от работы время, на занятиях профессора Шалыто. Возможно он не будет против, да и Вы не пострадаете - код останется при Вас и будет закрыт, а проект Вам и на фиг не нужен. Студенты же научатся грамотно оформлять проекты в реальных условиях. Уверен, что если после этого они попадут под Ваше начало, то проблем с ними у Вас будет значительно меньше. > Или защитников "теоретического программирования" не греет мысль самим написать что-то полезное (ну и ответить за написанное :))? Ну, это Вы загнули :) Произойдет это не раньше, чем Билли и его присные ответят за свои поделки.
	Шалыто 9 Mar 2004 9:16 PM
Может быть, я и теоретик, но справа во "мнениях" что-то одни американцы. Вы бы, практики, объединились и какую-нибудь инициативу в программировании предложили. А то последняя из известных мне инициатив, это "Идущие вместе" - книги Сорокина сжигать. Хотелось бы прочитать что-нибудь более конструктивное и осмысленное, чем двухстрочные ответы.
	xacid 9 Mar 2004 9:30 PM
в четвертых - нет смысла думать что проблема кроется в том коммерческая программа/система или нет... и в том и в другом случае есть объективные выгоды от формализации проектных решений и мета-информации (в коммерческих системах - повышение качества, снижение стоимости, уменьшение сроков, сохранение инвестиций, в некоммерческих - то же самое что для не коммерческих плюс синергетический обмен хорошими методами, идеями, паттернами и прочей мета-информацией), так и объективные тому препятствия, которые сводятся к просто элементарному остутствию как научной так и практической базы для подобной инструментальной платформы проектной деятельности в разработке программного обеспечения и так или иначе но мне кажется что прогресс уже накопил достаточную критическую массу теоретических подходов для хотя бы первой попытки реализации базового инструмента разработки как таковой если первая подобная система разработки будет создана и на практике докажет свою работоспособность то дальнейший путь развития этой и подобной ей систем уже будет на качественно новом витке развития - их можно будет проектировать уже научными и я бы даже сказал промышленными способами и технологиями, то есть на них же самих. правильная система проектирования сама должна быть правильно спроектированна, в идеале - на себе самой же то есть мы получим нормальный инкрементный путь накопления результатов интеллектуального труда человека, без которого в других областях деятельности людей просто уже ничего нельзя сделать нового или даже старого. могу привести аналогию с языками программирования - пока не был создан универсальный язык системного программирования не было и универсальной стандартной программмной платформы для реализации чего либо. сегодня, слава Богу, такие язык и система худо бедно существуют - думаю нет смысла подробно объяснять что это Си и Unix (POSIX) так же думаю что в том виде который они (язык и система) имеют сегодня их возможности уже практически исчерпаны - сложность задачь в очередной раз начинает превышать практические возможности среднего не глупого человека. значит нужны новые более высокоуровневые открытые стандартные инструменты реализации компонентов, их интерфейсов, протоколов взаимодействия и прочих весьма сложных в реализации вещей. и еще мне кажется что жизненноважно здесь чтобы инструмент был действительно открытым и по возможности самодостаточным - то есть не зависел от каких либо чьих то желаний, прихотей, мнений и тд. чтобы жизнь этого инструмента могла продолжаться независимо от перечисленных выше факторов человеческой природы, а в особенности от жадности и желания заработать на этом как можно больше. потому что сами свойства этой необходимой системы проектирования просто невозможны если проектировать систему с целью изволечения из неё прибыли как из таковой, то есть лицензирования, продажи и любой иной эксплуатации - она просто не родится и не станет развиваться дальше, а будет мёртвой еще до своего рождения. в идеале система вообще не должна работать ни с какой бинарной информацией - всё должно описываться текстовыми структурными элементами. думаю нет смысла долго объяснять что сегодня уже есть готовый инструмент для хранения в тесктовом виде любой структурной информации - а именно XML. XML мне кажется и должен стать сегодня основой попыток формализации и последующей реализации замкнутой открытой итеративной внутренне-синергетической системы проектирования и реализации программных систем.
	xacid 9 Mar 2004 9:46 PM
>>Вас понял каждый, а в идеале - вас поняла программа" >Это будет просто язык высокого уровня. Который снова надо будет документировать. :)) а почему нет? где сказано что проекты не могут и не должны проектироваться на каком либо языке высокого уровня? докажите принципиальную невозможность подобной технологии? я бы даже сказал что это будет не просто язык высого уровня, а это должен быть метаязык метавысокого уровня он должен быть способен описывать как единый проект свою собственную реализацию для любой платформы где он может и должен использоваться. иначе это будет действительно еще один язык который нужно будет еще отдельно документировать.... и думаю что старик Кнут был чертовски прав в том что, ЭТА система так же должна полностью сама себя документировать как таковую. то есть из проекта системы со всеми необходимыми комментариями (которые должны так же иметь свою структуру, а не быть сырым месивом трюизмов, шуточек просто бреда) короче идея в том чтобы дать всему в проекте своё место, где ему положено быть, хранить всё в одном необходимом для хранения экземпляре, дать всему четкое название-идентификатор которые имеет смысл в своей предметной области, организовать всё в области-пространства имён, придать всему структуру и по заданным правилам получить все необходимые и по возможности наиболее эффективные компилируемые и интерпретируемые исходные тексты всех компонентов системы на всех необходимых для получения заданных свойств системы языках программирования "более низкого уровня"
	- 9 Mar 2004 9:55 PM
> а почему нет? где сказано что проекты не могут и не должны проектироваться на каком либо языке высокого уровня? докажите принципиальную невозможность подобной технологии? Принципиально - возможно. Один раз такой скачок был сделан - от ассемблера к языкам высокого уровня. Легче стало.
	me - userinternet.com 9 Mar 2004 9:56 PM
>> Так что когда что-нибудь падает или тонет, не удивляйтесь. Это делали Ваши "братья". Соответственно, если что-то не взлетает или не едет, то это уже к вашим "братьям". >> Хотелось бы прочитать что-нибудь более конструктивное и осмысленное, чем двухстрочные ответы. Честное слово, я очень хочу понять, что же предлагается делать простым программистам. Из всех преимуществ документации мне пока что видится только одно: помнить, что было написано когда-то и почему именно так. Но проблема-то немного не в этом. Ошибки появляются не через год или два, а в момент начала тестирования. Что нужно написать в документации, чтобы их не стало? А про бардак в головах не надо. Он везде есть. ЗЫ: Хрю, про патентование ПО хочу возразить тебе, однако :)). Один из участников этого форума (с прочерком вместо имени) сказал правильную вещь о том, что программирование - это создание нового. А где новое, там и патенты, знаешь ли.
	- 9 Mar 2004 9:56 PM
2Шалыто: > Может быть, я и теоретик, но справа во "мнениях" что-то одни американцы. Вы бы, практики, объединились и какую-нибудь инициативу в программировании предложили. Нам не за инициативы платят. За инициативы платят вам. Пока, извините за честность, неудачно.
	- 9 Mar 2004 9:57 PM
2Шалыто. И я - не американец.
	me - userinternet.com 9 Mar 2004 9:58 PM
>> где сказано что проекты не могут и не должны проектироваться на каком либо языке высокого уровня? Это сказано вот здесь: http://zdnet.ru/?ID=427760 :))
	xacid 9 Mar 2004 10:02 PM
я даже еще не касаюсь при этом вопросов сопровождения и развития уже созданной системы... вот где кладезь то мешанины и груд бессмысленных имён переменных, процедур, модулей... и самое смешное что никто из МЕНЕДЖМЕНТА не понимает что - ЭТО И ЕСТЬ ИХ ДЕНЬГИ! с определенной точки зрения те бизнес-правила которые зашифрованы в исходных текстах реально работающих и подчас весьма сложных бизнес-систем имеющих историю не в один год, а то и их десятков - это САМОЕ ЦЕННОЕ в этих системах. если бы существовал отделенный от слоя реализации слой бизнес-логики самой предметной области в виде пригодном для программной интерпретации то изменение и усложнение этого слоя это логики и этих правил НЕ ПРЕДСТАВЛЯЛИ БЫ СОБОЙ НИКАКОЙ ПРОБЛЕМЫ даже для самого этого же менеджмента, даже без участия создававших или сопровождающих систему программистов. а так же стала бы сравнительно простой задача портирования системы на новые программны и аппаратные средства без потери преимуществ модернизации (иначе ради чего портировать?). и для этого совсем не нужно изобретать новый язык для каждой новой задачи - КАЖДАЯ НОВАЯ ЗАДАЧА УЖЕ СОДЕРЖИТ В СЕБЕ СВОЙ ЯЗЫК. и анализ, проектирование и реализация в ЛЮБОМ случае сводится к выделению, описанию и программной интерпретации МОДЕЛИ этого языка. только вот вся беда в том что структурирования и декомпозиции в конечном итоге от всей этой деятельности никакой не остаётся - мы получаем в итоге монолитную глыбу чегото под названием "какая то там система чего то". и как с этой глыбой дальше работать (и не просто работать, а развивать дальше, использовать целиком и польностью во всех видах) сказать нам сможет в лучшем случае _очень_ продвинутый специалист (возможно даже автор), а в худшем - никто вообще не сможет
	me - userinternet.com 9 Mar 2004 10:03 PM
>> Вы бы, практики, объединились и какую-нибудь инициативу в программировании предложили. XP предложили люди с весьма и весьма практичным подходом. Как бы оппоненты этой методологии не старались обосновать, например, бестолковость парного программирования, тратить ценное время на обсуждение статей ZDNet некомфортно в присутствии кого-либо ещё.
	xacid 9 Mar 2004 10:08 PM
>Принципиально - возможно. Один раз такой скачок был сделан - от ассемблера к языкам высокого уровня. Легче стало. значит мне кажется есть смысл продолжить начатое и сделать еще один скачёк, ещё одно усилие. не исключеное что станет еще намного легче, чем было при изобретении алгоритмических структурных языков (и всех прочих дальнейших языков высокого уровня) >Это сказано вот здесь: http://zdnet.ru/?ID=427760 думаю что Вы или не поняли или не очень правильно поняли что там сказано. лично я оттуда вынес только то что подобные проблемы кажутся таковыми не только мне одному. извините если мы с Вами о разных вещах...
	Сергей Середа - serge_seredahotmail.com 9 Mar 2004 10:39 PM
2 Хрю: Я принял эту статью близко к сердцу, потому что сам планировал реализовать средний по объёму проект "как надо" с полной проектной документацией, а затем выложить всё это в Сеть, как пример. Плюс у меня года с 2000 лежит статья "Синтаксический и семантический подходы к программированию", где аналогичным образом разграничиваются два подхода к разработке ПО. === Странно, что никто не среагировал на мысль насчет практикующих профессоров. В смысле как в медицине - _обязать_ профессоров (ну вообще "теоретиков") вести реальные коммерческие проекты. Такой "академический аутсорсинг". === Я, например, этому правилу следую, чтобы не "заржаветь". Но это - дело вкуса. А насчёт "обязать", то как Вы себе представляете коммерческий проект в теоретической физике или математике? Я - не очень представляю. В АСУ - более-менее. === "Почитайте сперва что-то по ТРИЗ. Хотя бы 4-5 книг. Потом Вы сможете со мной об этом спорить. Пока же, увы." Слушайте, ну когда же вы перестанете пальцы-то гнуть? Ну, "теоретик", ладно, понимаю. Но уж и спорить то с вами никто не моги... Такая спесь неприятно выглядит _даже_ у людей, которые могут ее подтвердить чем-то реальным. === Да зря Вы обижаетесь. ТРИЗ - Теория Решения Изобретательских Задач. В книгах по этой дисциплине, кроме вопросов решения изобретательских задач, обсуждаются вопросы технического творчества, изобретательства, судеб изобретателей и творчески личностей и мн.др. Поэтому говорить об изобретениях, не владея этим материалом, практически бессмысленно. Так же, как говорить об интегралах, на зная арифметики. А если бы Вы были знакомы с ТРИЗ, то Ваше мнение было бы иным. (А я таких книжек с десяток прочёл.) Насчёт "довольно пикироваться" поддерживаю. И приношу свои извинения за несколько провокационные постинги. Всё упирается не в то, "кто умнее": "теоретики" или "практики". Этот вопрос не вполне корректен. Дело в том, что действительно должно выполняться и проектирование и документирование программных продуктов. Иначе их качества и надёжности не видать никогда. Но этим должны заниматься не программисты, а проектировщики и технические писатели. Совмещать все три функции можно лишь в рамках малых проектов. Ну и очень неплохо было бы, если любой программист знал бы, как проектировать и документировать ПО. (Т.е. был немножко "теоретиком", раз и Вы предлагаете "теоретикам" практиковаться). А сегодня под словом "программист", понимается целый ряд специальностей, вот и получается как с тем пионером: "Ты - в ответе за всё". По-моему, xacid подал очень интересное предложение. Давайте попробуем придумать что-то вроде "открытого стандарта документирования ПО". Я, честно, говоря, был очень удивлён, что в сообществе Свободного ПО нет общепринятых стандартов программирования, библиотек шаблонов, единых требований по оформлению документации и т.д. и т.п. (Во всяком случае, мне об этом не известно.) С уважением, Сергей Середа Движение "ПОтребитель"
	me - userinternet.com 10 Mar 2004 12:19 AM
>> в сообществе Свободного ПО нет общепринятых стандартов программирования, библиотек шаблонов, единых требований по оформлению документации mozilla.org Не то, чтобы прямо "требования", но рекомендации там есть.
	Хрю 10 Mar 2004 12:55 AM
2Шалыто: "Ничего более ругательного, чем теоретик не придумать?" Ладно, оставим "теоретиков" (само подвернулось по тескту статьи). Будем говорить об "академичесокм" и "практичесокм" взгляде на программирование. ОК? "Хотелось бы прочитать что-нибудь более конструктивное и осмысленное, чем двухстрочные ответы." Так мы же от вас новых идеи и ждали, профессор... 2VicTor: "Хрю, ну кто ж Вам мешает? Сделайте шаг вперед, пригласите на разработку студентов от профессора Шалыто..." э-э-э... спокойно. я сам прикладной прог и мне немножечко не до "студентов от профессора Шалыто".. Самому бы вырулить. Хотя пару грамотных праней часто очень надо. "Уверен, что если после этого они попадут под Ваше начало, то проблем с ними у Вас будет значительно меньше." Нет - это у них прооблем будет меньше, а у меня-то больше :) Ну не "позиционируюсь" я лично в этой теме. А вот Анатолий Шалыто - да. К нему и вопрос. "Произойдет это не раньше, чем Билли и его присные ответят за свои поделки." Ну каждому кто что-то работающее написал есть за что ответить. :) 2me: "А где новое, там и патенты, знаешь ли." Ну вот и представь себе... себя, который прежде чем что-нить написать прикидывает - а не запатентовал ли уже какой-нить ХХХ это решение? Если запатентовал - он тебя потянет в суд. А если нет - беги патентуй. Только денежку не забудь с собою взять. Иначе - ХХХ сам это запатентует и тебя опять в суд... Нравится так работать? Вот и мне чтой-то не очень... 2Сергей Середа: "...сам планировал реализовать средний по объёму проект "как надо" с полной проектной документацией..." Вот тут одобрямс. "Плюс у меня года с 2000 лежит статья "Синтаксический и семантический подходы к программированию", где..." А вто это можно было бы и придержать до _результатов_ того проекта :). (ИМХО конечно же). "Вы себе представляете коммерческий проект в теоретической физике или математике? Я - не очень представляю" Оставим чисто теоретические дисциплины. Медицинская школа-то это практикует? Т.е. профессора, доценты и академики там разные от медицины _обязаны_ подолжать копаться в ливере живых (пока еще ;)) пациентов? И русская медицинская школа по-прежнему оччень уважаема. Почему бы и в программерском деле не перенять эту, вполне разумную, традицию? Ведь прикладное программирование имеет много аналогий с врачеванием (вот уж больше чем со строительством). Собственно мне очень интересен ответ Анатолия Шалыто по этому поводу. ЗЫ: А неплохо вышло, что каждый каждому здесь на любимую мозоль наступил :) Вроде и веселее пошло. И даже xacid оказался вовсе и не отморозком (хоть и многословен сильно) ;)
	Bulat - rootbulat.f0.ru 10 Mar 2004 3:35 AM
>torvic: >Да-да-да, а позвольте поинтересоваться как вы собираетесь это >доказывать? Есть кое-какие методики, но в общем случае больших успехов не достигли, как и везде в мире. Но для определенных частных случаев уже есть вполне коммерчески-применимые результаты. (конкретно у меня очень мало, а в Европе и штатах довольно-таки прилично уже) >torvic: >Единственный вариант в случае с императивными языками, который >я себе предствляю, это построение КА и трассировка всех его >возможных состояний. Вы не Дункан Маклауд в реале? Или все >строем на декларативные языки? Если честно - Дункан Маклауд. :) >Владимир Габриель: >А что, мне нравится идея, если бы ZDNet выступил бы в качестве >площадки то я бы был готов начать открывать документацию и >процесс разработки www.docsvision.com Я на свои проекты давно уже открывал публике (правда не широкой, а в основном локальной, потому как широкой оно не особо интересно, IMHO). А так инициативу приветствую. Если надо, хостингом (не очень быстрым, но хоть каким-то) могу поддержать. Так что пишите (мыло указано). >Шалыто: >Не понял юмора про топ -проекты! >Если Вы подобное найдете еще где-нидудь в русском Интернете >сообщите! :))) Ну, просто, эти проекты кроме улыбки ничего не вызывют - если их рассматривать в том контексте, в котором Вы их изначально упомянули в обсуждении.
	Bulat - rootbulat.f0.ru 10 Mar 2004 3:36 AM
>Шалыто - Хрю: >А про игру Robocode - из десятков тысяч танков только у нас >есть проектная документация, поэтому их легко модифицировать, >что было сделано во втором варианте танков при обучении детей >студентом Д.Кузнецовым во Дворце творчества юных. Но Вам, ведь, >наплевать на это и на юных и кто их будет учить и как? Главное - >пожрать и ... IMHO это Вы тут приводите ни к селу ни к городу. Насколько я понял Вы предлагали открытую проектную документацию как-раз-таки тем кто хочет пожрать, а теперь вдруг начинаете все рассматривать будто бы все это для обучения, а не для тех кто хочет пожрать. >Шалыто - Хрю: >А Денис, между прочим, двухкратный призер >командного чемпионата МИРА по программированию, но Вам и это >неважно! Главное - хрю! Да это никому здесь не важно. Я вполне верю что призер такого чемпионата действительно крут, но сюда-то это каким боком относится ? >Dmitry: >Сам я не против разумного (разумного) документирования. Так >документ - описание концепции, содержащий рассмотренные, >принятые и отклоненные архитектурные решения, неочевидные >трудности, возникшие при реализации, может быть краткое >описание базовых классов, полезен всегда. Все остальное есть в >коде. Полностью поддерживаю, это почти то же самое что я хотел еще написать здесь. :)
	Bulat - rootbulat.f0.ru 10 Mar 2004 3:36 AM
>Шалыто -> Dmitry: >Неужели у Вас язык поднимается так говорить о людях? Один из >моих мальчиков летит сейчас в самолете на двухдневное >интервью "к Биллу Гейтсу", пройдя три телефонных интервью, на >двух из которых ему по-английски говорили: "Диктуй код". И после этого Вы еще осмеливаетесь говорить о думании о будущих поколениях ? >Wintermute: >2 Хрю: Я же говорил - забейте на тему. Мужик обеспечил себя >работой за счет налогоплательщиков (расшифровываю - наш с вами) >на долгие годы. Таких "деятелей" в системе Академии Наук очень >много, чересчур много. Поделать с этим ничего нельзя, это >система. Ясен пень - такова вся фундаментальная наука - со стороны кажется что толку никакого и человек просто для себя что-то там придумывает. (ну вопросы отмыва бабок вообще не рассматриваем) Ну, да в любом случае, мы тут во-первых имеем шанс просто пообщаться :), во вторых найти единомышленников, в третьих отточить свои тезисы, и в четвертых - вдруг удастся направить наши деньги в то направление которое нам в последствии поможет. >AT: >2Шалыто: На счет диктуй код - вы же вроде как опытный человек. >Код просили продиктовать наверняка для какой-то простой задачки >типа сложить два чилса или найти среднее арифметическое.. Да не, там небось просили пин-код от кредитки - на кардеров нарвался. :))) >o: >2 Хрю: >> А вот прикол каких мало: >"А сходили бы раз на симфонию Чайковского, которую исполняют >великолепные музыканты, получающие три тысячи рублей (!) в >месяц, многое бы поняли" >Это не прикол, тупица. Если симфонию Чайковского исполняют >великолепные музыканты, получающие три тысячи рублей в месяц, >то это говорит о том, что для них качество работы и исполнения >музыкальных произведений превыше всего. Даже превыше мизерной >зарплаты в 100 долбаных у.е. Надо бы у них поучиться. А зачем у них учиться ? :O Вы еще у меня поучитесь - контузия головы и пр. прелести вообще забесплатно. :) А они, IMHO, получают 3000р. только потому, что им лень отрывать задницы от стульев и, забросив на пару часов в день свои треннировки, подыскивать местечко получше - в общем крутиться. (ну, и в продолжение - патриот не тот кто торчит здесь и нифига не делает, а тот кто, пусть даже уехал забугор, но тащит сюда бабло, военные секреты и пр. :)) >Шалыто - Qrot: >Проектов-то может быть и нет, но даже их почему-то никто >раньше, чем с третьего раза сделать не может, и это при том что >все работают программистами. Ну и что что сделать не могут, это каким-либо образом приближает их по объему кода, документации и пр. к большим проектам что-ли ? :O >Шалыто - Qrot: >Ни в одной книге даже таких проектов нет! А учить-то нрод надо - >так что делали проекты и делать будем! Ага, значит это все только для обучения ?! Тогда обеими руками за и даже очень заинтересован, особенно если разрешите использовать Ваши материалы в обучении.
	Bulat - rootbulat.f0.ru 10 Mar 2004 3:37 AM
>Шалыто - Qrot: >Через год студенты уже говорят спасибо. И Вы бы сказали... Наверное это выглядит так: Ш: Хотите я вам еще проектик дам ? С: Нет уж, спасибо. ;))) >Шалыто -Qrot: >А то, что ПВО США работает само по себе, так как нет ни тех >людей, ни документации Вас не смущает? И Вы думаете такая >ситуация только у ПВО США? Я знаю о примерах поближе! А еще мы не можем разгадать всяческие древние письмена и пр., думаете тоже из-за того что на них не была подготовлена проектная документация ? :) IMHO, вся документация на ПВО и пр. была, а может и сейчас есть. Просто в ней черт ногу сломит, а-то и потеряли часть, по какой-либо причине. Ну и вопрос все равно возвращается к деньгам - от того, что _сейчас_ неизвестно как оно работает, разработчикам _тогда_ дополнительно все-равно не заплатят. :) >Хрю: >Насколько мне известно в медицине, например, существует >принцип - если ты профессор или даже академик там какой, ты тем >не менее должен практиковать как врач - т.е. вети больных, >делать операции и т.п. Причем с применением методик, которым ты >учишь своих студнтов. Иначе доверие к твоему учению... >несколько снижается. Это во всех сферах жизнидеятельности так, но, IMHO, и в этом не стоит перебарщивать. Для меня, вот, человек не нюхавший пороха и не поимевший пулю себе в задницу тоже недочеловек. Но насколько такой подход приемлем ? >Шалыто -> torvic: >Никакого Фаулера перечитывать не буду. Автоматизированный дом >от Билла Гейтса или LG. Весь дом по чертежам, а проги кое-как. >Или я в чем-то не прав? Честно говоря, сейчас даже аппаратная часть в таких домах делается кое-как, и, в основном по настоянию заказчика. Это я как неоднократный руководитель таких проектов говорю, причем наши партнеры из Германии жалуются на тоже. (правда криво спроектированы даже сами референтные схемы от Siemens и пр.) Хотя мы готовы заказчику такой дом проектировать не один год и проверить все миллион раз. :) >Шалыто: >Что мы вообще обсуждаем? Единственный продукт, который в России >считается товаром без гарантий качества, это коробочное ПО. Отнюдь - в России на деле любой продукт является товаром без гарантии качества. (есть правда категории граждан для которых любой продукт имеет пожизненную гарантию качества :) ) >Шалыто: >А вы знаете кто отец русской авиации? Не Туполев, и не Яковлев, >а Жуковский, и поднялся он в воздух один раз и не на самолете, >а на воздушном шаре на ярмарке. Только он проектировал какие-никакие, но летательные аппараты для реальных задач, а не бумажные самолетики, и не учил других делать бумажные самолетики с полной проектной документацией, и уж темболее не занимался пропагандой повсеместного внедрения проектной документации. :)))
	Bulat - rootbulat.f0.ru 10 Mar 2004 3:37 AM
>xacid: >в четвертых - нет смысла думать что проблема кроется в том >коммерческая программа/система или нет... >и в том и в другом случае есть объективные выгоды от >формализации проектных решений и мета-информации (в >коммерческих системах - повышение качества, снижение стоимости, >уменьшение сроков, сохранение инвестиций, в некоммерческих - то >же самое что для не коммерческих плюс синергетический обмен >хорошими методами, идеями, паттернами и прочей мета- >информацией), так и объективные тому препятствия, которые >сводятся к просто элементарному остутствию как научной так и >практической базы для подобной инструментальной платформы >проектной деятельности в разработке программного обеспечения Такие системы разрабатываются уже давно, и даже уже существуют. Пока они не столь универсальны и удобны, как хотелось бы. Но самое главное подходы пока строго формализованы только для таких узких областей как, например, проектирование реляционных СУБД. Хотя, круг проработанных областей сейчас на текущий момент сильно расширился и продолжает расширяться. IMHO, Вам (как и г-ну Шалыто), стоило бы все-таки изучить мировое современное состояние дел в этой области, прежде чем вести здесь дискуссии - а-то нафталином пахнет. :) >Сергей Середа: >По-моему, xacid подал очень интересное предложение. Давайте >попробуем придумать что-то вроде "открытого стандарта >документирования ПО". Да есть их уже куча, и прежде чем создавать очередной, стоит хотябы изучить имеющиеся. А так инициативу поддерживаю.
	Bulat - rootbulat.f0.ru 10 Mar 2004 3:41 AM
В общем, поддерживаю предложения объединиться в исследовании этого вопроса. Но предлагаю расширить его так, чтобы он включал и вопросы формализации задач, и вопросы формализации процесса проектирования, и вопросы формализации представления моделей/документаций и пр.. P.S. Заинтересованные можете писать мне на мыло, все welcome !
	Bulat - rootbulat.f0.ru 10 Mar 2004 5:55 AM
Я также с радостью поучаствую и в вопросах разработки методик формализации, позволяющих дальнейшее формирование теорем (в частности корректности алгоритмов/реализаций) и их доказательство.
	VicTor 10 Mar 2004 9:16 AM
2 Хрю: > "Хрю, ну кто ж Вам мешает? Сделайте шаг вперед, пригласите на разработку студентов от профессора Шалыто..." > > э-э-э... спокойно. я сам прикладной прог и мне немножечко не до "студентов от профессора Шалыто".. Самому бы вырулить. Хотя пару грамотных праней часто очень надо. А вот в этом-то вся и беда. Надо бы пару толковых парней, а взять не откуда. Подготовка студентов Вас не удовлетворяет, а готовить кадры для себя Вы не хотите, ибо некогда и хлопотно :( > "Уверен, что если после этого они попадут под Ваше начало, то проблем с ними у Вас будет значительно меньше." > > Нет - это у них прооблем будет меньше, а у меня-то больше :) А "без расходов - нет доходов" (c)кто-то от финансов.
	Сергей Середа - serge_seredahotmail.com 10 Mar 2004 9:38 AM
2 Bulat: === >Сергей Середа: >По-моему, xacid подал очень интересное предложение. Давайте >попробуем придумать что-то вроде "открытого стандарта >документирования ПО". Да есть их уже куча, и прежде чем создавать очередной, стоит хотябы изучить имеющиеся === Это конструктивно. Давайте тогда для начала попробуем слепить список уже разработанных стандартов/рекомендаций. Давайте URL-ы. Пока звучали mozilla.org и http://satc.gsfc.nasa.gov . От себя могу дать "страшно неизвестную" ссылку - http://www.linuxdoc.ru/ P.S. Если вдруг что-то срастётся, можно попробовать разместить рабочие материалы на "ПОтребителе". С уважением, Сергей Середа Движение "ПОтребитель"
	Шалыто 10 Mar 2004 10:02 AM
Кто мне платит? И что мне платят? За одну из публикаций про инициативу я получил 600 рублей! Хотите поделюсь? Инициатива в одном - меня не устраивает ситуация с документацией на ПО, если вас устраивает, то нет ни спора, ни проблем!Такой ситуации, как с ПО нет больше ни с чем - и так долго продолжаться не будет. Хотя бы почитайте статьи про Открытые исходники на этом сайте!
	Max K. - maxim.korotkovmobile-review.com 10 Mar 2004 10:13 AM
«Даже простой торговец шерстью должен думать не только о том, как подешевле купить или подороже продать, но и о том, чтобы вообще могла беспрепятственно вестись торговля шерстью» (Галилео Галилей) Перефразируя, скажем, что даже простой программист должен думать не только о зарабатывании большего числа зеленых президентов, но и о том, чтобы было меньше нареканий на программирование как на отрасль. Те, кому последнее неинтересно, могут дальнейшее пропустить. Итак, попробуем систематизировать нижесказанное: Тезис первый: проблема качества ПО имеет место и достаточно важна. И не говорите, что «не надо все сваливать на прикладные проги». Если звезды зажигают… Даже если из 2 ошибок \ поломок \ катастроф одна – действительно на счету прикладных прог, то это уже ОЧЕНЬ МНОГО. И вспомним, что практически ВСЕМ прямо или косвенно управляют программы. Такая вот арифметика. Тезис второй: проблему надо решать Смотри начало постинга Теперь о решении: качественная проектная документация помогает не только легко вносить изменения (лет чрез дцать), но и ОТСЛЕЖИВАТЬ ОШИБКИ (проверено на собственном опыте). Таким образом, в тех проектах, которые не рассчитываются на «выбрасывание через год», она (документация) необходима. И чем дальше, тем больше. Документировать программу должны представители команды разработчиков – по-моему это очевидно, иначе мы получи хелп, а не документацию. О классификации проектов и стоящих задачах. 1. небольшие проекты (одиночка или команда из 2 – 3 программистов) – удобно документирование в текстовом процессоре. 2. проекты с большой («а 3 это куча?») командой разработчиков, но со строго поставленной задачей – формализация решения до уровня конечного автомата, с последующим сведением к случаю 1. Интерфейсы взаимодействия документируются отдельно, на первом этапе разработки и после меняются незначительно. Основной вопрос – структура. Такие проекты (со строгим ТЗ) редки. 3. проекты с «изменяемой геометрией», то есть либо очень большие проекты, в которых основная сложность – стыковка частей, а не их кодирование или проекты, требующие активной работы с заказчиком (неважно сводятся они к КА или нет) – таких проектов большинство. Вот здесь вопрос открыт – текстовый процессор не подходит (придется переписывать все 100 раз…) Требуется среда документирования ПО. Основные требования к среде: а. Возможность создания «иерархии документации», включения в текст графиков, диаграмм и вообще генерация связного текста (системы типа javadoc не подходят) б. Возможность ненавязчивой модификации документации вместе с модификацией проекта (вплоть до полной переработки структуры) в. Поддержка аналога CVS – всем ясно зачем (а вдруг в проекте 100 человек работает :) добавляйте! Мне пока видится интегрированный с CVS препроцессор TeX, генерирующий pdf с древовидным оглавлением и ссылками. PS: о патентах. А если изобрел не «ты», а «фирма»? Т есть фирма А вложила К (а может даже и М) долларов в продукт Х. А фирма Б (нехорошая такая…) взяла и скопировала продукт Х, создав полностью аналогичный продукт У. Продукт У дешевле, ведь Б не вкладывала денег в разработку. Что делать А? И надо патентовать или нет? Кстати, здесь документация помогает. Ведь код защищается копирайтом, а патентуется – метод! А документация как раз описывает метод, который можно запатентовать.
	Шалыто - Хрю 10 Mar 2004 10:26 AM
Про врачей - это сильно! А тот кто придумал ноты - он музыку писал? Может - да, а может - нет. Это неважно. Важно то, что десятки студентов, работающих в программистских фирмах не умеют писать проектную документацию, и я их учу этому! Уже сейчас я и они видят результаты. Если есть плохие проекты, то это должно поубавить в них спесь - это можно сделать только таким способом - выкладывая в Интернет! И еще. У меня на сайте скоро будет наполняться раздел - Визуализаторы. Сотни толковых студентов программировали алгоритмы с их визуализацией? Ну и что? Вкусовщина не больше! Я предложил метод формального построения логики визуализаторов - и этом вопросе все изменилось! Вот для чего нужны профессора, теоретики и как Вы нас там еще называете! А просто программировать много ума не надо - это сегодня уже умеют многие! Даже Гейтс заговорил (здесь на сайте), что ему методов не хватает. Как говорится, когда живешь - доживаешь!
	Хрю 10 Mar 2004 10:42 AM
2Max K.: "о патентах. А если изобрел не «ты», а «фирма»?" А что это меняет кроме масштаба беды?
	Сергей Середа - serge_seredahotmail.com 10 Mar 2004 10:42 AM
2 Шалыто: === И еще. У меня на сайте скоро будет наполняться раздел - Визуализаторы. Сотни толковых студентов программировали алгоритмы с их визуализацией? === Вот, кстати, вспомнил: http://alglib.dore.ru/ и программа там любопытная для редактирования блок-схем с возможностью последующей генерации кода для Дельфи. С уважением, Сергей Середа Движение "ПОтребитель"
	Max K. -> Хрю 10 Mar 2004 10:44 AM
--- А что это меняет кроме масштаба беды? --- Я же объяснил. Фирма вложила деньги в разработку и должна защититься от воровства идей. Или не должна?
	- 10 Mar 2004 10:48 AM
2xacid: "значит мне кажется есть смысл продолжить начатое и сделать еще один скачёк, ещё одно усилие. не исключеное что станет еще намного легче, чем было при изобретении алгоритмических структурных языков (и всех прочих дальнейших языков высокого уровня) " Бьются, понятно, не один год. Тут такое дело. Если для системной области преобладают диалекты C, то для баз данных уже используют SQL (фактически мета язык), для обработки текстов perl и другие скриптовые языки. Проблема объединить эти методы. Похоже, что невозможно в одной концепции удовлетворить потребности системщиков, бд-шников, настройщиков бух. проводок, и любителей записывать передачи по видеомагнитофону. Вернее, объединить можно, но язык получается раздутым до практической невозможности его использовать. Какие-то продвижки есть в C++ (generic programming, а не oop). Но все-равно такая фигня получается...
	Сергей Середа - serge_seredahotmail.com 10 Mar 2004 11:05 AM
2 Max K.: === Основные требования к среде: а. Возможность создания «иерархии документации», включения в текст графиков, диаграмм и вообще генерация связного текста (системы типа javadoc не подходят) б. Возможность ненавязчивой модификации документации вместе с модификацией проекта (вплоть до полной переработки структуры) в. Поддержка аналога CVS – всем ясно зачем (а вдруг в проекте 100 человек работает :) добавляйте! === Мне видится реализация подобного инструментария при помощи СУБД. Там автоматически получается и иерархия и возможность лёгкой модификации и простота навигации и совместный доступ к документам и разграничение доступа т.п. ==== Мне пока видится интегрированный с CVS препроцессор TeX, генерирующий pdf с древовидным оглавлением и ссылками. ==== Да, но в итоге получается "дубовый документ", внести изменения в который практически невозможно. А если он будет "весить" мегабайт 40 (а он будет) и нужно будет обновить пару строчек? Да ведь пользователи такой документации просто взвоют. === PS: о патентах. А если изобрел не «ты», а «фирма»? Т есть фирма А вложила К (а может даже и М) долларов в продукт Х. А фирма Б (нехорошая такая…) взяла и скопировала продукт Х, создав полностью аналогичный продукт У. Продукт У дешевле, ведь Б не вкладывала денег в разработку. Что делать А? И надо патентовать или нет? === А на самом деле проблема не столько в патетовании. Проблема в том, как вернуть потраченные на разработку деньги. Сейчас это делается при помощи коммерческой тайны. По-моему, патентование является более прогрессивным способом решения проблемы. Кроме того, даже если бы патенты не существовали вообще, всё равно сформировалась бы система, эквивалентная патентной. Это закономерно и не зависит от наших с Вами желаний. Не было бы патентов, заключали бы контракты о неразглашении и платили бы если не роялти, то сумму по контракту. Просто патенты узаконили общепринятую систему. === Кстати, здесь документация помогает. Ведь код защищается копирайтом, а патентуется – метод! А документация как раз описывает метод, который можно запатентовать. === Верно. Я тоже об этом подумал, но решил не лезть в обсуждение другой темы. С уважением, Сергей Середа Движение "ПОтребитель"
	torvic 10 Mar 2004 11:28 AM
2 Max K, Сергей Середа > О классификации проектов и стоящих задачах Наконец-то. Только на практике это уже пройденный этап. а. Почему javadoc не подходит? Потому что нужна иерархия? Есть jDox, NDoc c XML. Ну и что, что "дубовый"? Изменения вносятся автоматом, вес не проблема. Добавьте сюда Rational XDE и будет вам счастье. б. А что такого навязчивого в изменении комментариев на уровне исходного текста? Модификация сруктуры проекта - рефакторинг. в. cvs, svn зачем аналоги? чем не устраивает? "и иерархия и возможность лёгкой модификации и простота навигации и совместный доступ к документам и разграничение доступа т.п." Припашите к вышеперечисленному wiki.
	Max K. -> Сергей Середа - maxim.korotkovmobile-review.com 10 Mar 2004 11:33 AM
--- Да, но в итоге получается "дубовый документ", внести изменения в который практически невозможно. А если он будет "весить" мегабайт 40 (а он будет) и нужно будет обновить пару строчек? Да ведь пользователи такой документации просто взвоют. --- Дык пользователи-то в основном сами программисты. Кстати я, вроятно, неточно выразился. Править надо будет пару строчек в "исходниках докумнтации", которая, возможно, должна быть набором TeX (или "над-TeX") -исходников, хранящихся в SQL БД с удобным интерфейсом доступа (да, про CVS тоже не забываем :). А весить будет скомпиленная pdf. Которых, кстати, будет много, по разделам. И весить не 40 а 400 (у меня документация проекта, кот. делали вдвоем весит 3.36 мб (pdf), при том, что в нем всего 150к кода)
	Сергей Середа - serge_seredahotmail.com 10 Mar 2004 11:50 AM
2- Max K.: Теперь ясно. 2 torvic: Вопрос в одном: реализаций куча, а всё равно находятся недовольные. Может стОит просто (в смысле что непросто) хорошенько спроектировать систему документирования: рассмотреть технологию, технику и эргономику? Кстати, вернёмся к вопросу рассмотрения накопленного опыта (как обязательному элементу любого проектирования). Вы случайно нигде не видели материалов, в которых упомянутые Вами системы сравнивались бы по функциям, аппаратным требованиям, удобству работы и т.п.? С уважением, Сергей Середа Движение "ПОтребитель"
	Max K. -> torvic - maxim.korotkovmobile-review.com 10 Mar 2004 12:05 PM
--- а. Почему javadoc не подходит? Потому что нужна иерархия? Есть jDox, NDoc c XML. Ну и что, что "дубовый"? Изменения вносятся автоматом, вес не проблема. Добавьте сюда Rational XDE и будет вам счастье. --- javadoc не подходит, потому что хочется писать связный текст (иногда вынесенный за перделы класса, метода и пр. - описывающий архитектуру). Кроме того, хочется картинки и диаграммы. Делать это в коде - перегружать его ("...коня и трепетную лань!"). Я вот как представлю себе ТеХ-комментарии прямо в коде - жутко делается. Продукты компании Rational ориентированы на Rational Unified Process, а хочется документировать, например, XP проекты. --- б. А что такого навязчивого в изменении комментариев на уровне исходного текста? Модификация сруктуры проекта - рефакторинг. --- Повторюсь - комментарии это НЕ ДОКУМЕНТАЦИЯ. Документация - связный (в идеале, литературный) текст, снабженный всеми необходимыми ссылками, пояснениями и пр. (см. выше). Javadoc (в ее теперешнем понимании) - "хелп к внутренностям", а документация - не хелп! Рефакторинг должен, кстати, идти параллельно с рефакторингом документации. Из области высшего пилотажа: интеграция с Refactoring Browser и системами автоматизированного тестировнаия, типа DUnit. --- в. cvs, svn зачем аналоги? чем не устраивает? --- CVS как раз устраивает. Вопрос не в ней, а интеграции всего этого. Если у кого-то есть живые примеры использования CVS для совместной работы над текстом (не КОДОМ, а ТЕКСТОМ) - делитесь.
	torvic 10 Mar 2004 12:36 PM
2 Сергей Середа > Вопрос в одном: реализаций куча Функциональных отличий мало, обычные средства автодокументирования, каждый для своей платформы. Мне хватает. Работал с javadoc и NDoc - одинаково удобно. 2 Max K. XDE не для того чтобы подсаживаться на Unified Process, а только для UML-схем, работающих в обе стороны. А что вы хотите описывать связным текстом и картинками с диаграммами? UML + NDoc + легко читаемый исх.текст с тестами + описание архитектурных и алгоритмических решений. Что еще для счастья надо? Интеграция всего этого? А зачем, что это даст? Системного эффекта не будет, сразу предупреждаю.
	Max K. -> torvic 10 Mar 2004 12:59 PM
Для счастья нужны описания. Мы хотим описывать систему человеческим языком. Так сказать "кесарю - кесарево...". На уровне if-elseif комментарии, на уровне параметров функций - javadoc, на уровне архитектуры системы, ее логики, ее устройства - текстовые описания. Правда, последний уровень включает части первых двух, но это, видимо, судьба.
	torvic 10 Mar 2004 1:24 PM
Ну тады я не понимаю, что предлагается. Там где надо и хочется, там делают или заставляют делать. Там где не надо или не хотят, там не делают. Чем тут "теоретики" помогут, я не представляю.
	Хрю 10 Mar 2004 2:48 PM
"Max K. "Я же объяснил. Фирма вложила деньги в разработку и должна защититься от воровства идей. Или не должна?" Ну все правильно. Должна. И если смотреть с этой стороны - все вроде бы логично. Проблема в том, что у этой медальки есть и обратная сторона. И она называется ж...па :). А именно: теперь та же фирма берется за следующий проект. Обнаруживается проблема. Разработчикам (проектировщикам, аналитикам) приходит в голову идея как это решить. Но идею реализовывать нельзя. Сначала надо понять - а не запатентовал ли кто-нибудь что-нибудь похожее. А это очень непросто. И искать надо не только в местных патентах, но и в патентах других стран. Значит останавливаем разработку и производим патентный поиск. Если вдруг нашли что-то похожее - значит реализоввывать эту (свою, между прочим) идею не моги. Если не нашли - патентуем (денежку платим). Иначе конкурент сам запатентует и нас же в суд потянет. И только потом разрабатываем. Разработка плавно перерастает в игрища юристов и патентоведов. Собственно разработка становится нерентабельной. Рентабельным становится бизнес по подаванию в суд на всех и каждого (ско не убеждает?) Я тогда уйду в юристы. Буду сидеть и изучать новый софт на предмет поиска сколь-нибудь нетривиальных идей. И если эти раззявы не успели запатентовать хотя бы один клик... то бегом патентовать сам. На бегу сочиняя иск в суд. Озолочусь. :) Вот я и удивляюсь что сторонники патентования (неглупые, казалось бы, люди) абсолютно не думают о практическом процессе разработки. Т.е. перхоть лечим отсечением головы. (У кого была, конечно ;))
	me - userinternet.com 10 Mar 2004 3:25 PM
>> Проблема в том, что у этой медальки есть и обратная сторона Тем не менее, люди "простых" профессий как-то её умудряются обходить. Я согласен, конечно, что поиск патента на "Привет, мир!" займёт гораздо большее время, чем написание этой программки с нуля. Вот только у нас в России ты не запатентуешь настолько тривиальный "метод". Не спорю, с патентованием ПО ожидается некоторое количество проблем (если кому-то из программистов такой подход просто не нравится как ограничивающий, то пускай идут в юристы. Не жалко, чес-слово :)) Нифига не наезд, кстати), но в перспективе они вполне решаемы. >> Но идею реализовывать нельзя. Сначала надо понять - а не запатентовал ли кто-нибудь что-нибудь похожее. В любой книжке по прикладному программированию написано чёрным по белому: прежде, чем что-то написать самостоятельно, попробуйте найти готовое решение. Дешевле получится. Не все любят книжки, конечно. Надо с собой воевать на эту тему :)).
	me - userinternet.com 10 Mar 2004 3:26 PM
Это был жуткий оффтопик.
	А.Хохлов 10 Mar 2004 3:31 PM
В статье поминалась программа из шести строк, которую не мог понять некий выдающийся (!) программист. Ни документации, ни комментариев надо понимать к программе не прилагалось... Для разговора приведу другой пример - алгоритм Кнута-Морриса-Пратта для поиска строк. Он много где описан (Вирт, Кормен, ...). Можно здесь посмотреть -http://algolist.manual.ru/search/esearch/kmp.php - переписано из какой-то книжки. И текст невелик и некое подобие описания (документации) есть и даже пара комментариев. Но достаточно ли этого чтобы его понять? (ИМХО, приводимый обычно исходный текст - намеренное усложнение простой вещи с целью уменьшить число строк программы). Но это отступление и пример некачественной документации. Документация может быть полезна, но наверное проблема не только и не столько в ней. Может она просто в ничем неоправданной сложности нынешнего ПО?
	Andy 10 Mar 2004 3:58 PM
2me: "В любой книжке по прикладному программированию написано чёрным по белому: прежде, чем что-то написать самостоятельно, попробуйте найти готовое решение. Дешевле получится. Не все любят книжки, конечно. Надо с собой воевать на эту тему :))." Хорошее дело - готовое решение. И дешёвое. Берёшь ты его и начинаешь использовать. Потом ставишь вокруг подпорки, чтобы баги(АКА фичи) этого решения обойти. Потом напильником по возможности дорабатываешь. И через полгода замечаешь, что девелоперы проектом уже почти не занимаются, а искл-но фиксят баги в подпорках и ищут пути обхода фич(АКА багов) сего готового решения чтобы заставить его хоть что-то полезное сделать кроме того, что в демках и сэмплах было. К счастью не всегда так бывает, но уж черезчур часто :(
	me - userinternet.com 10 Mar 2004 4:09 PM
>> К счастью не всегда так бывает, но уж черезчур часто Теоритически, патенты способны помочь в решении этой проблемы. Взять хотя бы тот факт, что исходники-то будут доступны - меняй не хочу. И разработчиков ждать не надо, если сильно припечёт. Действительность, правда, рушит все эти стройные теории - факт, увы.
	VicTor 10 Mar 2004 4:57 PM
2torvic: > Там где надо и хочется, там делают или заставляют делать. Там где не надо или не хотят, там не делают. Реально так дело и обстоит. С одним дополнением - там, где надо, приходится еще дополнительно обучать, ибо "пехотинец, молодой, необученый" (или как там у Хайнлайна).
	xacid 10 Mar 2004 8:48 PM
2all проект организовать можно и нужно попробовать но здесь нужно тщательно продумать организационные моменты кто будет координировать, кто будет принимать решения итд итп мне кажется пока что лучше было бы просто наладить какие то более менее специализированные на эту тему коммуникации для обмена опытом, идеями, кодом, а реализацией каждый пока что может заниматься и сам в сооствествии со своими представлениями к сожаления еще лично у меня есть проблема с ограниченностью ресурсов - в основном времени.... но это возможно когда нибудь изменится, буду надеяться ну и еще могу поделиться для начала в организации проекта своим кодом - JSP TagLib интеграции JDBC-баз данных с XSLT процессором для генерации отчётов и прочего сложного форматирования сложных запросов из баз данных как оказалось в своё время когда я этим вопросом занялся ничего подобного тому что мне было нужно не было в готовом виде не могу сказать что код идеален, но коекакие интересные возможности там реализованы... многоуровневые связанные вложенные запросы например (к любому JDBC-источнику, хоть к DBF...) аналогичную технологию я хотел бы реализовать на чём то более системном чем Java (на С++ а то и plain С например), но пока увы - времени на это не остаётся... всё уходит на выживание в агрессивной среде >Бьются, понятно, не один год. Тут такое дело. Если для системной области преобладают диалекты C, то для баз данных уже используют SQL (фактически мета язык), для обработки текстов perl и другие скриптовые языки. всё верно но если мы немного абстрагируемся от этих различий то что мы сможем увидеть? все исходные тексты - это всего лишь тексты ничто не мешает их генерировать правила генерации у каждой "цели" естественно разные но в этом то и должна состоять в данном случае формализация в формировании правил генерации кода по заданным структурным моделям задачи >Проблема объединить эти методы. Похоже, что невозможно в одной концепции удовлетворить потребности системщиков, бд-шников, настройщиков бух. проводок, и любителей записывать передачи по видеомагнитофону. Вернее, объединить можно, но язык получается раздутым до практической невозможности его использовать. нет, это не правильный подход - пихать всё в один "толстый" язык языка как такового вообще не должно быть - должен быть метаязык, а все используемые и создаваемые языки должны или быть языком предметной области задачи или быть языками реализации >Какие-то продвижки есть в C++ (generic programming, а не oop). Но все-равно такая фигня получается... а вот это имхо уже более правильный подход я имею ввиду шаблоны естественно что здесь еще очень много предстоит сделать но направление имхо верное реализовать бы систему гибких лёгких удобных многоцелевых шаблонов на базе XML - и можно уже начинать думать над следующими по очередности проблемами.... 2 Bulat Вы поконкретнее плиз, давайте, ссылки там или хотя бы просто названия методов или идей... прикладной телепатией на предмет оценки знаний собеседника мы все и так хорошо умеем заниматься... и, боюсь, что мы пока немного о разных вещах говорим я так понял Вы хотите полностью автоматизировать процесс разработки - для этого так или иначе потребуются методы искусственного интеллекта, типа доказательств теорем я же себе такой цели пока не ставлю - моя цель избавиться от рутины и целиком заниматься анализом, проектированием и прочим творчеством, то есть реализовать то что уже вполне можно реализовать, а уже потом может быть дойдет дело и до более изощренных технологий... но пока мне кажется и без искуственного интеллекта хватает нерешенных проблем в этой области
	___ 10 Mar 2004 10:06 PM
Ответ сторонникам патентования во главе с С.Середой: >В любой книжке по прикладному программированию написано чёрным по белому: прежде, чем что-то написать самостоятельно, попробуйте найти готовое решение. Количество кода все время увеличивается, а потребность в его написании - еще больше. Поиск готового решения может занять полжизни, и это касается не только Hello world, но и критических модулей проектов размером на десятки человеко-лет. В таких случаях может оказаться, что время (и деньги) потрачены совершенно зря. Например, ваяли конвертор формата RealAudio (не самая сложная задача), а тут оказывается, что формат этот не имеет права конвертировать никто. Или как в случае с 321 - наглядный пример нынешнего юридического беспредела. РАБОТУ У ЮРИСТОВ НУЖНО ОТНИМАТЬ!!! Свобода кода - это свобода слова. Чего вообще добивается С.Середа? Крупные проекты и так защищают патентами, если в них реализованы действительно уникальные специализированные методы. А если мелкие не защищают, значит это никому не нужно! Если это "баловство", кустарщина, то кустарей-то никто не преследует? Так нет, от каждого кустаря, занимающегося, например, резьбой по дереву, требуют, чтобы он убедился, что никто в мире такого на своих досках не вырезал! Не говоря уже о том, что перспективы метода массового производства в нашей отрасли весьма сомнительны... Крупные проекты, конечно, нужно проектировать (каламбур?). Но - на модульном уровне! Никакого описания типа "переменная а_302160 означает то-то и то-то"! Вместо этого - что-то вроде "модуль uDESEncrypt выполняет DES-шифрование рабочих данных приложения для сохранения в БД. Параметры командной строки обозначают то-то и то-то. На выходе выдается следующая информация: ...." - и так далее. В наше же время основной единицей проекта считается не модуль, а объект. И что он делает для вызывающих его объектов, тоже скрывается. Я не противник ООП, я противник злоупотребления этой концепцией. Объектный уровень требует бОльшей детализации, чем модульный, и проектировать его можно уже потом. И уже затем - реализация функций объектов. Это уже каждый разработчик, ответственный за модуль! Я уже не говорю, что один модуль, задачи которого определены на уровне "что", а не "как", должен писать ОДИН человек. Если это невозможно - значит проект плохо разделен на модули, и нуждается в реорганизации, т.е. данный модуль должен вызывать другие модули для выполнения каких-либо функций. В начале же каждого нормально написанного опенсурсного модуля всегда присутствует масса комментариев, описывающих его предназначение. Документировать все остальное смысла нет, т.к. модуль должен быть достаточно небольшого объема для понимания одним человеком, и для разбора по косточкам группой из 2-3 в случае выявления бага (не стоит и говорить, что определить бажный модуль при таком подходе проще простого). Больше всего меня бесит современная практика разбиения с++ кода на с и h, т.е. отделение заголовков структур от их реализации. Именно поэтому сишный код труднее для понимания, чем паскаль или васик. С этим тоже надо что-то делать. Таким образом, идея пост-объектного программирования в сокрытии самих объектов внутри модулей, т.е. в установлении прав доступа не только к свойствам и методам объектов, но и к самим объектам, и в доступе к ним через единый для всего модуля интерфейс ("командную строку").
	Bulat - rootbulat.f0.ru 11 Mar 2004 12:04 AM
>xacid: >2 Bulat >прикладной телепатией на предмет оценки знаний собеседника мы >все и так хорошо умеем заниматься... Я думал тут все собравшиеся - Дунканы Маклауды, а ведь всем известно что Дунканы Маклауды прекрасно владеют прикладной телепатией и иных способов обмена информацией не признают. :) >и, боюсь, что мы пока немного о разных вещах говорим >я так понял Вы хотите полностью автоматизировать процесс >разработки - для этого так или иначе потребуются методы >искусственного интеллекта, типа доказательств теорем >я же себе такой цели пока не ставлю - моя цель избавиться от >рутины и целиком заниматься анализом, проектированием и прочим >творчеством, то есть реализовать то что уже вполне можно >реализовать, а уже потом может быть дойдет дело и до более >изощренных технологий... но пока мне кажется и без >искуственного интеллекта хватает нерешенных проблем в этой >области Я здесь о трех направлениях писал (но вроде как разделял каждый раз): 1) документирование проектов (с этого все и началось, не так-ли ?) 2) code reusing (как, блин, это по русски-то сказать ?) и т.п. использование уже готовых блоков и создание только супер-блоков 3) доказательство корректности алгоритмов/программы. А то что Вам показалось в моих репликах это уже 4-ый пункт - AI и пр.- его я не имел ввиду вовсе. :) >Вы поконкретнее плиз, давайте, ссылки там или хотя бы просто >названия методов или идей... Да, да, постараюсь - сейчас просто некогда собрать (как всегда даже поспать не успеваю), но как ключевые слова по третьему пункту, например, на вскидку: computational logic (ну и соответственно результаты европейских и штатовских грантов на эту тему).
	Сергей Середа - serge_seredahotmail.com 11 Mar 2004 12:28 AM
2 ___: === Ответ сторонникам патентования во главе с С.Середой: === Мне просто неудобно перед Анатолием Шалыто. Вроде бы эта ветка была посвящена обругиванию именно его идей, а не моих ;-) Коротко отвечу. На самом деле, "кустарщикам" вообще бояться нечего: ну кто, скажите на милость, сможет узнать что Вы, даже преднамеренно, использовали запатентованное решение, если Вашей программой пользуется только заказчик и о самОм факте её написания практически никому не известно? Это если Вы станете распространять продукт широко, то поднимутся юридические вопросы. Плюс повторю для "особо внимательных" читателей: Я ПРОТИВ ПАТЕНТОВАНИЯ ФОРМАТОВ ФАЙЛОВ. Поэтому отстаньте от меня с Вашим RealAudio и GIF. А правовая грамотность никогда не мешает: "Незнание закона не освобождает от ответственности, знание - запросто" (с) С.Е.Ленц. А если техническое решение Вами описано и опубликовано, никто не сможет его запатентовать - противозаконно. Поэтому GNU был, есть и будет есть ;-) С уважением, Сергей Середа Движение "ПОтребитель" http://consumer.nm.ru http://cie.ase.md/~sereda
	Andy 11 Mar 2004 9:41 AM
2___: "Больше всего меня бесит современная практика разбиения с++ кода на с и h, т.е. отделение заголовков структур от их реализации. Именно поэтому сишный код труднее для понимания, чем паскаль или васик. С этим тоже надо что-то делать." Вы действительно считаете, что разделение таких понятий, как объявление интерфейса и его реализация - это плохо? И кому это труднее для понимания? Вам лично? Тогда ИМХО надо не забывать ставить! BTW, насколько я помню, в паскале успешно используются блоки interface и implementation, разве что помещаются они в одном и том же файле.
	Andy 11 Mar 2004 9:45 AM
вдогонку: "Таким образом, идея пост-объектного программирования..." что-то эта идея очень мне Ada напоминает... Или ещё аналог - pascal units.
	Сергей Середа - serge_seredahotmail.com 11 Mar 2004 10:55 AM
2 Andy: Скажу больше, если Вы пороетесь в VCL для Delphi, то увидите, что константы и объявления там вынесены в отдельные файлы, точно также как это принято у "СИонистов/наСИльников/СИшников". Windows.pas WinInet.pas WinSock.pas WinSpool.pas WinSvc.pas и ты ды и ты пы. А какое это отношение имеет к обсуждению? С уважением, Сергей Середа Движение "ПОтребитель"
	Andy 11 Mar 2004 11:11 AM
2Сергей Середа: "А какое это отношение имеет к обсуждению?" Ваша правда, никакого. Кроме того факта, что явное выделение констант, интерфейсов и т.п. само по себе, имхо, является в некотором роде документированием, т.е. программист в явном виде описывает структуру своих объектов, интерфейсы и проч. Если это ещё сопровождается толковыми комментариями, то такой заголовочник часто бывает полезнее иной документации. Не всегда, но довольно часто.
	me - userinternet.com 11 Mar 2004 11:41 AM
>> Больше всего меня бесит современная практика разбиения с++ кода на с и h Даже я знаю, что это сделано для ускорения компиляции. И никто не мешает, кстати, всё класть в cpp, полностью обходясь без h. >> Поиск готового решения может занять полжизни (задумчиво) Надо, наверное, запанентовать какой-нибудь алгоритм (метод, извините) поиска патентов. Может быть, даже успею раньше google... >> а тут оказывается, что формат этот не имеет права конвертировать никто. Как это никто не имеет права? На то он и патент, чтобы права у всех были. За деньги, конечно. >> Так нет, от каждого кустаря, занимающегося, например, резьбой по дереву, требуют, чтобы он убедился, что никто в мире такого на своих досках не вырезал! Если речь идёт о широком распространении (как уже сказал Сергей), то и сейчас (без патентования резьбы по дереву) общественность требует от мастера, чтобы он чужие картинки не передирал. Кстати, насколько я понял, Анатолий Шалыто в обсуждаемой статье сетует именно на то, что программирование сродни вырезанию до дереву: что получилось, то получилось. Это и правда как-то не особо здорово :)).
	me - userinternet.com 11 Mar 2004 11:43 AM
Типа, плавно возвращаемся к исходной теме :)).
	Хрю 11 Mar 2004 12:21 PM
2me: "...общественность требует от мастера, чтобы он чужие картинки не передирал. " Речь о том что его раельно в суд потащат, углядев в его каракулях загогулину, чем-то похожую на васину (патентованную). "...программирование сродни вырезанию до дереву: что получилось, то получилось. Это и правда как-то не особо здорово :)). " А не все виды человеческой деятельности можно (и нужно) "индустриализовывать". Вот музыка та же - поставили на поток - получилась попса. Медицина - ставим на поток - получаем советскую поликлинику. Архитектура... Журналистика и писательство разное и т.п. Отчего же программеров все так страстно желают превратить в рабочих у конвеера. Чтоб платить поменьше? А потом "менеджеры" расстраиваются что каменный цветок не выходит несмотря ни на какое слабительное...
	me - userinternet.com 11 Mar 2004 1:16 PM
>> Отчего же программеров все так страстно желают превратить в рабочих у конвеера А от того, что растёт количество "профессионалов" кивающих на плохой UML, плохой C++, плохую жаву и на много чего ещё плохого, забывая о том, что всё это - лишь средства, выбирать которые должен сам программист. Видишь ли, если работник перекладывает ответственность на других, то ему платят меньше, а тому, кто её принимает - больше. Так заведено. Вообще, если отбросить заявления господина Шалыто о "мальчиках" (в отместку его уже назвали "теоретиком"), то следует ему сказать-таки спасибо за то, что дисциплинирует своих студентов. Ни умение писать документацию (хотя знание русского языка не помешает, само собой), ни строгое соблюдение "автоматного программирования", ни умение писать "танчики" не пригодится им никогда (вряд ли пригодится - менее категоричная формулировка; относится к танчикам). Зато умение относиться к своему делу с максимальной ответственностью очень ценится в программеских коллективах. ЗЫ: Пафосно как-то получилось :)) ЗЗЫ: ИТ - уже давно индустрия, Хрю. Спускайся к нам, на землю. Из-за облаков плохо видно.
	me - userinternet.com 11 Mar 2004 1:28 PM
>> Речь о том что его раельно в суд потащат, углядев в его каракулях загогулину, чем-то похожую на васину Плагиатом обычно называют сюжетный ход (например), скопированный из другого произведения, а не совпадение имён. И - ещё раз - загогулины не патентуют. Патентуют неочевидное (вот к этому термину у меня больше всего претензий) сочетание загогулин.
	Сергей Середа - serge_seredahotmail.com 11 Mar 2004 1:30 PM
2 Хрю: Ну поймите же, наконец, что программирование - НЕ ИСКУССТВО, А ТЕХНОЛОГИЯ!!! Повторю в очередной раз, умножение и деление римских чисел было искусством, обучиться которому могли лишь немногие. С арабскими же цифрами эти операции по силам и ребёнку. И не потому, что ребёнок, занющий арабские цифры, умнее римлянина, а потому, что римские цифры не позволяли проделывать над ними операции произведения и деления. То же сейчас и в "искусстве программирования". Не более того. С уважением, Сергей Середа Движение "ПОтребитель"
	Andy 11 Mar 2004 1:37 PM
2Сергей Середа: А "имхо" где? Конечно, кое-какие технологии наработаны, но всё равно выходит как с питанием: используете технологию - получаете Макдональдс, а нужно что-то эксклюзивное - к шеф-повару. Причём существуют не только эти две градации, но весь спектр, и все существуют и на каждого свой спрос.
	Хрю 11 Mar 2004 1:44 PM
2me: "ИТ - уже давно индустрия, Хрю." Нет. К счастью (для кого-то м.б. к сожалению). Более того - все наблюденные лично мною попытки делать проекты в индустриальной манере рождали таааких уродцев, что ни в сказке сказать... Причем в весьма пальцатых софтовых фирмах. На среднерусской возвышенности, я имею ввиду. А у вас, на Марсе, как с этим? ;) Кстати, слово "индустриальный" в нашей отрасти правильно писать через тире: "индус-триальный" (indus trial) ;) "Спускайся к нам, на землю. Из-за облаков плохо видно. " Эт ты кажись ориентировочку потерял :) "Патентуют неочевидное (вот к этому термину у меня больше всего претензий) сочетание загогулин." Вот-вот. Неочевидно патентуют неочевидное. И не очевидно не попадешь ли ты (лично или фирма) под неочевидную тебе (но очевидную вражеским юристам) неочевидность. Поэтому когда будешь придумывать и реализоввывать решения ты будешь должен... Ох, ладно, я уже это столько раз сказал... Неужели неочевидно? :)
	Хрю 11 Mar 2004 1:56 PM
2Сергей Середа: "Ну поймите же, наконец, что программирование - НЕ ИСКУССТВО, А ТЕХНОЛОГИЯ!!!" Ну поймите же и вы что это И технология И искусство. Видимо вопрос терминологический. Вы желаете под "программированием" понимать тупой кодинг? Тогда вы правы. Но отстали от жизни. Собственно кодинг год от года вытесняется именно технологиями и остается компонента которую несколько пафосно можно назвать искусством.
	me - userinternet.com 11 Mar 2004 2:23 PM
>> Неужели не очевидно? Было бы очевидно, если бы патентного права вообще не было. >> все наблюденные лично мною попытки делать проекты в индустриальной манере рождали таааких уродцев Не надо думать, что результаты "творчества" много лучше. Такое же дерьмо :)). >> поймите же и вы что это И технология, И искусство Вот-вот. Так везде, понимаешь? И с песнями, и со строительством, и с мерседесами.
	me - userinternet.com 11 Mar 2004 2:25 PM
ИТ - индустрия с того момента, как появилась теория построения компиляторов.
	Хрю 11 Mar 2004 2:30 PM
2me: "ИТ - индустрия с того момента, как появилась теория построения компиляторов." А музыка - индустрия с того момента как появилась нотная запись? Логично?
	VicTor 11 Mar 2004 2:31 PM
2 Сергей Середа, Хрю, me: Ну, традиционный-то спор с середины прошлого века был на тему: "Программирование - это наука, искусство или технология?"
	Хрю 11 Mar 2004 2:43 PM
2me: "Было бы очевидно, если бы патентного права вообще не было." Прямой вопрос. Ты (без ансамбля или с ансамблем), работая на фирму или на себя, решаешь задачу. Нашел решение. Занес руки над клавой. И тут предательская мыслишка "А не запатентовал ли это кто-нить?". Твои действия? Не абстрактного прога а твои, лично. Ответь, плз.
	Хрю 11 Mar 2004 3:36 PM
2VicTor: "Ну, традиционный-то спор с середины прошлого века был на тему: "Программирование - это наука, искусство или технология?"" А наука, похоже, сошла с дистанции :) Дыхалки не хватило :) Подтверждение - статья с которой ве началось
	me - userinternet.com 11 Mar 2004 3:41 PM
>> музыка - индустрия с того момента как появилась нотная запись? Нотная запись больше похожа на язык программирования, чем на компилятор. Компилятором в данном случае выступает сам инструмент (который патентуется, кстати, если он уж очень выдающийся). >> Прямой вопрос "Предательская" мыслишка появляется у меня _перед_ словосочетанием "Нашёл решение". Ищу в реестре патентов мою задачу. Может, убью на это денёк, но запомню то, что мне встречалось в процессе поиска (из неподходящих вариантов). Мало ли что в хозяйстве пригодится. Если найду, то поставлю заказчика или фирму, в которой работаю, в известность (они же будут платить). Если не найду или заказчик скажет, что это не подходит ему "по понятиям", то буду искать решение, отличное от патентованного (заказчик заплатит больше, чем заплатил бы за патент). Когда найду - запатентую, если решение окажется уж очень хорошим для использования его другими людьми.
	me - userinternet.com 11 Mar 2004 3:52 PM
Хрю, для справки: да, я знаю, что ПО отличается от объектов материального мира и отличается очень сильно; да, программисты должны быть в первую очередь проектировщиками (то есть такими инженерами, которые думают о последствиях того или иного конструктивного решения); да, патенты не совсем прозрачны для понимания простыми людьми. И что?
	Хрю 11 Mar 2004 3:54 PM
2me: "Может, убью на это денёк...". :))) щас.... "...то буду искать решение, отличное от патентованного.." Уверен что не зациклишься? :))) "Когда найду - запатентую, если решение окажется..." Не "если" а _обязательно_. И денежку _обязательно_. Иначе запатентует другой. И тебя в суд (ну фирму товою) Что и требовалось доказать.
	me - userinternet.com 11 Mar 2004 4:10 PM
"Статья 7. Автор изобретения, полезной модели, промышленного образца 1. Автором изобретения, полезной модели, промышленного образца признается физическое лицо, творческим трудом которого они созданы." (С) Патентный Закон РФ :)) Думаю, что вполне достаточно опубликовать решение и никто уже его не запатентует. Впрочем, это тоже относится к проблемам патентования, согласен.
	me - userinternet.com 11 Mar 2004 4:12 PM
И вообще, Хрю, предлагаю закончить обсуждение патентов здесь :)). Всё равно меня не переубедить, да и тебя тоже. А между тем, весь этот базар явно не по теме. Вот напишет Сергей Середа ещё что-нибудь про патенты - там и обсудим.
	torvic 11 Mar 2004 4:40 PM
Заодно давайте закроем тему программирование - это искусство или ремесло. Вопрос этот решается строго индивидуально. Программирование - ремесло, которое становится искусством в тот момент, когда в тебе просыпается Творец, т.е. когда ты начинаешь испытывать эстетические переживания, в обиходе называемые муками творчества. Это не я сказал, кто-то из великих.
	me - userinternet.com 11 Mar 2004 5:01 PM
Согласен, пора бы уже на господина Шалыто побычить :)).
	glassy 11 Mar 2004 5:09 PM
редкое обсуждение перелетит через 300-ю отметку всего за 7 дней... :)
	Дмитрий 11 Mar 2004 9:50 PM
2 Хрю, me: копать вашу мать, вы еще здесь. Не надоело х...м болтать на форуме? :-)
	Сергей Середа - serge_seredahotmail.com 12 Mar 2004 3:39 PM
2 torvic: === Заодно давайте закроем тему программирование - это искусство или ремесло. Вопрос этот решается строго индивидуально. Программирование - ремесло, которое становится искусством в тот момент, когда в тебе просыпается Творец, т.е. когда ты начинаешь испытывать эстетические переживания, в обиходе называемые муками творчества. === Так ведь это - принципиальный вопрос! Если программирование (разработка ПО) это искусство, то всё, о чём пишет Анатолий Шалыто не имеет никакого смысла. Какие претензии по проектировани и документированию можно предъявить художнику, скульптору, литератору? (Архитектура, кстати, не искусство, а технология, если кто не в курсе). А вот если программирование - процесс технологический, то всё становится на свои места. 2 Andy: === 2Сергей Середа: А "имхо" где? Конечно, кое-какие технологии наработаны, но всё равно выходит как с питанием: используете технологию - получаете Макдональдс, а нужно что-то эксклюзивное - к шеф-повару. Причём существуют не только эти две градации, но весь спектр, и все существуют и на каждого свой спрос. === Нет "имхо", потому что это не просто моё личное мнение. А чтобы решить этот вопрос, необходимо просто сформулировать критерии, по которым можно разделить искусство и технологии (науку не трогаем). Я это сделал, народу не понравилось. Я просто прошу: сделайте это сами. Возможно у Вас получится лучше. Пока всё, что написал Хрю, torvic и Вы применимо и к технологам, работающим с механизмами/электроникой и т.п. Даже в бОльшей степени, чем к программистам. Так что же, теперь объявим технологию "искусством", в талантливых технологах тоже "просыпается Творец". И что с того? А промышленный дизайнер кто? Дайте критерии (что искусство, а что - технология) и мы разберёмся с программированием. А иначе это будет просто бесполезный и бессмысленный трёп. С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 12 Mar 2004 3:50 PM
2 Andy II: === 2Сергей Середа: А "имхо" где? Конечно, кое-какие технологии наработаны, но всё равно выходит как с питанием: используете технологию - получаете Макдональдс, а нужно что-то эксклюзивное - к шеф-повару. Причём существуют не только эти две градации, но весь спектр, и все существуют и на каждого свой спрос. === А колбасу Вы, очевидно, тоже "эксклюзивную" кушаете? Всё, что продаётся в продовольственных магазинах - продукция пищепрома, производимая по жёсткой технологии, проверенная на качество, происхождение, безопасность и т.д. и т.п. Не дай Бог, чтобы случилось, что пищевые продукты станут производить, как компьютерные программы!!! Я - против "искусства" производства пищевых продуктов! Правда, тогда проблемы перенаселения не будет - все передОхнут... С уважением, Сергей Середа Движение "ПОтребитель"
	Прохожий 12 Mar 2004 5:10 PM
Обратно к статье :-) Ту развёлся та-а-акой флейм. А не совсем понятно почему. На мой взгляд, автору, прежде чем писать остальной текст статьи следовало бы сделать лирическое вступление о том, ЧТО такое проектная документация в его понимании и каковы цели ее создания. Тогда, опять же на мой взгляд, обсуждение было бы направлено в более конструктивное русло, нежели сейчас. Хочу добавить и свою копеечку в общую копилку мнений по поводу искусства и технологии. По-моему, технология - это то, что базируется на полученном коллективном или индивидуальном опыте. Искусство - это нечто новое и неизвестное. То есть, например, использование какого-либо известного алгоритмав стандартной ситуации - это технология, изобретение нового алгоритма - это искусство.
	Прохожий 12 Mar 2004 5:23 PM
Продолжая размышления вслух. Вот несколько причин, когда необходимо создавать документацию: 1. Координации программистов в сложном или долгоиграющем проекте. Иначе получится "кто в лес, кто по дрова". 2. Требование закакзчика, за которое он готов платить. С этим, я думаю, всё понятно :-) В остальных случаях разработка проектной документации целиком и полностью ложится на совесть программистов. Думаю, "теоретики" согласятся, что для того, чтобы забить гвоздь совсем не обязательно при этом описывать как это нужно сделать, особенно, когда делаешь это действие сам, а не поручаешь кому-нибудь неопытному.
	Прохожий 12 Mar 2004 5:40 PM
Еще о деньгах хочется поразмышлять. Почему-то все забывают, что деньги - это не цель, а средство. Средство для удовлетворения потребностей (в выживании, амбициях и т.д.). Почему ум стали мерять деньгами? Если уж что и мерять деньгами, так это амбициозность человека. И не более. Нельзя не согласиться, что для того, чтобы заработать много денег надо и ума немножко иметь. Но ум это далеко не всегда определяющий фактор. Вспомните фильм "Форест Гамп".
	Сергей Середа - serge_seredahotmail.com 12 Mar 2004 8:28 PM
2 Прохожий: По теме статьи, соглашусь с Вами. === Искусство - это нечто новое и неизвестное. То есть, например, использование какого-либо известного алгоритмав стандартной ситуации - это технология, изобретение нового алгоритма - это искусство. === Тогда получается, что изобретательская деятельность - искусство. Доказательству того, что это не так, посвящены все книги Генриха Сауловича Альтшуллера (ТРИЗ). Можете глянуть статью: "О психологии изобретательского творчества" http://www.bugtraq.ru/library/misc/invent.html (я порекомендовал её разместить на BugTraq). И "НАУКА ИЗОБРЕТАТЬ" http://www.altshuller.ru/triz15.asp Так что просто новизна+неизвестность "не катит". (Надеюсь, ни у кого не хватит глупости спорить с мнением Альтшуллера). Давайте дальше. Что ещё можно придумать в качестве критерия? (Я не издеваюсь, просто предлагаю продолжить обсуждение.) С уважением, Сергей Середа Движение "ПОтребитель"
	Шалыто 12 Mar 2004 9:43 PM
По результатам нашего обсуждения я внес изменения в текст статьи, добавив, в частности, два раздела, один из которых с рисунком, который многое что проясняет! Посмотрите.
	Геннадий Шушпанов 13 Mar 2004 12:04 AM
2 Шалыто === И последнее. Если кто-то из читателей считает, что в рассматриваемом вопросе все обстоит не совсем так или совсем не так, как это описано выше, автор рекомендует осуществить руководство, по крайней мере, двумя десятками проектов любых студентов любого университета страны, добившись от них проектной документации с качеством не ниже, чем у наших проектов. Я думаю, что после этого, как говорят студенты, «мало не покажется». === Я тоже думаю, что если бы автор хоть раз попробовал бы довести до завершения хотя бы один комерческий программный проект, "...скажем на смехотворную сумму в $1000", то ему "как говорят студенты, «мало не покажется»". Тогда мысли типа "А просто программировать много ума не надо - это сегодня уже умеют многие!" приходили бы пореже.
	Шалыто -> Геннадий Шушпанов 13 Mar 2004 2:16 PM
Каждому свое. Это первое. А во вторых, я служу профессором каждый день только с 18 часов, а до этого времени занимаюсь проектированием ответственных систем, так что мне есть с чем сравнивать. И я знаю как документируются разные проекты. (см. рисунок в моей статье и комментарии к нему)
	Шалыто -> Прохожему 13 Mar 2004 7:05 PM
Все очень просто! Не надо определять, что я понимаю под документацией,а достаточно посмотреть на указанном в статье моем сайте на саму документацию. Может быть я и теоретик, но я это говорю не голословно, а на основе выполнения учебных проектов с очень сильными студентами, многие из которых работают программистами.
	Шалыто 13 Mar 2004 7:21 PM
Спор про искусство и науку бессмысленный - вот, что сказано во введении в книге Брауде Э. Технология разработки программного обеспечения. СПб.: Питер,2004 Технология разработки программных продуктов - это по определению одна из областей инженерной науки. На стр.41 сказано: разработка ПО является очень молодой и быстро развивающейся отраслью инженерной науки! В Англии разработчикам программ присваивают звание инженера. Итак - это инженерная наука со всеми вытекающими из этого последствиями, о чем неоднократно говорится в моей статье. Что спорить?
	Шалыто - Хрю 13 Mar 2004 7:26 PM
Перечитал свою статью - ни слова не исключил, только еще кое-чего добавил. Все, что у меня написано все выстрадано и все правда, нравится ли Вам это или нет!
	Шалыто - 13 Mar 2004 7:40 PM
Много Вы знаете, что пригодится мальчикам, а что нет! Особенно всем хорошо известно, что танчики по жизни не нужны! А то, что на работу в Майкрософт не берут, если недостаточно эффективно нерекурсивный обход двоичного дереьв сделаешь. Это как? Эта задача очень практическая? А вы все про танчики! Я начинаю работу по выпуску студентами проектной документации на визуализаторы алгоритмов типа обхода деревьев, так как это, в конце концов, оказывается очень практичным.
	AT - 220220pager.icq.com 14 Mar 2004 1:33 AM
"Почему-то все забывают, что деньги - это не цель, а средство. " Это и не цель и даже не средство - а всего лишь единица обмена того что сделал сам на то что делают другие. И до тех пор пока пользу ты приносишь кому-то в полной мере имеешь право требовать чтобы и тебе полезное что-то делали. А на счет того что пригодиться или не пригодиться - то все мы знаем очень мало. Как раз чаще всего (по закону подлости) необходимо то чему не учили и самому думать приходиться. Вот судя по результатам вашего университета надеюсь что вы таки учите студентов думать, а не тупо писать документацию с помощью какой-то одной технологии или реализовывать ограниченный набор олимпиадных алгоритмов. Если бы студент/выпускник/будущий сотрудник софтверной фирмы или писатель открытого ПО умел бы думать и принимать решения - его бы тут в форумах не приходилось бы уговаривать следовать какой-то технологии. Сам бы понял зачем, почему, какие преимущества и недостатки и приминимо ли в его конкретной ситуации.
	Геннадий Шушпанов 14 Mar 2004 1:15 PM
2 Шалыто === И я знаю как документируются разные проекты. (см. рисунок в моей статье и комментарии к нему) === Кто Вам сказал это? "... это Вас кто-то Вас обманул!". (см. рисунок к Вашей статье и коментарии к нему) :) Предвидя Ваше предложение почитать документы на http://is.ifmo.ru, отвечаю -- почитал. Они лишь укрепили меня в моем мнении.
	me - userinternet.com 15 Mar 2004 12:15 PM
>> Много Вы знаете, что пригодится мальчикам, а что нет! Знаю, знаю. Кроме того, хорошо знаю, зачем в МС задают всякие "глупые" задачки. И не только в МС. >> Это как? Эта задача очень практическая? Вполне. Вот только задают её вовсе не для того, что они сами не знают.
	me - userinternet.com 15 Mar 2004 12:19 PM
>> Я начинаю работу по выпуску студентами проектной документации на визуализаторы алгоритмов типа обхода деревьев Студентам надо иногда давать почитать книжки, а не только посмотреть картинки. Кстати, а если бы на эти "визуализаторы" уже была необходимая документация, то, я полагаю, студентов нечему было бы учить? :)) Не самим же алгоритмам, в самом деле, правда?
	me - userinternet.com 15 Mar 2004 12:20 PM
вовсе не для того -> вовсе не от того
	А.Хохлов 15 Mar 2004 2:15 PM
>А то, что на работу в Майкрософт не берут, если недостаточно эффективно нерекурсивный обход двоичного дереьв сделаешь. И как это соотносится с не слишком эффективными продуктами MS?
	me - userinternet.com 15 Mar 2004 3:05 PM
>> И как это соотносится с не слишком эффективными продуктами MS? Провокатор, блин :))
	Прохожий 15 Mar 2004 4:18 PM
Всем. Да что вы к словам придираетесь-то? Человек высказал свою мысль. В принципе она неплоха. Имеется в ней здравое рациональное зерно. Документировать, порою, бывает жизненно необходимо, иначе такого можно наваять... Сергею Середе --- Не сотвори себе кумира :-). Это я про Альтшуллера и ваше к нему отношение. Прочитал его статью. Впрочем о ТРИЗ я и раньше слышал и кое-что читал. Ежели немного расширить и углУбить :-) мнение Альтшуллера, то получится, что любой вид деятельности - это не искусство. Везде всё сводится к пробам и ошибкам. И к "расшатыванию" привычных психических шаблонов. Если добавить к этой технологии фактор случайности, то вот вам и будет искусство в чистом виде.
	Прохожий 15 Mar 2004 4:27 PM
2 AT Вобще-то деньги - это именно средство для достижения цели. Вы сами это можете осознать, когда зададитесь себе вопросом: а зачем, собственно, они нужны? Ваш ответ: для обмена результата своего труда на чужой. Продолжим опрос: а зачем вы трудитесь? Единица обмена, как вы выразились, это и есть средство. Ибо ПОСРЕДСТВОМ денег вы получаете что-то ещё.
	Прохожий 15 Mar 2004 4:34 PM
Шалыто --- Все очень просто! Не надо определять, что я понимаю под документацией,а достаточно посмотреть на указанном в статье моем сайте на саму документацию. --- Сама документация на вашем сайте - это типа реализации какого-либо алгоритма на каком-нибудь алгоритмическом языке. То есть она очень конкретна. Неплохо было бы, всё-таки, более точнее определить, что такое проектная документация в вашем понимании по отношению к более сложным проектам. Ибо не всегда, мне кажется, можно определить программу в терминах только автоматов. А вы, насколько я понял, именно эту идею (программирование с помощью конечных автоматов) проталкиваете в массы. Или я не прав ?
	Прохожий 15 Mar 2004 4:45 PM
Шалыто --- Вы в статье пишете, что картины создаются без проектной документации. Вобще-то она имеется. В виде всяких там набросков, эскизов и т.п. "черновиков" :-) Можно сказать, что проектная документация присутствует практически всегда и везде, только не обязательно в явном виде :-).
	А.Хохлов 15 Mar 2004 4:51 PM
2me Маленький вопрос - какова минимальная конфигурация машины, на которой Win2K перестает действовать на нервы? PS. Дело не только в MS - он в этом не первый (но и не последний). Просто от фирмы такого масштаба хотелось бы большего...
	Шалыто - Прохожему 15 Mar 2004 4:56 PM
На учебных проектах я формирую различные подходы к автоматному проектированию программ.
	me - userinternet.com 15 Mar 2004 5:25 PM
>> какова минимальная конфигурация машины, на которой Win2K перестает действовать на нервы? Боюсь, что я за такой машинкой ещё не сидел никогда :)). Но, однако, смею утверждать, что медленнее можно было сделать: как в линуксе, например :)). К тому же, от версии к версии винды становятся заметно быстрее. Думаю, это напрямую связано с появлением в МС выпускников господина Шалыто :))).
	me - userinternet.com 15 Mar 2004 5:27 PM
>> На учебных проектах я формирую различные подходы к автоматному проектированию программ. Надеюсь, компиляторы для танчиков "мальчики" уже умеют писать?
	Mr.Bool - mr.boolrambler.ru 15 Mar 2004 6:03 PM
to me: >Маленький вопрос - какова минимальная конфигурация машины, на >которой Win2K перестает действовать на нервы? Да не переживайте Вы так, как выйдет Longhorn так придётся делать upgrade по любому (кто хочет Longhorn :0) так как там "жрущий" .NET будет "out of the box" :0)
	Dmitry 15 Mar 2004 6:19 PM
Всем, кто пытается разобраться во взаимоотношениях искусства, науки и ремесла рекомендую прочитать замечательную книгу Р. Пирсига "Дзен и искусство ухода за мотоциклом" (если кто не читал, конечно). Там живо и интересно излагается целостная философская концепция Качества, а искусство, наука и ремесло обсуждаются как некие его проекции. После прочтения многие вопросы отпадут сами собой, хотя многие и возникнут :)
	А.Хохлов 15 Mar 2004 6:21 PM
2me Почему-то осталось впечатление, что самой быстрой системой MS была NT 3.51. 2Mr.Bool Это в будущем, у нынешней Java аппетит тоже не маленький...
	Хрю 15 Mar 2004 7:13 PM
2А.Хохлов: "Почему-то осталось впечатление, что самой быстрой системой MS была NT 3.51." А самым медленным пользователем А.Хохлов :))) Сорри за невольный наезд, но ... будьте осторожнее на поворотах :).
	Шалыто - me 15 Mar 2004 7:31 PM
Вы хоть приблизительно понимаете,что такое стать призером чемпионата МИРА по программированию.Когда поймете я думаю стеб окончится! Очень в России не любят чужих успехов!
	Прохожий 15 Mar 2004 7:37 PM
Шалыто --- На учебных проектах я формирую различные подходы к автоматному проектированию программ. --- Это всё понятно. Но где же всё-таки ваше видение, что такое проектная документация? Статью вы написали о пользе этой самой документации. Но что это такое не объясняете. Здесь на форуме уже несколько точек зрения прозвучало по поводу проектной документации. Одни утверждают, что это только скелет программы, какие-то архитектурные особенности. Другие (и вы в том числе, судя по работам ваших студентов) - что это модель поведения автоматов, составляющих программу. Но, согласитесь, что это очень узкий взгляд на мир ПО. Ведь современное программное обеспечение - это не только алгоритмы. Это еще обрабатываемые данные, пользовательский интерфейс. Может еще чего упустил.
	Прохожий 15 Mar 2004 7:42 PM
2 Dmitry А вкратце суть пересказать можете этой книги? Хотя бы ту часть, что касается искусства?
	AT - 220220pager.icq.com 15 Mar 2004 8:16 PM
Шалыто: Прекрастно понимаю как стать призером ;o)) Грамоты и дипломы я уже на вес стал мерять - пол-кило уже :o) Только это ничего не доказывает. Я уже было сказал - решать ограниченный и схожий набор задач не означает уметь думать. К примеру однажды на Всеукраинской олимпиаде было дана задача с ошибкой в авторском решении. Как оказалось - никто из золотых призеров международной не смог ее решить, никто из жури не смог решить новую задачу с ошибкой, точно также как и все кроме одного участника. В условиях ограниченного времени им было найдено решение на 7 рукописных страницах выкладок. За что он дополнительно к диплому 2 степени и получил спец-приз. А 2 степени он оказался пому как некоторые специфические теоремы на которые были основанны другие задачи запихать в голову ему не успели в школе. Угадайте кто это был ? Давайте теперь послушаем про стеб ?
	AT - 220220pager.icq.com 15 Mar 2004 8:31 PM
Прохожий: Деньги нужны для того чтобы я не сам выращивал помидоры на своем участке, а пользовался результатом более продуктивных колхозников и фермеров. Точно также фермеры и колхозники когда им надо посчитать прибыль, обороты, налоги, и все остальное пользовались бы услугами опытного бухгалтера, а вот бухгалтер пользовался моими результатами. Думаю ясно зачем они мне ?? В случае если же бухгалтер сможет неограниченно пользоваться моими результатами - то дисбаланс получаеться однако.
	me - userinternet.com 15 Mar 2004 9:28 PM
>> Когда поймете я думаю стеб окончится! Я нахожу некоторую разницу между подходами к своей деятельности: "главное - не победа, а участие" и "наша цель - коммунизм". С первым обычно на работу не берут и мнение не слушают. Главное - цель и цена.
	Прохожий 16 Mar 2004 10:21 AM
2 AT Уходя далеко от темы. Деньги вам нужны, для того чтобы: а) выжить; б) получать удовольствия от жизни. А совсем не для того, чтобы выращивать или не выращивать помидоры. Или налоги считать. Хотя, если эти задачи входят в стратегию вашего выживания, то и за этим тоже. Если денег вам хватает на пункт а), то остальное количество денег, которое вы тратите на пункт б) зависит уже только от ваших амбиций. В любом случае вы достигаете ПОСРЕДСТВОМ денег две цели: вы выживаете, и вы получаете от жизни удовольствие. Извиняюсь за обсуждение не совсем по теме.
	Прохожий 16 Mar 2004 10:27 AM
2 AT Ссылка, приведенная вами - это не совсем по теме, даже совсем не по теме. Это скорее тонкий намёк в адрес Шалыто. То бишь переход на личности.
	Dmitry 16 Mar 2004 11:48 AM
>А вкратце суть пересказать можете этой книги? Хотя бы ту часть, что касается искусства? Вы знаете, не возьму на себя такую смелость :) Посмотрите хотя бы здесь: http://www.russ.ru/krug/vybor/20020522.html Вот самая известная цитата: "Будда, Божество с тем же удобством расположился в цепях цифрового компьютера, или коробке передач мотоцикла, что и на горной вершине или в лепестках цветка. Думать иначе означает унижать Будду - что равносильно унижению самого себя"
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 11:56 AM
2 Dmitry: Это в смысле: "Хари цепи, хари рама, заводи скорей Харлей"? :-)))
	Andy 16 Mar 2004 11:58 AM
2Сергей Середа: Дело в том, что Коран реально работает уже более полутора тысяч лет, миллионы людей во всём мире от эффективности Корана просто в шоке. Следовательно, Магомет прав. Но ещё дело в том, что Библия реально работает уже более двух тысяч лет, миллионы людей во всём мире от эффективности Библии просто в шоке. Следовательно, Христос прав. Но ещё дело в том, что Тора реально работает уже более двух с половиной тысяч лет, миллионы людей во всём мире от эффективности Торы просто в шоке. Следовательно, Моисей прав. <disclaimer: всё вышенаписанное сказано мною без малейшего оттенка иронии, с наибольшим уважением к упомянутым религиям и личностям.>
	Dmitry 16 Mar 2004 12:22 PM
>Это в смысле: "Хари цепи, хари рама, заводи скорей Харлей"? :-))) Нет. Просто в этой книге я нашел внятно изложенное подтверждение той мысли, что творчество и искусство вещи далеко не тождественные, творчество - не прерогатива людей так называемых "свободных профессий" и программист, да и человек любой другой профессии, может (и должен) заниматься творчеством. Как бы нас не пытались убедить в обратном сторонники конвейерного подхода.
	xacid 16 Mar 2004 3:30 PM
2Andy >Дело в том, что Коран реально работает уже более полутора тысяч.. >Но ещё дело в том, что Библия реально работает уже более двух.. >Но ещё дело в том, что Тора реально работает уже более двух с... Вам кажется что здесь есть какое-то противоречие? В чём именно?
	Прохожий 16 Mar 2004 3:31 PM
2 Сергей Середа Если вы не поняли, то наезд был не на ТРИЗ. А на ваше взгляд на Альтшуллера как истину в последней инстанции. Это, во-первых. Во-вторых, речь не о ТРИЗ шла, а об искусстве и его отличии от прочей человеческой деятельности.
	Andy 16 Mar 2004 5:26 PM
2xacid: "Вам кажется что здесь есть какое-то противоречие?" Речь здесь вообще не об этом.
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 5:48 PM
2 Прохожий: Так я о том и говорю, что Вы, голосистые ребята, не представляете себе на самом деле, что такое искусство, что такое наука, а что такое техническое творчество. Доказательство - никто не смог сформулировать критерий, по которому можно отнести произвольную деятельность к одной из этих сфер. Но на бас пытаетесь брать. А Альтшуллера я воспринимаю, как дОлжно. Да и воспринимаю я не Альтшуллера а ТРИЗовский образ мышления. Просто ТРИЗ сам по себе является доказательством того, что изобретательство - никакое не искусство, а техническое творчество. Что не нужно "родиться изобретателем" (как нужно родиться композитором), изобретательству можно научить и ученика младших классов и он даст сто очков вперёд "родившемуся изобретателем", т.к. будет использовать научный метод, а не "лошадинное чутьё". А я, всего-навсего, распространяю ТРИЗовский подход на ПО. И результаты моих исследований показывают, что это верно. P.S. А Вы ни кого не воспринимаете как истину в последней инстанции? Как насчёт Ньютона, Ампера, Эйнштейна? Я имею ввиду в области действия открытых ими законов. Не пробовали взлететь "аки птица"? Не получается? К чему бы это? С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 5:54 PM
2 Dmitry: === Просто в этой книге я нашел внятно изложенное подтверждение той мысли, что творчество и искусство вещи далеко не тождественные, творчество - не прерогатива людей так называемых "свободных профессий" и программист, да и человек любой другой профессии, может (и должен) заниматься творчеством. === Дорогой Вы наш! Так и я о том же! Ну нет такого вида человеческой деятельности, где можно обойтись без творчества! Даже на том самом ненавидимом Вами конвейере! Человек - такая зверюга, что без творчества не может. НО ЭТО НИКОИМ ОБРАЗОМ НЕ ГОВОРИТ О ТОМ, ЧТО ПРОГРАММИРОВАНИЕ - ИСКУССТВО!!! ПРОГРАММИРОВАНИЕ ЭТО ТЕХНИЧЕСКОЕ ТВОРЧЕСТВО!!! === Как бы нас не пытались убедить в обратном сторонники конвейерного подхода. === Кстати. Очень интересно, что же Вы понимаете под "конвейерным подходом" и вредом от него. К слову сказать, благодаря изобретению конвейера произошла НТР и мы с Вами имеем все удобства не во дворе, а дома. Плюс, все промышленные товары производятся на конвейерных линиях. Более прогрессивными являются только роторные линии, разработанные в российском ВПК. Так чем же Вам так не полюбился "конвейерный подход", извольте поведать нам? С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 6:09 PM
2 Andy: Коран, Библия, Тора, Веды и др. - собрания мыслей и изречений, описывающие каждый свою отдельную концепцию религиозного мировоззрения. Они могут существовать сотни и тысячи лет, но их роль сугубо социальна. Они не могут сами по себе способствовать или препятствовать решению технических задач, так как находятся в совершенно иной плоскости. Кроме того, очевидно, под словом "работают" Вы подразумевали, что у этих учений до настоящего времени есть последователи. Это так, но к нашему вопросу сей факт не имеет ни малейшего отношения. Религия оказывает позитивное влияние на общество и является одним из этнообразующих факторов, но к развитию техники она имела отношение (негативное) веке в XVII, с тех пор никакой связи нет. И мусульмане и иудеи и католики и православные и индуисты и все остальные совершенно одинаково решают технические задачи по единой методологии (кстати, очень часто с использованием ТРИЗ). Так что, как не пытался, а найти смысл в Вашей реплике мне так и не удалось. Следовательно, приходится отнести её к обычному софизму, т.е. не имеющему смысла доводу, предназначенному для создания у окружающих впечатления о наличии аргумента в споре. С уважением, Сергей Середа Движение "ПОтребитель"
	Хрю 16 Mar 2004 6:12 PM
2Сергей Середа: "А я, всего-навсего, распространяю ТРИЗовский подход на ПО. И результаты моих исследований показывают, что это верно." Какие? Нет, серьезно. Это очень интересно.
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 7:24 PM
2 Хрю: === 2Сергей Середа: "А я, всего-навсего, распространяю ТРИЗовский подход на ПО. И результаты моих исследований показывают, что это верно." Какие? Нет, серьезно. Это очень интересно. === Пока они выражаются в статье о примененимости законов развития технических систем (на которых базируется ТРИЗ) к ОС. Но я уже год как не могу разродиться статьёй именно по применению ТРИЗ при проектировании ПО. (Наработки есть, просто пока руки не доходят их собрать и оформить в статью.) Обязательно опубликую. С уважением, Сергей Середа Движение "ПОтребитель"
	Dmitry 16 Mar 2004 8:13 PM
2 Сергей Середа >Дорогой Вы наш! Искренне тронут :) Какое из значений слова искусство Вы имеете в виду, когда говорите, что программирование - не искусство? Если понимать искусство как специфический вид человеческой деятельности к которому традиционно относятся музыка, живопись, скульптура, архитектура (т.е. то, что раньше называли свободные художества), то, по определению, программирование - не искусство. Вряд ли найдутся здесь люди, которые будут утверждать обратное. С другой стороны, с течением времени возникла подмена понятий: Творец - всегда Художник, а Художник - всегда Творец. Вот с этим многие (я в том числе) и спорят, когда утверждают, что программирование - искусство, т.е. такая область человеческой деятельности в которой творчество играет первостепенную роль. С этим согласны и Вы. Есть еще одно значение слова искусство - вершина в своем роде, например искусство программирования. Так с чем мы спорим?
	Dmitry 16 Mar 2004 8:23 PM
2 Сергей Середа >Так чем же Вам так не полюбился "конвейерный подход", извольте поведать нам? С превеликим удовольствием изволю и поведаю. Я имел в виду только конвейерный подход к программированию, если Вы не поняли. То есть такой подход, когда на входе - некое описание непонятно чего (типа use cases), на выходе - готовая работающая программа. Такая вот роторная линия по разработке программного обеспечения. Я полагаю, что такой подход не может работать в принципе.
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 11:03 PM
2 Dmitry: Тогда, думаю, спор насчёт искусства можно закрывать. Я имел ввиду, что программирование это не искусство в том его значении, которое применяется к поэзии, живописи, скульптуре и т.п. А в "искусстве программирования" понятие "искусство" используется в переносном смысле. Так же можно говорить об искусстве рыбной ловли, искусстве настройки оборудования и т.п. === Я имел в виду только конвейерный подход к программированию, если Вы не поняли. То есть такой подход, когда на входе - некое описание непонятно чего (типа use cases), на выходе - готовая работающая программа. Такая вот роторная линия по разработке программного обеспечения. Я полагаю, что такой подход не может работать в принципе. ==== А почему? Просто понятие "конвейер" тоже можно использовать в нескольких смыслах. Можно, кстати, сказать, что программист-одиночка, пишущий программу за пару ночей без проработки, серьезного тестирования и документирования, "поставил дело на конвейер". А можно сказать, что в специализированной фирме по разработке ПО, организован конвейер: инженер пишет спецификацию, координатор разбивает её на отдельные задания, программисты эти задания выполняют, тестеры тестируют программу, технический писатель пишет документацию и т.п. По-моему, во втором случае конвейер не только возможен, но и крайне желателен, как средство повышения производительности труда. Или я опять чего-то не понял? С уважением, Сергей Середа Движение "ПОтребитель"
	torvic 16 Mar 2004 11:06 PM
> Я полагаю, что такой подход не может работать в принципе Вы посмотрели кто автор статьи? Тут уже звучали ключевые слова "автоматное программирование", "switch-технология". Еще раньше были диаграммы Харела.
	Bulat - rootbulat.f0.ru 16 Mar 2004 11:07 PM
>Сергей Середа: >Коран, Библия, Тора, Веды и др. - собрания мыслей и изречений, >описывающие каждый свою отдельную концепцию религиозного >мировоззрения. Они могут существовать сотни и тысячи лет, но их >роль сугубо социальна. Они не могут сами по себе способствовать >или препятствовать решению технических задач, так как находятся >в совершенно иной плоскости. Кроме того, очевидно, под >словом "работают" Вы подразумевали, что у этих учений до >настоящего времени есть последователи. Он может быть и да, а я бы подразумевал, что действительно то, что там описано вполне применимо и работает.
	Хрю 16 Mar 2004 11:49 PM
2Сергей Середа: "...инженер пишет спецификацию, координатор разбивает её на отдельные задания, программисты эти задания выполняют, тестеры тестируют программу, технический писатель пишет документацию и т.п. По-моему, во втором случае конвейер не только возможен, но и крайне желателен, как средство повышения производительности труда. Или я опять чего-то не понял?" Не "не понял" а "не знаете". В этом и проблема. Как бы снаружи (для понтов) это выглядит именно так. А вот как _на_самом_деле_ это происходит... Сергей Середа: "А я, всего-навсего, распространяю ТРИЗовский подход на ПО. И результаты моих исследований показывают, что это верно." Хрю: "Какие? Нет, серьезно. Это очень интересно." "Пока они выражаются в статье о примененимости законов развития технических систем (на которых базируется ТРИЗ) к ОС." Где можно прочитать?
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 11:49 PM
2 Bulat: === Он может быть и да, а я бы подразумевал, что действительно то, что там описано вполне применимо и работает. === В каком смысле? Сотворение мира за 7 дней, Ноев ковчег, древо познания? Что значит "работает"? Я не очень силён в теологии. С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 16 Mar 2004 11:54 PM
2 Хрю: ==== Не "не понял" а "не знаете". В этом и проблема. Как бы снаружи (для понтов) это выглядит именно так. А вот как _на_самом_деле_ это происходит... ==== Ну объясните, раз Вы у нас про это знаете. Я уже просто мечтаю узнать про "реальный мир разработки ПО". Просто пример конвейера, который Вам не понравился, я взял из статьи на www.eme.ru, а эта контора уже давненько разработкой занимается и на них не накатишь, что они, дескать, теоретики. ==== "Пока они выражаются в статье о примененимости законов развития технических систем (на которых базируется ТРИЗ) к ОС." Где можно прочитать? ==== http://consumer.nm.ru/os_devel.htm Только таблицу в конце статьи близко к сердцу не принимайте. С уважением, Сергей Середа Движение "ПОтребитель"
	Хрю 17 Mar 2004 1:07 AM
"...я взял из статьи на www.eme.ru, а эта контора уже давненько разработкой занимается и на них не накатишь, что они, дескать, теоретики." В таких конторах "статьи" пишут одни люди, а реально работающие проекты - совсем другие. И часто они даже не знакомы. Причем те, которые "статьи" пишут как правило вообще никогда к разработке отношения не имели. Это реально так, прямо вот несоклько часов как домой пришел оттуда... Иногда из-за этого порою возникают скандалы (часто недетские). "Конвейер" существует только в голове у тех, первых (сейлзы, консультанты, аккаунт-менеджеры и т.п.). Те, кто проектирует, разрабатывает и внедряет проекты конечно же понимают что никакого конвейера быть не может просто потому что проект проекту lupus est и, в _лучшем_ случае, они (проекты) друг-другу отдаленная родня. Ссылочку почитаю позже. И высажусь (уж не сомневайтесь %)).
	Хрю 17 Mar 2004 1:12 AM
"И высажусь.." Ну не высажусь, конечно (я не десантно-штурмовой батальон), а выскажусь (это мое конституционное право). :)
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 9:38 AM
2 Хрю: Кстати, когда я рылся в Сети на предмет материалов по Вашему вопросу из другой ветки, я случайно наткнулся на такую вот книжку: УСПЕХИ ВЕЛИКИХ КОМПАНИЙ "Они и не подозревали, что действуют по методике ТРИЗ" (http://quality.eup.ru/DOWNLOAD/FILES/triz1.rar) Вот такие пироги... P.S. Кстати насчёт "знаю-не знаю", я сам работал по описанной мной конвейерной схеме (второму варианту), мой сокурсник сейчас работает по ней же, у другого сокурсника своя фирма, которая работает так же. Просто этот процесс может обладать разным уровнем формализации: там, где работал я, задания назначались устно, а спецификация уточнялась непосредственно у заказчика; там, где работает мой сокурсник, задания раздаются в письменной форме индивидуально, при этом с заказчиком общается лишь постановщик задач (коим и является мой сокурсник); в фирме другого моего сокурсника они часто дают задания программистом по "аське", они не обладают свойствами ГОСТ-овского ТЗ, но формулируются достаточно чётко. Так что к "конвейеру" в той или иной его форме приходят все. Так как двигателем прогресса является не лень, а нужда. С уважением, Сергей Середа Движение "ПОтребитель"
	Andy 17 Mar 2004 10:23 AM
2Сергей Середа: "В каком смысле? Сотворение мира за 7 дней, Ноев ковчег, древо познания? Что значит "работает"? Я не очень силён в теологии." - If I have to explain, you wouldn't understand. -
	Andy 17 Mar 2004 10:25 AM
Я не помню откуда эта цитата, но эти слова здесь, имхо, применимы на 100%.
	test 17 Mar 2004 10:27 AM
К закрытому спору об искусстве :) искусный - искушенный, умелый.
	test 17 Mar 2004 10:29 AM
Про работающую теологию: Конечно не технически:) Психологически (социально).
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 10:33 AM
2 Andy: ==== 2Сергей Середа: "В каком смысле? Сотворение мира за 7 дней, Ноев ковчег, древо познания? Что значит "работает"? Я не очень силён в теологии." - If I have to explain, you wouldn't understand. - ==== "Чего он сказал?" (c) "Крепкий орешек 3". ;-) Я писал, что при всём желании могу сказать только, что религия "работает" как фактор формирования социального поведения и этнообразующий фактор. Всё. Большего ни мифология ни религия дать не могут. И это не я вбил себе в голову, это вы в любой научной публикации прочтёте. Просто я не совсем понял к чему вообще тут была реплика про религии, ведь я упомянул ТРИЗ, чтобы показать, что программирование является техническим творчеством, "отраслью инженерной науки", как указал Анатолий Шалыто. Кстати, действительно, не понятно, почему я должен доказывать почтенной публике то, что в доказательствах не нуждается, а является объективной реальностью? С уважением, Сергей Середа Движение "ПОтребитель"
	me - userinternet.com 17 Mar 2004 10:46 AM
>> Я не очень силён в теологии Тем не менее, написал-то практически всё то же самое, что и про религию. Таким словом (религия) разывается слепая вера во что-либо. Например, в ТРИЗ. Кроме того, Andy явно намекал на нелогичность вывода о том, кто прав, а кто нет. >> в специализированной фирме по разработке ПО, организован конвейер: инженер пишет спецификацию, координатор разбивает её на отдельные задания, программисты эти задания выполняют, тестеры тестируют программу, технический писатель пишет документацию Интересное представление о разработке ПО :)). Це ж "водопадная" модель! Для более или менее реальных проектов она не работает вообще (это, кстати, факт: спорить с ним безполезно). А на сайтах всякое пишут, чтобы клиента получить.
	me - userinternet.com 17 Mar 2004 10:48 AM
тьфу, блин: безполезно -> бесполезно
	Прохожий 17 Mar 2004 10:56 AM
Сергею Середе Так я о том и говорю, что Вы, голосистые ребята ... --- Вы у нас, разумеется, тихий паренек. Не голосистый. , не представляете себе на самом деле, что такое искусство, что такое наука, а что такое техническое творчество. Доказательство - никто не смог сформулировать критерий, по которому можно отнести произвольную деятельность к одной из этих сфер. --- А у вас уже готовы формулировки? Вы ведь тоже пока ничего не сказали, кроме того, что есть такая ТРИЗ. Просто ТРИЗ сам по себе является доказательством того, что изобретательство - никакое не искусство, а техническое творчество ... --- В таком случае, например, композиторство - это звуковое творчество, а изобразительное искусство - это изобразительное творчество. Практически во всяком современном виде искусства есть свои технологические наработки. Иначе не было бы всяких там академий изобразительных искусств и прочих учебных заведений. Композитором и художником тоже совсем не обязательно родиться. Можно научиться быть им. И даже результат творчества такого "художника" будет находить спрос, что мы и наблюдаем на современной эстраде. Вы тут счас Моцарта и Баха будете приводить в пример и то, что их музыка вечна. А я скажу, что есть люди, которые ненавидят классическую музыку, причем у этих людей достаточно высокий коэффициент умственного развития (победители там Олимпиад всяких в прошлом). Так где же ваша трактовка что есть искусство? Давайте ее быстрей в студию. А я, всего-навсего, распространяю ТРИЗовский подход на ПО. И результаты моих исследований показывают, что это верно. --- Ваш опыт - это еще не значит, что так оно и есть для остальных. Хотя против ТРИЗ я ничего против не имею. А Вы ни кого не воспринимаете как истину в последней инстанции? Как насчёт Ньютона, Ампера, Эйнштейна? Я имею ввиду в области действия открытых ими законов. --- Лично я никого не воспринимаю как истину в последней инстанции. Тоже самое касалось всех тех уважаемых личностей, которых вы привели в качестве неудачного примера. Ибо если бы они вели себя так, как вы, то никаких открытий никогда бы не произошло. Не пробовали взлететь "аки птица"? Не получается? К чему бы это? --- А откуда вы обо мне что-то знаете, чтобы делать такие предположения? Аргументы закончились, так переходим на личности?
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 11:02 AM
2 me: А какое отношение может иметь "слепая вера" к ТРИЗ? Я занимаюсь ТРИЗ с 6 класса средней школы и реально решал задачи при помощи методологии ТРИЗ. Да и во всём мире их решают. Говорить, что использование научно обоснованных методик есть слепая вера, это как говорить что когда мы утверждаем, что "2 + 2 = 4", мы так говорим по причине "слепой веры". Так что утверждение, что я слепо верю в ТРИЗ является абсурдом (или, более обидно, идиотизмом). Да ещё и основанном на невежестве. Потому я и не мог понять довода о редигиях, т.к. понимаю лишь доводы разумные. С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 11:07 AM
2 me: Насчёт водопадной модели: http://www.delphimaster.ru/books/978594723663/fragment.html http://www.avalon.ru/HigherEducation/OurCourses/Course.asp? CourseID=76 Кроме того, не путайте подход с моделью разработки. При конвейерном подходе возмоджна реализация кучи раных моделей разработки. С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 11:29 AM
2 Прохожий: === Сергею Середе Так я о том и говорю, что Вы, голосистые ребята ... --- Вы у нас, разумеется, тихий паренек. Не голосистый ==== Так это... С кем поведёшься... ;-) Да и орать я предпочитаю том, в чём разбираюсь (хотя бы по моему собственному мнению). ==== А у вас уже готовы формулировки? Вы ведь тоже пока ничего не сказали, кроме того, что есть такая ТРИЗ. ==== Конечно готовы. Иначе чего бы мне на Вас накатывать? Они - в моей статье "Патенты вместо авторских прав: выбираем меньшее из зол". Вот отрывок: "Общеизвестно, что потому и существуют различные понятия: художественное и техническое творчество, что первое совершенно несовместимо с технологическим подходом к его производству, в отличие от второго. Кроме этого, результаты художественного творчества не обладают функциональностью. То есть, художественное произведение обладает художественной ценностью, несовместимо с технологическим подходом и не обладает функциональностью." Имеется ввиду технологический подход ИМЕННО К СОЗДАНИЮ произведения, а не тиражировани. его экземпляров. А ты Вы сразу приведёте в пример литографию, скульптуру и литературу. Вот три признака, по которым я разделяю предметы искусства и предметы техологического производства. Лучших я не придумал. Мои коллеги тоже. Дайте контрпример, который бы опроверг эти критерии и/или предожите более удачные критерии. Тогда это будет научная дискуссия, а не базар. ==== А я, всего-навсего, распространяю ТРИЗовский подход на ПО. И результаты моих исследований показывают, что это верно. --- Ваш опыт - это еще не значит, что так оно и есть для остальных. Хотя против ТРИЗ я ничего против не имею. ==== Так результаты исследований тем и отличаются от личного опыта, что они подлежат проверке. В этом суть научного подхода к познанию. ==== Лично я никого не воспринимаю как истину в последней инстанции. Тоже самое касалось всех тех уважаемых личностей, которых вы привели в качестве неудачного примера. Ибо если бы они вели себя так, как вы, то никаких открытий никогда бы не произошло. ==== Вы заблуждаетесь, очень много известных учёных и мыслителей обладали отвратительным характером, задиристостью и вздорным нравом. Это я не в смысле того, что в этом нужно брать с них пример. ==== Не пробовали взлететь "аки птица"? Не получается? К чему бы это? --- А откуда вы обо мне что-то знаете, чтобы делать такие предположения? Аргументы закончились, так переходим на личности? ==== Причём же тут личности. Я о Вас ничего не знаю, но, исходя из общих законов природы, могу со 100% уверенностью сказать, что левитировать Вы не способны (как и ни один Homo Sapiens). Если же Вы способны левитировать, значит нам нельзя принимать Ньютона и других великих физиков "как последнюю инстанцию", а нужно выдать Вам Нобелевскую премию и строить всё научное знание заново. Так что любой человек "верит" в то, что предметы имеют свойство падать на землю, а не возноситься в небеса. Исключения же из этого правила объясняются "верой" в закон Архимеда и формулы Можайского и Жуковского. С уважением, Сергей Середа Движение "ПОтребитель"
	me - userinternet.com 17 Mar 2004 11:39 AM
>> какое отношение может иметь "слепая вера" к ТРИЗ? Слепая вера - вера (пусть и основанная на опыте), которая не позволяет видеть недостатков и ограничений. Так что сам дурак :)). Нигде я не сомневался в эффективности конвейерного подхода, кстати. А вот водопадная модель не работает всё равно. Не получается настолько сильно отделить проектировщиков от "кодеров". Почему-то :)). Про Брауде я где-то слышал. Возможно, даже читал. Где он там хвалит водопады? >> http://quality.eup.ru/DOWNLOAD/FILES/triz1.rar А вот это очень смешная статья :)). Товарищ явно лукавит (читай: гонит).
	me - userinternet.com 17 Mar 2004 11:52 AM
>> Так что любой человек "верит" в то, что предметы имеют свойство падать на землю Не "верит", а "знает". Тоже в кавычках. "Верит" - это если ему кто-то говорит, что "знает". >> художественное произведение обладает художественной ценностью, несовместимо с технологическим подходом и не обладает функциональностью Посмотрим на программу, приводимую в пример автором обсуждамой статьи: нерекурсивные Ханойские башни. 1. 6 строк - явно претендует на художественную ценность 2. Наверняка была придумана не на конвейере. 3. Функциональности ровно столько же, сколько и в тексте решения (а текст-то сильно претендует на художественное творчество) Вывод? И так очень многие из существующих программ, так как они часто состоят именно из таких алгоритмов.
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 12:01 PM
2 me: Вот, кстати, еще нашёл по разработке ПО: http://www.osp.ru/os/2002/10/039.htm === >> какое отношение может иметь "слепая вера" к ТРИЗ? Слепая вера - вера (пусть и основанная на опыте), которая не позволяет видеть недостатков и ограничений. Так что сам дурак :)). === То есть, с одной стороны, вера как бы и слепая (не позволяет видеть недостатков и ограничений), а с другой - подслеповатая (основанная на опыте). Вы, всё-таки, определитесь, что из этого Вы инкреминируете именно мне. ;-P ==== Про Брауде я где-то слышал. Возможно, даже читал. Где он там хвалит водопады? ==== А где я писал про водопады? === >> http://quality.eup.ru/DOWNLOAD/FILES/triz1.rar А вот это очень смешная статья :)). Товарищ явно лукавит (читай: гонит). === Ещё раз перечитал. Всё совершенно чётко. Никаких натяжек или передёргиваний. То, что Вам в это "не верится", ещё ни о чём не говорит. Точнее говорит, но Вы обидитесь ;-) С уважением, Сергей Середа Движение "ПОтребитель"
	me - userinternet.com 17 Mar 2004 12:02 PM
>> Вы заблуждаетесь, очень много известных учёных и мыслителей обладали отвратительным характером, задиристостью и вздорным нравом. Хочешь быть великим, да? :)) Молодец.
	Chiko 17 Mar 2004 12:05 PM
Напрашиваются несколько тезисов по прочтении статьи и ознакомления с некоторыми проектами студентом с ихнего сайта 1)Документация очень нужна преподавателю для проверки курсовиков студентов. 2)Знаком-ли Сергей Середа с понятием "самодокументирующийся код"? 3)Сколько денег потеряет фирма и когда она обанкротится, оплачивая затраченное на документацию время, если будет таким образом документировать код, учитывая, что в некоторых проектах, которые я посмотрел, объем документации превышал объем кода в 10 раз !!! P.S. Безусловно документация не может быть лишней, но не такой ценой. Вот если бы она генерировалась аутоматично разными там CASE-cредствами - тогда ДА, а пока ИМХО не она, не UML никуда кроме как в жопу хе-хе не засовывается. Но думаю рано или поздно мы дойдем и до этого, об чем говорит появление в программировании SEH, patterns и тех-же: UML и "Движение за открытую проектную документацию"
	Хрю 17 Mar 2004 12:12 PM
==== "И результаты моих исследований показывают, что это верно. Пока они выражаются в статье о примененимости законов развития технических систем (на которых базируется ТРИЗ) к ОС." Где можно прочитать? ==== http://consumer.nm.ru/os_devel.htm " Ох... почитал. И _это_ все? Вот эти две странички и есть "результаты исследований"? И вывод что дос рулез как финал? Даже спорить не о чем :( Ну признайтесь честно, вы ведь хмм... не являетесь специалистом по операционным системам? Ведь так? Или по-другому: скажите пожалуйста в _чем_именно_ вы считаете себя специалистом? В чем вы компетентны? Просто чтобы не тратить слов в пустую....
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 12:12 PM
2 me: Уважаемый! Задача о Ханойских башнях является задачей прикладной математики. Так что её решение можно вообще отнести к теоретическим результатам, котрые здешней публике так не нравятся. Художественной ценностью строки программы могут обладать разве что, если их скульптор вырубит в камне, а ювелир и инкрустирует алмазами и золотом. При этом они приобретут ту же ценость, что и надписи в гробнице Хеопса. Решение задачи о Ханойских башнях было "придумано"с использованием методологии мат. логики, что хуже конвейера, т.к. может быть полностью автоматизировано (как и доказательство теорем). Функциональностью же программа решения задачи о Ханойских башнях будет обладать, если с её помощью можно будет решать какие-то реальные задачи. В любом случае, ни о какй художественной ценности речь не идёт. Нужно будет в пару словарей полезть (или в учебник по искусствоведению) и выписать определение понятия "художественная ценность". С уважением, Сергей Середа Движение "ПОтребитель"
	me - userinternet.com 17 Mar 2004 12:13 PM
>> Вы, всё-таки, определитесь, что из этого Вы инкреминируете именно мне "не позволяет" следует читать как "запрещает" (то есть, адепты, может, что-то и видят, но сказать не могут: низзя). Подслеповатая, пожалуй, точнее передаёт смысл. Основанная на опыте в райских садах. >> Ещё раз перечитал. Всё совершенно чётко. Это к вопросу о "слепой вере". Меня в этой статье не ТРИЗ смешит, а то, как автор интерпретирует успехи других людей. Насколько я понимаю (книжек ещё ни читал про это), ТРИЗ - некое формальное (и понятное) описание успешных подходов. А товарищ Петин (есть подозрение, что настоящая фамилия автора немного другая) говорит следующее: "смотрите, они используют ТРИЗ, потому что их методы совпадают с ТРИЗовскими!". Ему и в голову не приходит, что, вероятнее всего, ТРИЗ была сформулирована на основе таких вот успехов, а вовсе не наоборот.
	me - userinternet.com 17 Mar 2004 12:17 PM
>> Решение задачи о Ханойских башнях было "придумано"с использованием методологии мат. логики, что хуже конвейера, т.к. может быть полностью автоматизировано (как и доказательство теорем). Упс. Сорри, всё, молчу. Дальше без меня.
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 12:27 PM
2 Chiko: ==== Напрашиваются несколько тезисов по прочтении статьи и ознакомления с некоторыми проектами студентом с ихнего сайта 1)Документация очень нужна преподавателю для проверки курсовиков студентов. ==== Если он в "10!!!" раз превышает объём кода, то по-Вашему, получается, что преподаватель сам себе враг, т.к. увеличивет свою работу в 10 раз. ==== 2)Знаком-ли Сергей Середа с понятием "самодокументирующийся код"? ==== Я бы назвал это "самокомментирующимся кодом". Т.к. цитируюя Анатолия Шалыто "Не проектная документация должна писаться по коду, а код - по проектной документации". ==== 3)Сколько денег потеряет фирма и когда она обанкротится, оплачивая затраченное на документацию время, если будет таким образом документировать код, учитывая, что в некоторых проектах, которые я посмотрел, объем документации превышал объем кода в 10 раз !!! ==== Я буду прилагать все усилия, чтобы приблизить время, когда в первую очередь будут банкротиться фирмы, разрабатывающие некачественное и незадокументированное ПО. Наконец. Проектная документация "генерируется" мозгами разработчика, поэтому автоматичеки её генерировать не получится. Автоматически комментировать код и использовать шаблоны документирования для стандартных ситуаций - пожалуйста. С уважением, Сергей Середа Движение "ПОтребитель"
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 12:33 PM
2 me: === А товарищ Петин (есть подозрение, что настоящая фамилия автора немного другая) говорит следующее: "смотрите, они используют ТРИЗ, потому что их методы совпадают с ТРИЗовскими!". Ему и в голову не приходит, что, вероятнее всего, ТРИЗ была сформулирована на основе таких вот успехов, а вовсе не наоборот. === Разумеется, ТРИЗ была сформирована именно на основе анализа успешных решений. Просто автор указывает, что описанные решения были приняты спонтанно, без методологии. При этом эти решения являются сильными, "тризовскими". Если Вы имели в виду неоднозначность названия статьи, то я с Вами соглашусь, но содержание статьи просто ещё раз показывает эффективность ТРИЗ, как методологии, намного опережающей принятый до сих пор метод проб и ошибок. С уважением, Сергей Середа Движение "ПОтребитель"
	Andy 17 Mar 2004 12:37 PM
me прав, статья очень смешная. Напоминает когда-то популярную статью о вреде огурцов - там тоже очень много примеров было ;)
	Andy 17 Mar 2004 12:57 PM
А если быть серьёзным, то можно ещё вспомнить "Философию Творчества" Э.По (напр. http://lib.ru/INOFANT/POE/essays.txt). Имхо, здесь тот же случай. То есть мы что-то делаем, а затем пользуясь хорошей методикой объясняем почему это у нас получилось (или почему не получилось).
	Прохожий 17 Mar 2004 1:04 PM
Сергею Середе Да и орать я предпочитаю том, в чём разбираюсь (хотя бы по моему собственному мнению). --- Дык и все так себя ведут. "Общеизвестно, что потому и существуют различные понятия: художественное и техническое творчество, что первое совершенно несовместимо с технологическим подходом к его производству, в отличие от второго." --- Еще как совместимо. Еще раз напомню про учебные заведения в сфере искусства. Кроме этого, результаты художественного творчества не обладают функциональностью. --- Если понимать под функциональностью то, что способно удовлетворять какие-то потребности, то еще как обладают. Иначе никто не платил бы иной раз миллионы долларов за некоторые произведения искусства. Имеется ввиду технологический подход ИМЕННО К СОЗДАНИЮ произведения. --- Вы когда-нить занимались искусством? Похоже, что нет. А я занимался. Повторюсь еще раз. В любом современном виде искусства (музыка, изобразительное искусство, литература) есть технологические наработки. Именно технологические. Которые используются при СОЗДАНИИ художественных ценностей. Лучших я не придумал. Мои коллеги тоже. Дайте контрпример, который бы опроверг эти критерии и/или предожите более удачные критерии. Тогда это будет научная дискуссия, а не базар. --- Еще раз перечитайте мои сообщения. Если углубиться в размышления над способами создания технических или художественных ценностей, то окажется, что _принципиальной_ разницы между ними нет. Если поразмыслить просто о разнице, не принципиальной, тогда стОит говорить только о повышенной сложности при создании художественных ценностей по сравнению с техническими. Вы заблуждаетесь, очень много известных учёных и мыслителей обладали отвратительным характером, задиристостью и вздорным нравом. --- Не понял только в чем я заблуждался? В том, что не стОит превозносить открытия в области науки, как истину в последней инстанции? но, исходя из общих законов природы... --- Вы обо всех законах природы всё знаете? Гм... ... могу со 100% уверенностью сказать, что левитировать Вы не способны. Если же Вы способны левитировать ... --- Значит есть таки сомнения? И то хорошо. ... значит нам нельзя принимать Ньютона и других великих физиков "как последнюю инстанцию" --- А я и не принимаю. Уже говорил об этом. ... а нужно выдать Вам Нобелевскую премию и строить всё научное знание заново. --- Возможно, возможно. Так что любой человек "верит" в то, что предметы имеют свойство падать на землю, а не возноситься в небеса. --- Хорошо, хоть, признаете, что это всего лишь вера.
	Прохожий 17 Mar 2004 1:09 PM
Сергею Середе --- ... а нужно выдать Вам Нобелевскую премию и строить всё научное знание заново. --- Сколько уж раз так было. И ничего. Жив курилка. :-)
	Сергей Середа - serge_seredahotmail.com 17 Mar 2004 1:17 PM
2 Andy: === me прав, статья очень смешная. Напоминает когда-то популярную статью о вреде огурцов - там тоже очень много примеров было ;) === Мне это напомнило эпизод из фильма "Место встречи изменить нельзя", когда народ дружно ржал над одним из сотрудников МУРа, когда он сказал, что придёт время, и телевизоры будут в каждом доме и изменят всю нашу жизнь. P.S. Я тоже отключаюсь. Работы - куча. С уважением, Сергей Середа Движение "ПОтребитель"
	Andy 17 Mar 2004 1:27 PM
"Мне это напомнило эпизод из фильма "Место встречи изменить нельзя", когда народ дружно ржал над одним из сотрудников МУРа, когда он сказал, что придёт время, и телевизоры будут в каждом доме и изменят всю нашу жизнь." - Ага, и ещё был фильм "Москва слезам не верит", где один гражданин рассказывал, что "Лет через двадцать ничего не будет: ни театра, ни кино, одно только телевидение".
	Chiko 17 Mar 2004 1:28 PM
2 Сергей Середа: === Если он в "10!!!" раз превышает объём кода, то по-Вашему, получается, что преподаватель сам себе враг, т.к. увеличивет свою работу в 10 раз. === Я так понимаю из Вашей статьи это проще, чем вникать в код. :) === Я бы назвал это "самокомментирующимся кодом". Т.к. цитируюя Анатолия Шалыто "Не проектная документация должна писаться по коду, а код - по проектной документации". === Получается, что документация отделена от кода, следовательно при изменении ТЗ должна изменяться как проектная документация так и код. Изменения в двух местах. Выше вероятность внести ошибку + неудобство поддержки. Если я правильно понял, то в проектной документации всё должно быть описано подробно до кажного винтика, поэтому вопрос зачем этот винтик документировать отдельно, если это делает сам исходный код программы ? === Я буду прилагать все усилия, чтобы приблизить время, когда в первую очередь будут банкротиться фирмы, разрабатывающие некачественное и незадокументированное ПО. === Очень пафосно... :) Вы делаете знак равенства между "некачественное" и "незадокументированное" ? Я бы сказал что "некачественное" - это то, которое не выполняющее (плохо выполняющее) свои функции, но никак не незадокументированное. "Рынок голосует деньгами" - поэтому Ваша схема "Разновидности требований к проектной документации" очень правильна. "Документировано в объёме требуемом заказчиком" - всё верно. Заплатят сделаю, не заплатят - как захочу. Ни копейки - нецелевому расходованию средств. Насильственное внедрениие документации не получится. Хорошо написанный код, с комментариями в НУЖНЫХ местах, и есть проектная документация!
	Andy 17 Mar 2004 1:40 PM
BTW, вот все такие занятые - "P.S. Я тоже отключаюсь. Работы - куча." и т.п. Один я ерундой занимаюсь. Между прочим, документацию пишу. Подробно описываю взаимодействия нашей системы с некоторыми внешними компонентами. Что характерно, взаимодействия эти абсолютно прозрачны и происходят по стандартному сценарию. Но нет, я методом cut-and-paste творю массу описаний и диаграмм. Этого хочет заказчик. И когда ему весь этот ворох покажут - он будет доволен. А вот тот, кто будет эту систему поддерживать после меня - потратит несколько дней на ковыряние, пока не поймёт, что это всё - разные варианты одного и того же. Тогда он возьмёт одну из этих схем, самую общую, и будет с ней сверяться - а остальные будут и дальше лежать - просто для документации. Чтобы её не было слишком мало. Мы пишем документированное ПО!
	me - userinternet.com 17 Mar 2004 2:07 PM
>> вот все такие занятые Я откланялся исключительно потому, что господин Середа ясно продемонстрировал ценность своего диплома. Спорить с пятнадцатилетним хвастуном не имею ни малейшего желания.
	Прохожий 17 Mar 2004 3:01 PM
2 Шалыто Вот еще один человек недоумевает, что такое проектная документация в вашем понимании. Вы бы описали всё-таки что это такое, а?
	xacid 17 Mar 2004 4:23 PM
2 Bulat >Он может быть и да, а я бы подразумевал, что действительно то, что там описано вполне применимо и работает. вопрос только в том _что_ там описано...
	Н 17 Mar 2004 5:07 PM
Есть одна мысль. Лично я понял статью следующим образом: Суть движения состоит не в том, чтобы научить людей как писать документацию, а в том, чтобы сделать ее открытой. Пусть люди выкладывают то что есть! А время расставит все по местам. Ведь выкладывают в Open Source проектах имеющиеся исходники, а не только тщательно выверенные. В хороших проектах - хорошие исходники, в плохих - плохие. Как писать документацию - вопрос важный но ортогональный идее статьи. Г-н Шалыто просто на своем примере демонстрирует, что у его проектов открытая документация, но не призывает всех делать в точности также. Если у проекта плохая документация, то люди, которые будут разбираться в этом проекте, будут давить на производителя, чтобы он ее улучшил. Потребители будут ставить продукты с хорошей проектой документацией, потому что это некоторая гарантия качества. И т.д. Что думаете?
	Прохожий 17 Mar 2004 5:21 PM
2 Н Есть одна мысль. Лично я понял статью следующим образом: Суть движения состоит не в том, чтобы научить людей как писать документацию, а в том, чтобы сделать ее открытой. Пусть люди выкладывают то что есть! --- Это хорошо, если оно действительно есть. Как указывают участники форума, зачастую нет вобще никакой проектной документации в явном виде. В неявном виде она, конечно же, присутствует в головах разработчиков. Если у проекта плохая документация, то люди, которые будут разбираться в этом проекте, будут давить на производителя, чтобы он ее улучшил. --- За ваши деньги - любой каприз Потребители будут ставить продукты с хорошей проектой документацией, потому что это некоторая гарантия качества. --- Эта гарантия качества распространяется только на проектную документацию, но никак не на качество ПО. И так будет до тех пор, пока этапы проектирования и кодирования не сольются в один.
	Хрю 17 Mar 2004 5:30 PM
2Сергей Середа: "У меня в дипломе написано..." А в жизни? В какой именно из многочисленных областях ИТ вы сам себя считаете наиболее компетентным? Вы хотя бы понимаете что "..разбираться во всех аспектах обработки данных.." невозможно? Это значит не разбираться решительно ни в чем.
	Andy 17 Mar 2004 5:36 PM
"И так будет до тех пор, пока этапы проектирования и кодирования не сольются в один." Да нет такого этапа, как "кодирование". Ну разве что в совсем дохлых случаях (см. статью собс-но http://zdnet.ru/?ID=427760). А есть проектирование на разных уровнях детализации. А то, что на одном уровне удобнее (и нагляднее) использовать UML, а на другом - C++, это уже детали реализации.
	Прохожий 17 Mar 2004 5:46 PM
2 Andy Да есть такой этап как кодирование :-) Это когда вы ручками код набиваете, ну или среда какая-то за вас это делает.
	Andy 17 Mar 2004 5:53 PM
"Это когда вы ручками код набиваете, ну или среда какая-то за вас это делает." Ну можно компиляцию кодированием назвать конечно. Только вроде как этого давно никто ручками не делает, или я не прав?
	Прохожий 17 Mar 2004 5:57 PM
2 Andy Конечно, правы. Вот один этап автоматизации пройден (генерация кода низкого уровня). Появились компиляторы. Очередь за следующим этапом: генерация кода на языках высокого уровня. В перспективе (по-моему, весьма отдаленной) - общение с компьютером на естественном языке.
	Chiko 17 Mar 2004 6:06 PM
to Прохожий и Andy: Абсурд, демагогия, софистика.
	Andy 17 Mar 2004 6:09 PM
2Прохожий: Да, согласен. Но я пытаюсь сказать, что кодирования как такового уже нет. То есть ВСЯ разработка есть проектирование. И ЯВУ - весьма хороший инструмент для записи результатов этого проектирования, заодно указывающий на очевидные (а иногда и не очень) ошибки в проекте. К тому же с возможностью автоматически сгенерировать из этого проекта исполняемый модуль. А попытки разделить программирование на проектирование и кодирование - зряшные, ведь по сути вопрос стоит только о выборе инструмента проектирования на данном этапе разработки.
	Прохожий 17 Mar 2004 6:17 PM
2 Andy Опять вы правы, но лишь отчасти. Кодирование до сих присутствует, к сожалению (или к счастью :-)). Проблема в том, что сделав что-то в среде программирования на Яве вы не сожете повторить это на С++. А хотелось бы (может не всем, а только мне :-)), чтобы с помощью проектной документации, созданной в одной среде, успешно можно было бы генерировать код на языке высокого уровня в другой. Своего рода язык более высокого уровня абстракции хотелось бы иметь. Ну типа ЮМЛ, только еще более универсальный.
	Прохожий 17 Mar 2004 6:18 PM
2 Chiko Цыц :-) Дай дядькам поговорить. :-)
	Chiko 17 Mar 2004 6:21 PM
to Прохожий: Эээ... слова красивые ;-)
	Chiko 17 Mar 2004 7:01 PM
Что за мудачкий сайт этот zdnet programmers.txt - без пробелов
	Andy 18 Mar 2004 9:27 AM
2Chiko: да, ??? ??? Microsoft VBScript ошибка '800a004c' - это наверное смешно!
	Шалыто - Прохожий 18 Mar 2004 9:32 AM
Вы правы! Все, что Вы перечислили должно входить в проектную документацию. Обо все этом подробно - Брауде Э. Технология разработки ПО. СПб.: Питер, 2004.
	Шалыто -AT 18 Mar 2004 9:35 AM
Поздравляю! Так вот мои студенты - не слабее Вас, так что их надо уважать!
	Шалыто - torvic 18 Mar 2004 9:43 AM
Я чем-то задел публику, но чем не угодил Харел?
	Шалыто - tchico 18 Mar 2004 9:55 AM
А Вы проектную документацию на аппаратуру когда-нибудь видели - это принципиальная схема с комментариями и все? Смешно! Как сказано в одной книге: Боинг полетит тогда, когда вес докуметации совпадет с его весом! И это на самом деле так!
	Шалыто - Andy 18 Mar 2004 9:58 AM
А Вы напишите такую документацию, которой будете гордиться, а не отбывайте номер. Это сложно, это надо уметь и требуется много времени.
	Шалыто - Н 18 Mar 2004 10:09 AM
Это один из выводов статьи. Иначе не дисциплинировать - многим все равно куда работа выкладывается: в Интернет, в шкаф или помойку. Главное отбыть номер и получить деньги, с моем случае - зачет. Надеюсь, что открытость поможет.
	Шалыто - Прохожему 18 Mar 2004 10:13 AM
А заставьте своих сотрудников (если они у Вас есть)писать код по проектной докуметации, а не наоборот. А изменения вносите комплектно как это всегда делалось для аппаратуры в оборонке долгие годы.
	Andy 18 Mar 2004 11:59 AM
2Шалыто: Да, некоторые тоже верят, что "Боинг полетит тогда, когда вес докуметации совпадет с его весом! И это на самом деле так!". Вот и приходится кроме одной общей толковой и нужной схемы генерировать ещё два вагона частных случаев - в довесок.
	Andy 18 Mar 2004 12:44 PM
2Chiko: Да, это весело! Когда-то давно я это видел, но понять большей частью что происходит не мог - сейчас, конечно, рофл!
	Chiko 18 Mar 2004 12:54 PM
2Шалыто: 1. для меня код и есть документация, пояснения требуются редко, если код нормально написан. Ваши студенты так смогут работать ? 2. те программы которые я просмотрел на вашего сайта у нас пишутся одним программистом за 1-2 дня. Ваши студенты смогут? 3. смогут ли фирмы, работающие в аутсорсинге, сохранить заказчиков, если будут работать так как Вы предлагаете ? Думаю, что нет. 4.Гарантирует-ли наличие документации надежность программы ? Думаю, что нет. 5. Потребует ли будующий работодатель Ваших студентов навыков написания проектной документации ? Врят-ди...
	Chiko 18 Mar 2004 1:00 PM
2 Andy: это я к тому, что писатель проектной документации - есть более продвинутый вариант матерого программиста :)
	Н 18 Mar 2004 2:35 PM
To Andy Аутсорсинг - это конечно хорошо, но когда пишется коробочный продукт, то качество его дожно быть заметно выше, тем более если он открытый и сообщество может привлечь разработчиков для обеспечения качества. Кстати в микрософте (многими нелюбимым, хотя, как известно, чем боьше программист ругает чужое ПО, тем хуже он пишет свое) есть группы, которые ДОКАЗЫВАЮТ (по Грису) правильность работы своих алгоритмов. Эти доказательства они прикладывают к продукту, то есть эти доказательства служат проектной документацией. Нужно ли говорить, что код в этих отделах получается чрезвычайно качественный. Вопрос цены, но микрософт может себе это позволить. Поэтому "Потребует ли будующий работодатель Ваших студентов навыков написания проектной документации ?" БЕЗУСЛОВНО, потому что студенты не пойдут в офшорные фирмы!
	Andy 18 Mar 2004 5:19 PM
2H: "Аутсорсинг..." -сорри, про аутсорсинг я ни слова не говорил :( "есть группы, которые ДОКАЗЫВАЮТ (по Грису) правильность работы своих алгоритмов" -всех-всех?
	Н 18 Mar 2004 6:49 PM
Сорри Andy, это было для Chiko. Сорри Chiko.
	Шалыто - Andy 18 Mar 2004 6:53 PM
Вы думаете кто создает самолеты,подводные лодки и небоскребы - козлы, а только молодцы программисты, которые придумали делать сложные вещи без документации. Болезнь роста - скоро это пройдет! И в автоматизированном доме и дом и программы будут сильно документироваться!
	Н 18 Mar 2004 6:55 PM
To Andy. Я согласен, что прозвучало немного по-снобистски. Не в смысле, что чур меня чур, конечно. Это просто ответ на "смогут ли фирмы, работающие в аутсорсинге, сохранить заказчиков, если будут работать так как Вы предлагаете ?". Вообще говоря зависит от специализации фирмы, если фирма разрабатывает ПО по заказу боинга, то почему бы и нет. А что касается того, берут ли на работу студентов из ЛИТМО, то в нашей компании (>900 чел.) считается, что программисты оттуда сейчас самые сильные. To Andy: Да всех. Там предметная область такая, что это оправдано.
	Шалыто - Chiko 18 Mar 2004 6:57 PM
Вы посмотрели раздел статьи о требованиях к документации и картинку там ответы на практически все Ваши вопросы!
	Н 18 Mar 2004 6:58 PM
To Chiko Конечно в Winnt нет доказательств, ведь проектная документация у микрософт закрыта!
	Шалыто - Chiko 18 Mar 2004 6:59 PM
Смогут студенты тк работать, как Вы говорите - вот с этим и борюсь! Когда проектирование станет потбостью, то все встанет на свои места!
	Andy 18 Mar 2004 7:00 PM
2Шалыто: "...козлы,..." -Когда я обзывал кого-нибудь КОЗЛОМ?! "...которые придумали делать сложные вещи без документации..." -Кто сказал БЕЗ ДОКУМЕНТАЦИИ?!?! Я тут всё пытаюсь намекнуть, что ЧРЕЗМЕРНАЯ документация так же вредна как и полное отсутствие документации.
	Шалыто - Н 18 Mar 2004 7:03 PM
Спасибо за правильные слова! Еще раз говорю всем - посмотрите статью Гейтса здесь на сайте об иновациях - заговорил о методах проектирования, заговорит и о документации - никуда не денется
	Шалыто - Chiko 18 Mar 2004 7:06 PM
Поделки... А может быть Вы где-нибудь видели открытые учебные проекты большей сложности и на русском!
	Шалыто - Н 18 Mar 2004 7:09 PM
Когда я говорю, что у нас очень сильные студенты - мне не верят - профессор... Может быть поверят Вам и изменят тон разговора!
	Шалыто - Andy 18 Mar 2004 7:13 PM
Да какая там черзмерная - никакую не умеют писать! Про каждую фразу спрашиваю - ты это имеешь ввиду, а надо не иметь ввиду, а понятно и логично ее писать и строить
	Барвицкий 18 Mar 2004 9:08 PM
Техническая документация должна быть понятна для среднестатистического идиота. Это нужно для того, чтобы среднестатистический инженер на 11-м часу работы смог ее прочесть. Для этого нужно ее писать с позиции того самого идиота, который будет ее читать. Особенно хорошо посадить его рядом. Именно сейчас мы этим с А.А. Шалыто и занимаемся :) Привет всем и от него тоже.
	AT - 220220pager.icq.com 19 Mar 2004 1:45 AM
ЭЭх ... Если спор до сих продолжаеться значит никто не сумел привести достаточных аргументов. Объявляю ничью :o)))
	Chiko 19 Mar 2004 11:47 AM
Да, все остались при своем мнении. Я очень хотел-бы посмотреть, как уважаемый профессор писал-бы коммерческий продукт, когда заказчик присылает в день по 2-3 новых требования к программе, зачастую противоположные друг другу и общей архитектуре программы, когда проодукт требует значительного перепроектирования. Документация, во всяком случае в предлагаемом автором виде, будет просто тормозом при этом. Это ИМХО просто лишнее звено. Такова реальность. А появление экстремального программирования как раз и свидетельствует тому что требуется сейчас в этой индустрии.
	VicTor 19 Mar 2004 12:55 PM
2Chiko: описываемая Вами ситуация говорит только об одном - что у Вас вообще нет проекта. Заказчик не знает, что он хочет, Вы не предствляете себе его работу и, соответсвенно, не можете на доступном ему языке объяснить ему, что ему надо (да, приходится заниматься и этим тоже :)
	Прохожий 19 Mar 2004 1:09 PM
2 Барвицкий "Для этого нужно ее писать с позиции того самого идиота, который будет ее читать. Особенно хорошо посадить его рядом. Именно сейчас мы этим с А.А. Шалыто и занимаемся" --- А кто при этом в роли идиота выступает? :-)
	Прохожий 19 Mar 2004 1:45 PM
2 Chiko Ладно. Лишнее звено. Но как вы будете координировать человек, скажем 40, при отсутствии проектной документации? Очень интересен будет ваш опыт.
	Барвицкий 19 Mar 2004 2:08 PM
Уважаемый Chiko, кто из вас умеет разрабатывать ПО? Вы или разработчик? Если бы вы пришли к хирургу и стали рассказывать ему, как Вам надо вырезать аппендицит, что бы из этого получилось? Я считаю, что заказчик ПО ОПРЕДЕЛЕНИЮ не может сформировать ТЗ в сколько-нибудь пригодном виде. Оно в любом случае ДОЛЖНО проходить редакцию разработчиков. И, реально, последнее слово о том, каким будет ТЗ остается за разработчиком, а не за менеджером. Потому, что у него 10*N лет опыта работы и он - профессиональный инженер, в отличие от всех остальных занятых в разработке. С моей точки зрения это не противоречит ни каким методикам ведения проекта, а является элементарным деловым этикетом. Теперь к документации. С моей точки зрения, документацию лучше делать из пяти частей: 1) "Intro" - 2-20 страниц текста о том, что это за проект, с какой целью он разрабатывается, и чего мы хотим этим добиться, какие идеи мы закладываем в эту разработку и т.д. Используется для того, чтобы придя в команду, новый инженер СМОГ в общих чертах въехать в то, чем ему предстоит заниматься. Так же используется как отправная точка для press-release, чтобы PR-щики не напороли всякой чуши, вызывающей у специалистов нервное хихиканье. Бывает полезна менеджерам для того, чтобы разговаривать с клиентом. Пишется ручками манагером и архитекторами. Читается всеми и корректируется по мере надобности. Как правило, коррективы туда вносятся только при реинкарнации проекта. Разработку не тормозит. Имеет смысл написать в стиле А.А.Шалыто - не прогадаете. 2) "Spec" - 10-15 стр. - спецификация продукта. Утрясается с заказчиком. В идеале подписывается им и манагером. Это единственный документ, который содержит ЧЕТКОЕ описание официальных пожеланий заказчика. Звонки по телефону, почта и прочее - это не документ. Любое изменение требований должно туда попадать. Используется разработчиками, тестерами, манагерами и адвокатами (если заказчик ерепенится). Обновляется - где-то пару раз в неделю. Тормозит принятие решений, но без нее сильно возрастает риск сделать не то, что хочет заказчик. Кроме того, если нет отдельного документа определяющего В ДЕТАЛЯХ чего хочет заказчик, то у заказчика всегда есть возможность продинамить выплаты или скривить морду по поводу правильно сделанной работы. Объясните это своему манагеру, и найдете 100% поддержку. Кстати, процедура утверждения Spec проходит в несколько итераций, до тех пор, пока его вид всех не устроит. До этого начинать работу смысла нет. По личному опыту, даже с такими запутками удается делать официальный билд в неделю. Чаще, по моему мнению, смысла это делать нет. Заказчик всегда неделю перетопчется. (...to be continued...)
	Барвицкий 19 Mar 2004 2:09 PM
(... продолжение ...) 3) "Reference" - дока разработчиков + диаграмки. Строится CASE'ом или по исходному коду. Приводится в Божеский вид перед каждым официальным билдом, за что несет ответственность лидер группы. Как правило метаописания правят прямо в момент их внесения. Reference так же делится на части, но об этом в другой раз. Как правило, содержит диаграмки нарисованные архитекторами (что настоятельно рекомендуется). ПО ПОВОДУ ОТДЕЛЬНЫХ НЕТРИВИАЛЬНЫХ МОМЕНТОВ, рисуется очень подробная дока в виде статьи. Одна особенность - Reference не должна быть избыточной, иначе при каждом билде надо делать ревизию. Это плохо. Поэтому правило "Once and only once" там работает. 4) Не смейтесь, "Project plan". Нафига? Объясню. Во-первых, любая работа хорошо сделана тогда, когда сделана в срок. Поэтому любое телодвижение в проекте должно быть чем-то обосновано в ПП. Во-вторых, это единственная вещь, которая привязывает сроки к нашей деятельности. И, в третих, ПП есть проекция Spec на ось времени. Если ПП грамотно использовать, нет нужды умножать сроки на 3.14. В-третьих, это помогает четко видеть перспективу и оценивать риски. С ПП работают все. При этом (ВАЖНО!) любой человек вплоть до тестера (!) и кодера(!) может и ДОЛЖЕН корректировать план в тех местах, где есть на него assignment. Только так манагеры смогут иметь у себя на листе реальную картинку, а не желаемую. Метрики (например, CMMI) для этого помогают, но они не могут заменить активной работы с ПП в полном объеме. В случае если изменения, внесенные в ПП, не устраивают манагера, ему следует подойти к их автору, выяснить, в чем дело и придумать решение проблемы. Имхо, это его работа - обеспечивать планирование проекта. И ему следует помнить, что это он работает для разработчиков а не разработчики для него. Т.е. ПП это реальная составляющая проектной документации, не отделимая от всего остального. 5) Ессно, "User". Состоит из кучи частей. Пишется отдельными людьми (часто кто-то из QA) под надзором и при помощи разработчиков. Приводится в нормальный вид перед release, проверяется по Spec. Иногда пишется самим заказчиком и проверяется QA и/или разработчиками. Открывать стоит все кроме (4), так как это внутренняя вещь для конторы. Писать в духе А.А.Шалыто надо, по моему мнению, (1) (2 особенно) (куски 3) и (5). Мне кажется это разумным компромиссом. Успехов Вам всем…
	Барвицкий 19 Mar 2004 2:25 PM
2 Прохожий: В роли идиота всегда выступает не знакомый с проектом человек, в принципе представляющий себе предметную область. В роли подопытных кроликов хорошо идут тестеры. Во многом благодаря своей природной придирчивости. Попробуйте - поймете что это не плохо работает. Я на ваш вопрос ответил? С уважением...
	Chiko 19 Mar 2004 3:28 PM
2 VicTor: === описываемая Вами ситуация говорит только об одном - что у Вас вообще нет проекта. === да ну, может еще определение проекта дадите на всякий случай. skip === Заказчик не знает, что он хочет, Вы не предствляете себе его работу и, соответсвенно, не можете на доступном ему языке объяснить ему, что ему надо (да, приходится заниматься и этим тоже :) === Скажу сразу, что то о чем я пишу - взято из жизни. Заказчик имеет идею программного продукта, по которому он пишет базовый вариант ТЗ, которое присылается нам на доработку и согласование. В контракте оговорены поддержка и сопровождение. После выпуска релиза заказчик отсылает его клиентам от которых поступают предложения на доработку различной срочности на выполнение. Заказчик передает их нам на реализацию. Его не интересует архитектура программы - только лишь срок разработки.
	Chiko 19 Mar 2004 3:35 PM
2 Прохожий: === Но как вы будете координировать человек, скажем 40, при отсутствии проектной документации? Очень интересен будет ваш опыт. === Обычно мы составляет блок-схемку на листе формата А4 или нескольких таких листах. После этого пишутся интерфейсы модулей сразу в header-файлах. Нет у меня опыта для 40 человек. Однако я наверное разделил-бы их в виде древовидной структуры с корнем (я сам). Это вроде как не мной придумано :)
	Chiko 19 Mar 2004 3:52 PM
2Барвицкий: Хе-хе. Так вот то что Вы написали, я как раз считаю правильным. Но это противоричит словам автора статьи, - "В заключение раздела отметим, что в рамках предлагаемого подхода код должен основываться на проектной документации, а не наоборот" Ваши слова: " 3) "Reference" - дока разработчиков + диаграмки. Строится CASE'ом или по исходному коду. Приводится в Божеский вид перед каждым официальным билдом, за что несет ответственность лидер группы. Как правило метаописания правят прямо в момент их внесения. Reference так же делится на части, но об этом в другой раз. Как правило, содержит диаграмки нарисованные архитекторами (что настоятельно рекомендуется). ПО ПОВОДУ ОТДЕЛЬНЫХ НЕТРИВИАЛЬНЫХ МОМЕНТОВ, рисуется очень подробная дока в виде статьи. Одна особенность - Reference не должна быть избыточной, иначе при каждом билде надо делать ревизию. Это плохо. Поэтому правило "Once and only once" там работает." Ну что поимал на слове ? ;-)))
	Chiko 19 Mar 2004 3:57 PM
"Reference не должна быть избыточной, иначе при каждом билде надо делать ревизию" - Вот вот, про это я тоже ниже уже писал.
	Барвицкий 19 Mar 2004 4:13 PM
2 Chiko: "Построение кода по документации" - вариации на тему Model Driven Development. Если вы можете его использовать - значит вы большой молодец. Итак, по-порядку: Когда вы пишете код или правите модель используя документацию, значит вы ОСНОВЫВАЕТЕ ВАШИ ДЕЙСТВИЯ на проектной документации. Чем больше ответов на ваши вопросы дает ваша документация, тем ваша документация лучше и тем проще вам вести разработку. Так что противоречий со статьей нет. Далее, если вы пишете документацию в коде, то вы сначала рисуете интерфейс, потом пишите документацию и только потом пишете код и отлаживаете его. Опять же используя документацию, которую только что написали. Я и тут не вижу противоречия. Если же вы используете моделирование и рисуете диаграмки, с помощь некоего CASE-средства, которое по вашим формальным определениям строит код, вы опять-таки сначала рисуете документ, потом получаете код. И это, по моему мнению, опять не противоречит высказыванию автора. Спасибо за ответ. Не поймали :)) Могу ли я задать вам пару вопросов? ==== Обычно мы составляет блок-схемку на листе формата А4 или нескольких таких листах. ==== Блок-схему _чего_ вы строите? Зависимости компонентов? Фазы ПП? ==== После этого пишутся интерфейсы модулей сразу в header-файлах. ==== Как вы понимаете какие интерфейсы нужны? Сколько человек занимается этой работой? Заранее спасибо...
	Прохожий 19 Mar 2004 4:16 PM
2 Барвицкий Да это я шутил тогда. :-)
	Барвицкий 19 Mar 2004 4:23 PM
2 Chiko: ==== "Reference не должна быть избыточной, иначе при каждом билде надо делать ревизию" - Вот вот, про это я тоже ниже уже писал. ==== Правильно писали. Если документация не соответствует продукту, то это может спровоцировать катастрофу. А получить несоответствие легко там, где есть избыточность. Я поясню свою позицию. Если в проекте есть нетривиальные моменты, их надо разжевывать очень подробно. И там с избыточностью мириться можно, так как (а) таких мест не много при хорошем проектировании и (б) за эти нетривиальные куски отвечают конкретные люди. Поэтому и предлагается делить Reference на отдельные части, некоторые из которых ведутся и поддерживаются конкретными людьми. Спасибо за ответ.
	Барвицкий 19 Mar 2004 4:25 PM
2 Прохожий Пошутили очень в тему :-) В следующий раз буду осторожнее пользоваться словом "идиот". Спасибо.
	glassy 19 Mar 2004 5:33 PM
Спор свелся к выяснению простой и обидной истине -- менеджеры, заказчики и клиенты есть зло и мастдай :) Каждый программист мечтает писать короткие функции в небольших модулях с удобочитаемыми названиями. Терпеть не могут чужих неисправимых глюков и неожиданные фича-реквесты. О документации речь вообще не идет -- ее не любят и читать, и писать, и разработчики, и пользователи. Или тут я не прав? Я бы на месте автора написал статью про "верхи не могут, низы не хотят, безголовые проекты рулят" :) ЗЫ А еще мне нравится, как в соседнем треде с такой же силой кто-то доказывает, что любой юзер немного разработчик :)
	Барвицкий 19 Mar 2004 5:54 PM
Уважаемый glassy, Разговор идет, что каждый должен заниматься своим делом НА ПРОФЕССИОНАЛЬНОМ уровне и не должен мешать другим. Участие заказчика в создании продукта так же необходимо как и участие разработчика. Участие разработчика в управлении проектом так же необходимо как участие клиента в формироавнии требований. Учатие менеджера и в том и в другом необходимо по определению - он за все отвечает. И один из немногих способов обеспечить взаимодействие всех этих людей - заставить ВМЕСТЕ создавать и читать документацию, потому как в жизни у них очень мало общих слов. К созалению. "Терпеть не могут ... неожиданные фича-реквесты." - в равной степени как и исправлять свои ошибки. За них всегда стыдно и обидно. Неожиданный feature request суть ошибка в Spec. Люди делают ошибки. Люди исправляют ошибки. Иногда чужие. Через тернии к звездам. "...любой юзер немного разработчик :)". Извините за грубость, но в той же степени, что и любой вытирающий задницу - проктолог. Спасибо за ответ.
	me - userinternet.com 19 Mar 2004 7:09 PM
>> Неожиданный feature request суть ошибка в Spec. Мальчик, иди проспись :)) Все запросы на новую функциональность диктуются пользователями продукта (читай: вполне неожиданные). А на оправдания типа "пасмари суда, сынку, это - СПЕЦИФИКАЦИЯ" пользователи говорят немного матерных слов и больше софтину не покупают. >> если вы пишете документацию в коде, то вы сначала рисуете интерфейс, потом пишите документацию и только потом пишете код и отлаживаете его Ты бы почитал предыдущие 500 сообщений, дорогой друг. Господин Шалыто (да и ты тоже) не понимает, что программисты научены решать задачи не на том языке, на котором они матерные стишки пишут, а на том, который хорошо понятен компилятору. Идиоты - правильное было слово. Моё личное мнение таково: программу должен писать заказчик. Примерно так: "программа должна делать пользователю хорошо". И пользователю становится хорошо. Понятен намёк?
	me - userinternet.com 19 Mar 2004 7:09 PM
Не удержался, да... :))
	Шалыто - Прохожему 19 Mar 2004 7:45 PM
Какая разница!
	AT - 220220pager.icq.com 20 Mar 2004 3:06 PM
Супер идея - отдаю бесплатно. Для того чтобы создавать спецификации и требования к ПО надо воспользоваться опытом людей с Лубянки. Они сумеют из рядового пользователя в куче томов описать все требования и фичи которые будут достаточны :o))) Далее если же человек допустил дизинформацию - те же специалисты смогут перепроверить и откорректировать как требования - так и рядового юзера :o)))) Открытость информации правда можно будет требовать только после снятия грифа "секретно" при очередных выборах, или смене на новый более прогрессивный общественый строй или его маркетинговое название :o)
	Лубянские 20 Mar 2004 4:22 PM
2АТ: да, за такую "идею" деньги требовать... Лично подвергались или из демократической прессы наслышаны?
	Прохожий 22 Mar 2004 1:30 PM
2 me Позвольте полюбопытствовать, если не секрет, в команде из скольки человек вы работаете? И кто ваши основные заказчики?
	Прохожий 22 Mar 2004 1:39 PM
2 Сергей Середа Вы привели замечательную цитату. "В пределах предпосылок моделей научные знания, когда они применяются в этих границах, являются абсолютной истиной." Заметьте, сколько в ней оговорок. Вы же, как я вас понял, претендовали на абсолютную истину безоговорочно. Те, ссылки, которые вы приводите - это ведь не довод. А просто еще одно чьё-то мнение. Филсософский словарь зачем-то упомянули. Вот уж где кладезь "мудрости", оплаченной нынешними или бывшими идеологами. Напомню вам еще раз - не сотвори себе кумира. Мудрые, на мой взгляд, слова. Которым не одна тысяча лет, и которые проверены на практике не раз. Хотя абсолютной истиной они тоже являться не могут :-)
	nf - for_spamukr.net 22 Mar 2004 2:31 PM
Документация, коммуникация, проектирование и создание методологий... Не в этом топике эта проблема была поднята и не здесь она будет решена. (Вопрос где, как и кто найдет "сереборянную пулю" остается открытым). Вот только две книги по этой теме. Разные люди, разные ситуации, разные подходы к решению проблем, но все пока плывет в одну сторону, и это сторона не тотального документирования (Для "тяжелых" проектов все это не применимо). А. Коберн, "Быстрая разработка программного обеспечения." http://www.books.ru/shop/books/31328 Эдварда Йордона, "Путь камикадзе." (http://www.books.ru/shop/books/8646)
	me - userinternet.com 22 Mar 2004 3:18 PM
>> в команде из скольки человек вы работаете? 12 >> Это к "me" относительно его накатов на мою компетентность Не на "компетентность", а на "(не)образованность". На диплом имени главы академии информатизации.
	Konstantin - expfront.ru 23 Mar 2004 6:43 AM
Самаи идея Открытой Документации мне нравится, но статья просто гадская :) 80% статьи потрачена на доказательство и так неоспариваемых фактов, например доказывается что наличие документации - добро, по моему с этим и не кто не спорит и доказывать это полнейшая глупось. Тем более некоторые доводы просто смашны: "Один программист один раз не понял одну функцию", в то время ка десятки тысяч в тысячах open-source проектах, сони раз тысячи методов понимают! А по сути сказанно слишком мало!!
	Simon 23 Mar 2004 4:06 PM
Идея, может, и хорошая, но по делу сказано мало. Примерно на уровне предложить новый тренд в стоительстве, проиллюстрировав его двадцатью образцами шикарных собачих будок, выполненных призерами всемирных соревнований юных строителей. Далее подкрепив всё это уровнем призёрства своих мальчиков. Забыв при этом сказать, что мальчики учились и где-то ещё, и их призёрство не доказывает исключительной руководящей роли профессора и его учения. В качестве контрпримера можно привести победителя (а не призёра) тех же соревнований, который не собеседуется, а давно работает у БГ, и при этом не ведёт проектной документации. Кроме того, тон профессора довольно чванский, и не делает ему чести. Попытка использовать для поддержки бывших и нынеших учеников вызывает улыбку. А уж про бедность и зарплату профессора... Я бы заплакал, если бы не знал, как на том факультете у студентов выбивают деньги "на поддержу родных стен". Профессор, поработайте лучше над теорией!
	Шалыто - Simon 23 Mar 2004 9:37 PM
Спасибо за добрые советы, высказанные прекрасным тоном!
	Шалыто - Konstantin 23 Mar 2004 9:41 PM
А вот Столлман не считает, что они легко понимают. Он считает для своего движения проблему с плохой документацией практически основной. А так спасибо на добром слове!
	Дмитрий 25 Mar 2004 7:53 PM
Ух ты... Все еще спорят ни о чем... Фантастика... 2 Анатолий Шалыто: успехов вам на вашем сизифовом поприще ;-) P.S. Идея на самом деле неплоха. Хотите встречную? Попробуйте кинуть ее (идею) на ZDNet.com (не .ru). Интересно, что получится. Мне кажется, что аудитория идею ухватит с лета. Только как она приживется?
	Шалыто - Дмитрий 26 Mar 2004 9:17 PM
Спасибо на добром слове. Даже странно их слышать в этой переписке. На com посылал - ни ответа, ни привета. Но две недели назад выступал на LinuxSummit - вполне успешно (см. фотографии у меня на сайте)
	Шалыто 1 Apr 2004 5:03 PM
Вчера одни из наших мальчиков, которых здесь вместе со мной , стали чемпионами Мира по программированию по версии АСМ. Порадуйтесь, хоть, этому!
	- 2 Apr 2004 1:42 PM
2Шалыто: Поздравляю!!!
	юзер 3 Aug 2004 4:52 PM
Уфф... дочитал таки... ФИДОрастия. 2Шалыто: вам не следует вступать в обсуждения ваших статей. Если бы вы наблюдали не вмешиваясь, спустя 25 страниц флейма вам бы иначе представлялась значимость "мнений". С глубочайшим уважением, юзер
	Алексей Далотов - agavaszerro.net 15 Aug 2004 4:32 AM
Уважаемый Анатолий Абрамович! Ваше движение мне хорошо знакомо по сайту http://www.crealab.org/. Я сам программист с немалым стажем, но не могу сказать, что имеет место нехватка информативности кода. Конечно, есть такие люди, что пишут совершенно непонятные коды. Но таких мало! Более того, именно закрытость (инкапсулированность) кода гарантирует его сохранность при создании большого проекта. Требуется дать каждому программисту по задаче и максимально сузить интерфейс его взаимодействия с остальным проектом. И все!
	Просто пользователь - itusernarod.ru 18 Jul 2005 11:49 PM
[Quote] Почему исходные тексты не решают проблему понимания программ? [/Quote] Может поптому же, почему печатное слово(программа) не корректно решает проблему передачи мысли (алгоритма).
	Запоздалый читатель 11 Sep 2005 3:52 PM
Статью можно редуцировать к слогану: "Пишите документацию к программам и выкладывайте ее на всеощее обозрение". Слоган следует поправить: "Пишите _адекватную_ _проектную_ документацию к программам и выкладывайте ее на всеощее обозрение". Блин. Какая пустая статья! Слава Богу, обсуждали ее интересные люди, не зря читал комментарии.
	Сергей Дмитриев 21 Sep 2005 5:10 PM
В статье «Ещё раз об открытой проектной документации» нашел строчку: «упор в нем [движении за открытую проектную документацию] делается не на документацию программ, а на документацию проектов их создания», по которой получается, что идея открытой проектной документации (Foundation for Open Project Documentation) вполне вписывается в общий ход мыслей об ad-hoc education (мои попытки описать адекватную времени самоорганизующуюся образовательную систему - см. тут: http://adhoceducation.blogspot.com/2005/06/draft-concept-rus sian-edition.html). И в контексте ad-hoc education идея отрытой документации, по моему мнению, не имеет столь спорного характера, как при применении ко всей софтверной индустрии в целом.
	sergei - snikitsmail.ru 13 Nov 2005 5:52 PM
Убийство авиадиспетчера это великая глупость, потому что в катастрофе в первую очередь виновата администрация СКАЙ ГАЙД которая поставила специалиста в такие условия, когда просто физически не возможно было контролировать все воздушное пространство из-за технологической занятости.