Здравствуйте!
Меня зовут Константин Берлинский, я автор книги «Набор серебряных пуль» (размещена здесь: http://www.vbstreets.ru/Projects/NSP_Book/default.aspx).
Эта ветка форума была создана для того, чтобы в одном месте собрать все замечания, касающиеся опубликованного материала.
В первую очередь, интересуют:
А) технические рецензии ИТ-экспертами (изменение/расширение предложенного набора УПР)
Б) литературная коррекция
В) предложения о сотрудничестве по развитию проекта (перевод, издание в «бумажном» варианте, etc.)
Убедительная просьба высказываться по существу и приводить аргументы в защиту Вашей точки зрения. Я готов ответить на всевозможные вопросы и поддержать любую дискуссию с использованием нормативной лексики.
При необходимости, можно связаться со мной через email (nsp_book на сервере mail.ru).
--
С уважением,
Константин Берлинский
разработчик ПО ИТ-отдела
компании Maximum,
Республика Молдова
Обсуждение книги «Набор серебряных пуль»
Модератор: BV
Сообщений: 14
• Страница 1 из 1
- Константин Берлинский
- Начинающий
- Сообщения: 6
- Зарегистрирован: 23.06.2004 (Ср) 20:42
- Откуда: Республика Молдова, Кишинев
Обсуждение книги «Набор серебряных пуль»
Константин Берлинский » 23.06.2004 (Ср) 23:00
Последний раз редактировалось Константин Берлинский 30.06.2004 (Ср) 10:03, всего редактировалось 1 раз.
- areh
- Постоялец
- Сообщения: 530
- Зарегистрирован: 02.12.2002 (Пн) 12:28
- Откуда: РОССИЯ, Салехард
areh » 27.06.2004 (Вс) 13:24
Прочитал книгу от начала до конца не отрываясь..
Идея мне очень понравилсась. Нашел для себя много нового а так же подтверждение (подробное описание) идей до которых дошел сам и которые активно применяю.
Мне кажеться, что описание книги очень туманное, и по большому счету не дает представления о том что в ней будет, хотя немного завораживает... т.е. в описании основную информативную роль несут понятия "методология", "методика", НО эти понятия являються очень неоднозначными, и при прочтении описания, каждый может трактовать содержание книги по своему, что в своб очередь очень плохо, так как это может оттолкнуть людей, которым информация в книге будет полезной...
возможно будет достаточно дополнить "методику" до "методика работы над проетом"
советую прочитать книгу всем, кто собираеться работать в области ИТ. она поможет вам организовать работу, над каким либо проектом.
Теперь относительно того как книга написана. Считаю очень плохим решением постоянно использовать сокращения, т.е. нет ничего страшного в том, что используються общепринятые сокращения (типа ПО, СУБД), но использовать собственные сокращения мне кажеться не стоит. Во-первых, это ухудшает читаемость текста, во-вторых, есть изменения их значение от одного пункта к другому (в книге есть несколько вариантов сокращения ПП).
Так что лучше такое убрать, а все остальные сокращения (которые имеют одно и то же значение на протяжении всей книги) можно вынести на отдельный лист (не зря придумали такую штуку как список сокращений).
вообщем вот такое моё мнение. в целом книгой остался доволен, и сейчас мне не жалко времени, потраченного на её прочтение.
Идея мне очень понравилсась. Нашел для себя много нового а так же подтверждение (подробное описание) идей до которых дошел сам и которые активно применяю.
Мне кажеться, что описание книги очень туманное, и по большому счету не дает представления о том что в ней будет, хотя немного завораживает... т.е. в описании основную информативную роль несут понятия "методология", "методика", НО эти понятия являються очень неоднозначными, и при прочтении описания, каждый может трактовать содержание книги по своему, что в своб очередь очень плохо, так как это может оттолкнуть людей, которым информация в книге будет полезной...
возможно будет достаточно дополнить "методику" до "методика работы над проетом"
советую прочитать книгу всем, кто собираеться работать в области ИТ. она поможет вам организовать работу, над каким либо проектом.
Теперь относительно того как книга написана. Считаю очень плохим решением постоянно использовать сокращения, т.е. нет ничего страшного в том, что используються общепринятые сокращения (типа ПО, СУБД), но использовать собственные сокращения мне кажеться не стоит. Во-первых, это ухудшает читаемость текста, во-вторых, есть изменения их значение от одного пункта к другому (в книге есть несколько вариантов сокращения ПП).
Так что лучше такое убрать, а все остальные сокращения (которые имеют одно и то же значение на протяжении всей книги) можно вынести на отдельный лист (не зря придумали такую штуку как список сокращений).
вообщем вот такое моё мнение. в целом книгой остался доволен, и сейчас мне не жалко времени, потраченного на её прочтение.
- CyberYen
- Продвинутый пользователь
-
- Сообщения: 112
- Зарегистрирован: 10.03.2004 (Ср) 18:14
CyberYen » 27.06.2004 (Вс) 16:37
areh писал(а):Считаю очень плохим решением постоянно использовать сокращения, т.е. нет ничего страшного в том, что используються общепринятые сокращения (типа ПО, СУБД), но использовать собственные сокращения мне кажеться не стоит. Во-первых, это ухудшает читаемость текста, во-вторых, есть изменения их значение от одного пункта к другому (в книге есть несколько вариантов сокращения ПП).
Полностью согласен!
А в остальном, книга действительно содержит довольно много полезных идей. В принципе, она будет полезна не только разработчикам.
Советы и предложения данной книги окажутся весьма полезными организаторам, менеджерам и пр.
И я не жалею времени, потраченного на чтение
- Константин Берлинский
- Начинающий
- Сообщения: 6
- Зарегистрирован: 23.06.2004 (Ср) 20:42
- Откуда: Республика Молдова, Кишинев
Константин Берлинский » 28.06.2004 (Пн) 9:50
Здравствуйте!
Спасибо за доброжелательные (в целом) отклики.
Мне уже прислали несколько замечаний на емайл, поэтому, суммируя все полученные на данный момент рецензии, могу сказать следующее:
1. По поводу сокращений и вынесения списка их в отдельную главу – хорошая идея, в следующей версии текста надо будет переделать
2. По поводу «туманного описания книги» - я постарался как раз сделать аннотацию максимально краткой, но одновременно ясно и четко описывающей содержание материала. Поэтому, слово «методология» мне показалось наиболее информативным и отражающим суть книги (набор УПР в противовес методикам). И это понятие не кажется мне туманным. Хотя я могу и ошибаться
3. Кроме того, было прислано много писем, где меня ругали за чересчур частое цитирование и большой список литературы - не всем верится, что вся она была использована. Однако, я не стесняюсь использовать чужой опыт в своей работе. Надеюсь, мне не будет задан вопрос – «Уважаемый Б.К., почему в Вашем творчестве так много римейков» .
4. Вообще, текст требует хорошей работы литературного редактора. Т.к. сейчас я живу в Молдавии, то «хорошим русским языком» похвастаться не могу. Но на данный момент достигнуто соглашение о правке текста редактором сайта CitForum.ru. Надеюсь, нам удастся выполнить эту работу и тогда материал будет переиздан в формате HTML (подразумевается, что качество самого текста также повысится).
--
С уважением,
Константин Берлинский
Спасибо за доброжелательные (в целом) отклики.
Мне уже прислали несколько замечаний на емайл, поэтому, суммируя все полученные на данный момент рецензии, могу сказать следующее:
1. По поводу сокращений и вынесения списка их в отдельную главу – хорошая идея, в следующей версии текста надо будет переделать
2. По поводу «туманного описания книги» - я постарался как раз сделать аннотацию максимально краткой, но одновременно ясно и четко описывающей содержание материала. Поэтому, слово «методология» мне показалось наиболее информативным и отражающим суть книги (набор УПР в противовес методикам). И это понятие не кажется мне туманным. Хотя я могу и ошибаться
3. Кроме того, было прислано много писем, где меня ругали за чересчур частое цитирование и большой список литературы - не всем верится, что вся она была использована
. Однако, я не стесняюсь использовать чужой опыт в своей работе. Надеюсь, мне не будет задан вопрос – «Уважаемый Б.К., почему в Вашем творчестве так много римейков» .
4. Вообще, текст требует хорошей работы литературного редактора. Т.к. сейчас я живу в Молдавии, то «хорошим русским языком» похвастаться не могу. Но на данный момент достигнуто соглашение о правке текста редактором сайта CitForum.ru. Надеюсь, нам удастся выполнить эту работу и тогда материал будет переиздан в формате HTML (подразумевается, что качество самого текста также повысится).
--
С уважением,
Константин Берлинский
- Новиков Виталий
- Начинающий
- Сообщения: 1
- Зарегистрирован: 12.07.2004 (Пн) 10:07
- Откуда: г. Москва
Отзыв на книгу
Новиков Виталий » 12.07.2004 (Пн) 14:15
Константин, спасибо за книгу.
Было и есть - полезно почитать!
К сожалению, мало рекомендаций Заказчикам ПО, а я представляю именно их сторону баррикад.
Опыт сотрудничества с IT компаниями (пока с 1-ой ) к положительным результатам не привел. В основном, как Вы правильно сказали в книге, из-за того, что компания не смогла организовать процесс.
Мне же сказали, что они отнеслись ко мне как к обычному заказчику, а я оказался "несколько продвинутым". Правда и задача стоит не совсем стандартная, больше напоминающая АСУ, а не управленческий учет в его теперешнем понимании.
Поэтому мне, например, было бы полезнее узнать какие "ошибки" делают заказчики и как с ними - заказчиками бороться.
Хотя книга ориентирована не на заказчиков, а на разработчиков, было бы интересно услышать мнение профессионалов IT о заказчиках (не только ваше).
Скорее всего, там будет не мало "лестных" отзывов, но взгляд со стороны всегда полезен.
Еще раз спасибо за книгу. Удачи!
Было и есть - полезно почитать!
К сожалению, мало рекомендаций Заказчикам ПО, а я представляю именно их сторону баррикад.
Опыт сотрудничества с IT компаниями (пока с 1-ой ) к положительным результатам не привел. В основном, как Вы правильно сказали в книге, из-за того, что компания не смогла организовать процесс.
Мне же сказали, что они отнеслись ко мне как к обычному заказчику, а я оказался "несколько продвинутым". Правда и задача стоит не совсем стандартная, больше напоминающая АСУ, а не управленческий учет в его теперешнем понимании.
Поэтому мне, например, было бы полезнее узнать какие "ошибки" делают заказчики и как с ними - заказчиками бороться.
Хотя книга ориентирована не на заказчиков, а на разработчиков, было бы интересно услышать мнение профессионалов IT о заказчиках (не только ваше).
Скорее всего, там будет не мало "лестных" отзывов, но взгляд со стороны всегда полезен.
Еще раз спасибо за книгу. Удачи!
- Константин Берлинский
- Начинающий
- Сообщения: 6
- Зарегистрирован: 23.06.2004 (Ср) 20:42
- Откуда: Республика Молдова, Кишинев
IMHO
Константин Берлинский » 13.07.2004 (Вт) 19:24
Здравствуйте!
2Новиков Виталий:
Ниже представлено мое личное мнение об ошибках заказчика и вообще отзывы о нем.
Рассматривается категория ПО, связанная с построением заказных АИС для управления, учета, контроля чего/кого либо.
1. неутешительная для заказчиков новость: если хочешь получить хороший продукт - будь готов потратить на него большие ресурсы (время, деньги). Варианты startup-го проекта - типа сделайте задешево мне систему, а уже потом я сделаю Вам небо в алмазах - не проходят. Нужно быть заранее готовым к большим начальным тратам: на квалифицированный персонал, оборудование и т.п.
2. вместо построения «воздушных замков», нужно четко себе представлять, что будет автоматизировано, а что нет, и какие преимущества от этого фирма получит (и готова ли она за это платить оговоренную сумму). Т.е. нужно управлять масштабом проекта (в рамках: функциональность/срок реализации), а не бесконечно развивать одну и ту же систему (программистам быстро надоест подобный «безнадежный проект» и скоро они начнут искать себе более интересное место работы)
3. нужно просчитывать риски - что будет, если система не заработает в срок? Вряд ли тут поможет расстрел всех программеров во главе с менеджером проекта, из-за того, что «на почве автоматизации» был взят кредит в банке и отдавать его сейчас нет никакой возможности. ПО - дорогой бизнес, и нужно быть готовым и к неудачам в том числе и заранее предусмотреть неблагоприятный вариант событий. А не высказывать претензии вида: «мы вам поверили, а вы нас бросили в самый тяжелый момент»
4. нужно планировать эволюцию системы - то, что была написана система, получены деньги и благополучно программистами потом потрачены не означает, что разработчики «навечно» привязаны к заказчикам (и к своему уже бывшему проекту). Т.е. нужно четко оговорить, кто будет сопровождать систему, за какие деньги и в течении какого времени. Платить сумму за сопровождение оригинальным разработчикам, или другим. Вообще, сам процесс сопровождения должен быть выгоден программистам (сейчас же это зачастую бесплатный и весьма утомительный процесс – это не собственный опыт, а из наблюдений «за процессом»)
5. была хорошая статья про то, что «новый софт писать вообще не надо» - т.е. большая часть задач уже автоматизирована и не надо заказывать писать системы, которые уже кем-то написаны. Многие бизнес-потребности решаются с помощью MS Office, Internet, средств контроля версий и т.п. Поэтому нужно много раз подумать, какие уникальные конкурентные преимущества даст новая система, которых нет уже в существующих (будет ли это более выгодно в плане финансов или по набору разработанной функциональности и т.п.)
Честно говоря, я долго размышлял, публиковать тезис №5 или нет. Получается, что я отговариваю заказчиков платить мне, как программисту деньги за разработку ПО. Но потом я подумал, что на самом деле, цель программистов (и ИТ-индустрии в целом) - приносить пользу людям (как бы это не наивно звучало). Разрабатываемые проекты должны быть не очередной скучной "инкарнацией" учета склада, товаров, бухгалтерии и т.п. Новые системы должны быть абсолютно уникальны, предлагать нестандартные возможности, нигде ранее не реализованные. В таком проекте программисты будут участвовать не из-за денег, а из-за того, чтобы потом сказать "Я сделал это".
Тогда, и разочарований в программистах (и вообще, в ИТ) у заказчиков будет меньше. Освободившиеся таким образом ресурсы заказчиков вместо "серых, безликих проектов" будут направлены на:
а) приобретение готового лицензионного ПО,
б) консалтинговым фирмам, которые будут анализировать, как максимально эффективным способом построить ИТ-структуру организации,
в) на "интересные проекты", о которых я уже говорил выше.
От такого «повышения цивилизованности» ИТ-рынка, я думаю, выиграют все. Заказчики будут более рационально использовать свои ресурсы, а программисты будут участвовать в более интересных проектах, где нужно будет серьезно работать творчески (а за такую работу намного больше платят, что конечно, не может не порадовать
--
С уважением,
Константин Берлинский
2Новиков Виталий:
Ниже представлено мое личное мнение об ошибках заказчика и вообще отзывы о нем.
Рассматривается категория ПО, связанная с построением заказных АИС для управления, учета, контроля чего/кого либо.
1. неутешительная для заказчиков новость: если хочешь получить хороший продукт - будь готов потратить на него большие ресурсы (время, деньги). Варианты startup-го проекта - типа сделайте задешево мне систему, а уже потом я сделаю Вам небо в алмазах - не проходят. Нужно быть заранее готовым к большим начальным тратам: на квалифицированный персонал, оборудование и т.п.
2. вместо построения «воздушных замков», нужно четко себе представлять, что будет автоматизировано, а что нет, и какие преимущества от этого фирма получит (и готова ли она за это платить оговоренную сумму). Т.е. нужно управлять масштабом проекта (в рамках: функциональность/срок реализации), а не бесконечно развивать одну и ту же систему (программистам быстро надоест подобный «безнадежный проект» и скоро они начнут искать себе более интересное место работы)
3. нужно просчитывать риски - что будет, если система не заработает в срок? Вряд ли тут поможет расстрел всех программеров во главе с менеджером проекта, из-за того, что «на почве автоматизации» был взят кредит в банке и отдавать его сейчас нет никакой возможности. ПО - дорогой бизнес, и нужно быть готовым и к неудачам в том числе и заранее предусмотреть неблагоприятный вариант событий. А не высказывать претензии вида: «мы вам поверили, а вы нас бросили в самый тяжелый момент»
4. нужно планировать эволюцию системы - то, что была написана система, получены деньги и благополучно программистами потом потрачены не означает, что разработчики «навечно» привязаны к заказчикам (и к своему уже бывшему проекту). Т.е. нужно четко оговорить, кто будет сопровождать систему, за какие деньги и в течении какого времени. Платить сумму за сопровождение оригинальным разработчикам, или другим. Вообще, сам процесс сопровождения должен быть выгоден программистам (сейчас же это зачастую бесплатный и весьма утомительный процесс – это не собственный опыт, а из наблюдений «за процессом»)
5. была хорошая статья про то, что «новый софт писать вообще не надо» - т.е. большая часть задач уже автоматизирована и не надо заказывать писать системы, которые уже кем-то написаны. Многие бизнес-потребности решаются с помощью MS Office, Internet, средств контроля версий и т.п. Поэтому нужно много раз подумать, какие уникальные конкурентные преимущества даст новая система, которых нет уже в существующих (будет ли это более выгодно в плане финансов или по набору разработанной функциональности и т.п.)
Честно говоря, я долго размышлял, публиковать тезис №5 или нет. Получается, что я отговариваю заказчиков платить мне, как программисту деньги за разработку ПО. Но потом я подумал, что на самом деле, цель программистов (и ИТ-индустрии в целом) - приносить пользу людям (как бы это не наивно звучало). Разрабатываемые проекты должны быть не очередной скучной "инкарнацией" учета склада, товаров, бухгалтерии и т.п. Новые системы должны быть абсолютно уникальны, предлагать нестандартные возможности, нигде ранее не реализованные. В таком проекте программисты будут участвовать не из-за денег, а из-за того, чтобы потом сказать "Я сделал это".
Тогда, и разочарований в программистах (и вообще, в ИТ) у заказчиков будет меньше. Освободившиеся таким образом ресурсы заказчиков вместо "серых, безликих проектов" будут направлены на:
а) приобретение готового лицензионного ПО,
б) консалтинговым фирмам, которые будут анализировать, как максимально эффективным способом построить ИТ-структуру организации,
в) на "интересные проекты", о которых я уже говорил выше.
От такого «повышения цивилизованности» ИТ-рынка, я думаю, выиграют все. Заказчики будут более рационально использовать свои ресурсы, а программисты будут участвовать в более интересных проектах, где нужно будет серьезно работать творчески (а за такую работу намного больше платят, что конечно, не может не порадовать
--
С уважением,
Константин Берлинский
- Константин Берлинский
- Начинающий
- Сообщения: 6
- Зарегистрирован: 23.06.2004 (Ср) 20:42
- Откуда: Республика Молдова, Кишинев
Константин Берлинский » 17.07.2004 (Сб) 20:12
Здравствуйте!
Т.к. отзывы о книге мне все больше присылают на емайл, а не пишут на форуме, я буду публиковать наиболее интересные письма.
Естественно, с разрешения рецензентов. Думаю, народу будет интересно.
--
С уважением,
Константин Берлинский
----------------------------------------
Friday, July 16, 2004, 10:32:43 PM, Mikhail Tchernomordikov wrote:
MT> Доброй бессонной ночи!
MT> Прежде всего, большое спасибо за интересную книгу! Она
MT> действительно замечательна.
MT> Люблю материалы, где обо всем и понемногу. Они просто необходимы,
MT> чтобы понять общую картину и знать, в каком направлении двигаться
MT> дальше.
MT> Кроме того, это отлично проведенное время для вечера пятницы
MT> (в противополжность известной рекламе "конфет"
MT> С нетерпением жду продолжения, надеюсь, он также будет в пдф
MT> (кстати, по оформлению: все хорошо, вот только заголовок на целую
MT> страницу меня совсем не порадовал).
MT> Также было бы интересно узнать, как Вы(ты) относитесь к инициативе
MT> .NET, которую называют чуть ли не панацеей и революцией а-ля
MT> IBM/360. Просто мечтал бы прочесть книгу на эту тему.
MT> А то у меня с друзьями вечные споры MS-Open SOURCE, хотя сам при
MT> этом являюсь сторонником как одного, так и другого.
MT> Отсюда и вытекает, что идеала не сущесвует, о чем Вы и пишите.
MT> Еще раз спасибо!
--------------------------------------
Здравствуйте!
Спасибо за Ваш отзыв о моей работе.
По поводу "заголовка на целую страницу" - меня он тоже не радует.
Вначале я думал перед каждым описываемым этапом ЖЦ ПО давать краткую справку об этапе:
для чего он нужен, основные участники, цели, действия, полученные артефакты,
"граничные точки" т.п. Но потом я передумал это делать, т.к.: а) материал рассчитан все
же для "продвинутых" ИТ-специалистов и для них все эти вещи были бы очевидны. б) подобная
справочная информация уже описана в RUP-е, который можно скачать с www.rational.com
(они даже триальные диски на халяву присылают). А просто перевести на русский RUP и
опубликовать под "собственным копирайтом", было бы плагиатом.
Что насчет "панацеи и революции", в виде .NET, то могу сказать следующее.
Я последний год работаю с .NET (C#) и пока ничего действительно революционного не заметил.
Есть хороший продукт - IDE, который позволяет писать код на одном из наиболее популярных языков.
Есть куча реализованных возможностей и фич и прочих "полезностей", надерганных с разных языков, IDE и т.п. И только.
Была бы действительно "революция" в ПО, если бы MS выпустила IDE, позволяющая писать
кроссплатформенный код. Но это бы противоречило главному принципу MS -
"в каждый дом по ПК ... с ОС от MS". IMHO, естественно.
Пару месяцев назад я читал документацию по MSSQL и наткнулся на такую фразу:
"MSSQL - обладает настоящей кроссплатформенностью. Его можно установить на WinXP, Win2k, Win98, etc"
Запостил это даже на www.ostrie.ru, но народ шутки не понял.
--
С уважением,
Константин Берлинский
Т.к. отзывы о книге мне все больше присылают на емайл, а не пишут на форуме, я буду публиковать наиболее интересные письма.
Естественно, с разрешения рецензентов. Думаю, народу будет интересно.
--
С уважением,
Константин Берлинский
----------------------------------------
Friday, July 16, 2004, 10:32:43 PM, Mikhail Tchernomordikov wrote:
MT> Доброй бессонной ночи!
MT> Прежде всего, большое спасибо за интересную книгу! Она
MT> действительно замечательна.
MT> Люблю материалы, где обо всем и понемногу. Они просто необходимы,
MT> чтобы понять общую картину и знать, в каком направлении двигаться
MT> дальше.
MT> Кроме того, это отлично проведенное время для вечера пятницы
MT> (в противополжность известной рекламе "конфет"
MT> С нетерпением жду продолжения, надеюсь, он также будет в пдф
MT> (кстати, по оформлению: все хорошо, вот только заголовок на целую
MT> страницу меня совсем не порадовал).
MT> Также было бы интересно узнать, как Вы(ты) относитесь к инициативе
MT> .NET, которую называют чуть ли не панацеей и революцией а-ля
MT> IBM/360. Просто мечтал бы прочесть книгу на эту тему.
MT> А то у меня с друзьями вечные споры MS-Open SOURCE, хотя сам при
MT> этом являюсь сторонником как одного, так и другого.
MT> Отсюда и вытекает, что идеала не сущесвует, о чем Вы и пишите.
MT> Еще раз спасибо!
--------------------------------------
Здравствуйте!
Спасибо за Ваш отзыв о моей работе.
По поводу "заголовка на целую страницу" - меня он тоже не радует
.
Вначале я думал перед каждым описываемым этапом ЖЦ ПО давать краткую справку об этапе:
для чего он нужен, основные участники, цели, действия, полученные артефакты,
"граничные точки" т.п. Но потом я передумал это делать, т.к.: а) материал рассчитан все
же для "продвинутых" ИТ-специалистов и для них все эти вещи были бы очевидны. б) подобная
справочная информация уже описана в RUP-е, который можно скачать с www.rational.com
(они даже триальные диски на халяву присылают). А просто перевести на русский RUP и
опубликовать под "собственным копирайтом", было бы плагиатом.
Что насчет "панацеи и революции", в виде .NET, то могу сказать следующее.
Я последний год работаю с .NET (C#) и пока ничего действительно революционного не заметил
.
Есть хороший продукт - IDE, который позволяет писать код на одном из наиболее популярных языков.
Есть куча реализованных возможностей и фич и прочих "полезностей", надерганных с разных языков, IDE и т.п. И только.
Была бы действительно "революция" в ПО, если бы MS выпустила IDE, позволяющая писать
кроссплатформенный код. Но это бы противоречило главному принципу MS -
"в каждый дом по ПК ... с ОС от MS"
. IMHO, естественно.
Пару месяцев назад я читал документацию по MSSQL и наткнулся на такую фразу:
"MSSQL - обладает настоящей кроссплатформенностью. Его можно установить на WinXP, Win2k, Win98, etc"
Запостил это даже на www.ostrie.ru, но народ шутки не понял
.
--
С уважением,
Константин Берлинский
- Константин Берлинский
- Начинающий
- Сообщения: 6
- Зарегистрирован: 23.06.2004 (Ср) 20:42
- Откуда: Республика Молдова, Кишинев
Еще одна переписка с читателем
Константин Берлинский » 23.08.2004 (Пн) 21:31
Еще одна переписка с читателем (в календарном порядке):
-------------------------------
Wednesday, August 18, 2004, 12:56:44 Alexandr Antonov wrote:
AA> Здравствуйте, Константин.
AA> Я только что прочитал Вашу книгу "Набор серебряных пуль - Справочник
AA> удачных проектных решений при разработке ПО".
AA> Книга произвела на меня довольно сильное впечатление. И хотя я
AA> довольно часто читаю различные книги, статьи, форумы на данную тему,
AA> но именно Ваш труд как-то по особенному меня задел (в хорошем смысле).
AA> С первых несколько страниц бросились в глаза несколько довольно
AA> смелых, прямо таки дерзких утверждений, которые однако выглядят
AA> довольно обоснованными и разумными с моей личной точки зрения.
AA> Например, главный тезис книги: "методологий не существует".
AA> Также поразило, что многие утверждения книги прямо таки полностью
AA> совпадают с моими личными выводами, сделанными из профессионального опыта.
AA> Очень понравилась и согласуется с моими личными выводами идея про то,
AA> что нет совершенных методологий, а все они подходят в той или иной
AA> степени только при определённых обстоятельствах, и из каждой методологии
AA> надо брать лучшее.
AA> Я также согласен с Вашим выводами относительно XP. Сам я знаком с ним
AA> только теоретически, и меня всегда возмущала крайняя категоричность
AA> положений этой методологии и высказываний её приверженцев. Несомненно
AA> есть в XP очень разумные идеи, но нельзя его, по моему, применять всегда и
AA> полностью, без оглядки. Особенно у меня вызывают критику положения
AA> "минимум проектной документации и диаграмм". Мне, кажется, для
AA> проектов длиной хотя бы в несколько месяцев это абсолютно неприемлемо,
AA> даже если команда разработчиков состоит из одного человека.
AA> Также меня прямо таки задела за живое библиография.
AA> Во-первых: просмотрев её, я в очередной раз схватился за голову со
AA> словами: "О ужас, какой я темный человек, а ещё называю себя
AA> профессионалом! Сколько необходимых книг я ещё не прочитал! Немедленно
AA> в книжный магазин!". Если все книги и статьи из данной библиографии Вы
AA> прочитали лично в полном объеме, то примите моё искреннее и глубокое
AA> уважение! Сам я от Вас в этом плане значительно отстаю, хотя я на один
AA> год и старше.
AA> Во-вторых: я себе лично определил, что данная библиография подходит
AA> мне, как нельзя лучше, как план для чтения на ближайшие годы.
AA> Я бы сказал, что данная библиография имеет самостоятельную,
AA> независимую от самой книги, образовательную ценность, как ориентир для
AA> чтения для начинающих специалистов и специалистов
AA> среднего уровня по разработке программного обеспечения.
AA> Ну, хватит о хорошем. Перейдём к критике книги. Лёгкой критике.
AA> Позволю себе высказать несколько замечаний по частям книги, с которыми
AA> я немного не согласен (или просто не понял?).
AA> Сначала, небольшие замечания по структуре книги. Глава 7.3.9
AA> "Расслоение системы" показалась мне находящейся не на своем месте.
AA> Во-первых, сразу бросилось в глаза, что принцип Model-View-Controller
AA> является паттерном проектирования, и выглядит нелогично, что есть
AA> отдельная глава "Паттерны проектирования", но MVC выделен отдельно,
AA> причем в другом месте книги. Мне кажется эти две главы должны быть как
AA> то явно связаны, например идти одна за другой или ссылаться друг на друга.
AA> Также сама идея "расслоения системы", по моему, практически идентична
AA> принципу "создавать 'правильные' объекты" (или является его подмножеством),
AA> описанному в главе 7.3.1 "Создание объектов". Разве одной из целей создания
AA> "правильных" объектов не является хорошее расслоение системы на
AA> классы\пакеты\подсистемы с минимальным зацеплением друг с другом для
AA> того, чтобы работал главный принцип борьбы со сложность "разделяй и властвуй"?
AA> Таким образом, мне кажется, что главы 7.3.1 и 7.3.9 должны быть как то
AA> явно связаны или объединены.
AA> Теперь о минусах ООП, приведённых вами в главе 7.3.10 "ООП". К моему
AA> удивлению они у меня вызвали некоторое несогласие.
AA> Рассмотрим из по отдельности:
AA> 1) "снижение скорости выполнения методов". Звучит очень спорно. Если я
AA> правильно понял, Вы имеете в виду накладные издержки при вызове
AA> виртуальных методов? Много раз встречал споры по этому поводу и мой
AA> личный вывод таков: значительного снижения скорости здесь нет (по сравнению с
AA> процедурным стилем). Если я всё правильно понял, то готов
AA> подискутировать на данную тему.
AA> 2) "увеличение размера программы". Имеете ли Вы виду увеличение
AA> исходных текстов? Если да, то я посмею поспорить. По авторитетным мнениям
AA> (кажется Г.Буч) и по своим личным выводам дело обстоит как раз
AA> наоборот. Хорошая (именно хорошая) ОО программная архитектура отличается,
AA> по моему, как раз таки лаконичностью, с которой можно реализовать
AA> каждый метод программы. Вспомните хотя бы цитату из вашей книги: "Код
AA> каждого метода должен быть не более трех строк".
AA> Также, заметьте, одна из главных целей ООП - это повторное
AA> использование, а повторное использование, очевидно, ведет только к
AA> уменьшению суммарного размера исходных текстов.
AA> 3) "повышение сложности системы". Каким образом? Ведь главная цель ООП -
AA> это победа над сложностью предметной области, т.е. упрощение
AA> всей системы за счет грамотной инкапсуляции, распределения
AA> обязанностей программных сущностей (классов, модулей, ...) и т.д.
AA> Может я не так Вас понял?
AA> 4) "значительный рост требований к квалификации разработчиков". С этим
AA> согласен, но это и минусом ООП назвать сложно. ООП в первую очередь
AA> необходим для разработки сложных систем, а чем сложнее система, тем
AA> выше рост требований к квалификации разработчиков, независимо от
AA> используемой методологии. Таком образом первопричина роста требований
AA> к квалификации, - по моему, не в ОПП, а в сложности систем для которых
AA> ООП создан.
AA> Ещё раз повторюсь, книга очень понравилась. Единственно, так это остаётся
AA> ощущение не полноты книги. Такая серьёзная тема так и просит больше
AA> объема, деталей и охвата.
AA> Очень надеюсь, что мои теплые слова добавят вам, хотя бы немного,
AA> творческого и профессионального вдохновения, а моя критика поможет
AA> сделать следующую версии книгу ещё полезней и интересней.
AA> С глубоким уважением, Александр Антонов.
-------------------------------
Здравствуйте!
AA> Сначала, небольшие замечания по структуре книги. Глава 7.3.9
AA> "Расслоение системы" показалась мне находящейся не на своем месте.
Отчасти с Вами согласен. Но я решил выделить MVC в отдельную главу,
т.к. считаю его не просто паттерном, а скорее "философией", которая
помогает строить "правильную" структуру системы.
Паттерны, по моему мнению, это более "мелкие" кирпичики. Поэтому все
они были помещены в одну главу.
AA> отдельная глава "Паттерны проектирования", но MVC выделен отдельно,
AA> причем в другом месте книги. Мне кажется эти две главы должны быть как
AA> то явно связаны, например идти одна за другой или ссылаться друг на друга.
На самом деле в плане написания книги у меня был записан отдельный пункт -
отсортировать главы в к-л логическом порядке. Но в спешке я забыл это сделать
AA> Также сама идея "расслоения системы", по моему, практически идентична
AA> принципу "создавать 'правильные' объекты" (или является его подмножеством),
AA> ...
AA> Таким образом, мне кажется, что главы 7.3.1 и 7.3.9 должны быть как то
AA> явно связаны или объединены.
То, что принцип создавать "правильные" объекты является подмножеством
"расслоения системы" - полностью согласен. На момент написания книги я
о такой связи не думал. Но в принципе, 7.3.1, также как и паттерны,
можно считать идеей более мелкого масштаба, чем 7.3.9 (следовательно
глава 7.3.1 также имеет право на отдельное существование).
AA> 1) "снижение скорости выполнения методов". Звучит очень спорно. Если я
AA> ...
AA> виртуальных методов? Много раз встречал споры по этому поводу и мой
Честно говоря, этот пункт (минус ООП) я написал исходя из тех споров, о
которых Вы говорите, в Интернете, на форумах, в различных книгах и
статьях. Т.е. лично на практике скорость выполнения методов (исходя из
того, что в ООП методы могут быть перегруженными, отнаследованными из
базовых классов и т.п.) я не проверял.
Поэтому в данном случае, могу признать некоторую "сырость" главы про
ООП в общем и пункт про скорость методов в частности.
Надо было больше работать над материалом
AA> 2) "увеличение размера программы". Имеете ли Вы виду увеличение
AA> исходных текстов? Если да, то я посмею поспорить. По авторитетным мнениям
Имеется в виду размер исполняемого кода (EXE, DLL, etc).
Впрочем, на данный момент, размер исполняемого кода программы уже не
важен (главное, надежность, функциональность и гибкость ПО).
Поэтому, этот аргумент, медленно, но верно устаревает.
AA> 3) "повышение сложности системы". Каким образом? Ведь главная цель ООП -
AA> это победа над сложностью предметной области, т.е. упрощение
AA> всей системы за счет грамотной инкапсуляции, распределения
AA> обязанностей программных сущностей (классов, модулей, ...) и т.д.
Все понятно, если речь идет именно о ГРАМОТНОЙ инкапсуляции и т.п.
Чаще всего это не так. По моему мнению, среднему и начинающему
разработчикам значительно легче разобраться в "плоской" структуре
программы, т.е. наборе функций, вызываемых из разных форм + набор
глобальных переменных, чем держать в голове "объемную" модель
программы - т.е. понимать как в текущем контексте работают объекты
разных классов, когда вызывается базовый метод, а когда метод потомка,
что кому делегируется, какие были применены паттерны и т.п.
AA> 4) "значительный рост требований к квалификации разработчиков". С этим
AA> согласен, но это и минусом ООП назвать сложно. ООП в первую очередь
AA> необходим для разработки сложных систем, а чем сложнее система, тем
AA> выше рост требований к квалификации разработчиков, независимо от
AA> используемой методологии. Таком образом первопричина роста требований
AA> к квалификации, - по моему, не в ОПП, а в сложности систем для которых
AA> ООП создан.
Согласен наполовину. Всем понятно, что С++ более мощный, чем
VBasic, но тем не менее, много людей пишут на ВБ.
В ситуации, когда ПО нужно создавать как можно быстрее, а средний
возраст разработчиков в районе 25 лет, то повышение требований к
квалификации (и времени на изучение и получение опыта)
среды/языка/методики можно считать минусом.
Хотя насчет первопричины согласен.
AA> Такая серьёзная тема так и просит больше объема, деталей и охвата.
Если бы мой рабочий график это позволял... если бы дали отпуск...
больше недели...оплачиваемый... то тогда конечно
С уважением,
Константин Берлинский
-------------------------------
Thursday, August 19, 2004, 4:56:21 Alexandr Antonov wrote:
Доброго времени суток.
N> Честно говоря, этот пункт (минус ООП) я написал исходя из тех споров, о
N> …………
N> Надо было больше работать над материалом
Про "сырость" главы согласен. Я, честно говоря, вообще не был уверен
правильно ли я понял, некоторые утверждения этой главы, в частности про минусы ООП.
Также про скорость могу добавить следующее: по моему мнению,
программы, построенные по всем принципам ООП могут быть более
медленными, чем их процедурно построенные функциональные аналоги,
потому что в ООП программе очень частым явлением является
делегирование, а точнее даже цепочки делегирования, порой довольно длинные.
Происходит это обычно (как Вы и сами знаете) из-за того, что порой
между клиентом и сервером некоторой услуги находятся несколько уровней
абстракции или "слоев" системы. Прямой вызов клиентом метода сервера
был бы значительно эффективнее, но это противоречит главным принципам ООП:
инкапсуляции, минимизации зацепления и т.д.
Мне кажется, это действительно является минусом ООП, причем более
весомым, чем накладные расходы на вызов виртуального метода, которые на
самом деле я считаю абсолютно несущественными, но правда, именно
относительно С++. (готов это обсудить более подробно, есть есть
желание). Про другие языке говорить не буду.
Кстати, про скорость вызова виртуальных методов есть хороший тест здесь
http://www.rsdn.ru/article/devtools/perftest.xml
Его нельзя назвать всеобъемлющим, но все же он подтверждает мои чисто
теоретические выводы (относительно C++ и Object Pascal), хотя про одну
только фактическую скорость рассуждать здесь нельзя. Надо ещё
учитывать, что процедурная программа должна содержать некий дополнительный
код, который эквивалентен механизму вызова виртуальной функции, например
"поле типа" (термин Страуструпа) и его анализ, например, с помощью оператора case.
AA>> 2) "увеличение размера программы". Имеете ли Вы виду увеличение
AA>> исходных текстов? Если да, то я посмею поспорить. По авторитетным мнениям
N> Имеется в виду размер исполняемого кода (EXE, DLL, etc).
С этим частично согласен. Но мне кажется, в наше время больше на
размер исполняемого кода влияют сторонние библиотеки статически
подключаемые к проекту. Также есть у меня подозрение, что в программах
именно на C++ размер хорошо раздувают templates, если один и тот же
template инстанцирован в проекте большим множеством разных типов.
N> Впрочем, на данный момент, размер исполняемого кода программы уже не
N> важен (главное, надежность, функциональность и гибкость ПО).
N> Поэтому, этот аргумент, медленно, но верно устаревает.
Полностью согласен. Я думаю, "минусы" про скорость устаревают по той
же причине.
N> Все понятно, если речь идет именно о ГРАМОТНОЙ инкапсуляции и т.п.
N> Чаще всего это не так.
Не могу спорить.
N> По моему мнению, среднему и начинающему разработчикам значительно в "плоской"
N> ………….
N> что кому делегируется, какие были применены паттерны и т.п.
Так для этого диаграммы и текстовая документация и нужны! (ещё один
камешек в огород XP). Ни один гений не удержит в голове всю архитектуру
большого проекта.
Так что в плоской структуре без проектной документации все же будет
разобраться сложнее, чем в хотя бы поверхностно документированной ООП
структуре. А документация, а именно различные диаграммы, - это один из
неотъемлемых и обязательных аспектов ООП.
Вспомните хотя бы горячо любимый новичками Delphi. Структуру VCL
тривиальной назвать нельзя, размер тоже немаленький, но все же хорошая
документация делает использование VCL довольно простым.
Так что с "повышением сложности системы" не могу согласится.
N> Спасибо еще раз за такую детальную и аргументированную рецензию.
Рад, что угодил. С интересным человеком и коллегой пообщаться и
интересно и полезно. Хотя я обычно письма и реплики в форумы пишу
редко, но, повторюсь, ваша книга как-то задела меня за живое.
N> Если хотите дискуссию сделать публичной, то можете запостить Ваше письмо и мой ответ на форум, где обсуждается книга: http://bbs.vbstreets.ru/viewtopic.php?t=8337.
Я только "за", но данная страница выдаёт у меня серверную SQL ошибку.
Буду только рад, если вы запостите нашу переписку и расскажите, как
все-таки на этот форум зайти.
Меня несколько позабавило название сервера vbstreets. Похоже сайт про
VB, но вопросы обсуждаемые именно в нашей переписке далековаты от мира
VB, хотя сама книга, конечно же, актуальна для всех.
С уважением, Александр Антонов.
-------------------------------
Wednesday, August 18, 2004, 12:56:44 Alexandr Antonov wrote:
AA> Здравствуйте, Константин.
AA> Я только что прочитал Вашу книгу "Набор серебряных пуль - Справочник
AA> удачных проектных решений при разработке ПО".
AA> Книга произвела на меня довольно сильное впечатление. И хотя я
AA> довольно часто читаю различные книги, статьи, форумы на данную тему,
AA> но именно Ваш труд как-то по особенному меня задел (в хорошем смысле).
AA> С первых несколько страниц бросились в глаза несколько довольно
AA> смелых, прямо таки дерзких утверждений, которые однако выглядят
AA> довольно обоснованными и разумными с моей личной точки зрения.
AA> Например, главный тезис книги: "методологий не существует".
AA> Также поразило, что многие утверждения книги прямо таки полностью
AA> совпадают с моими личными выводами, сделанными из профессионального опыта.
AA> Очень понравилась и согласуется с моими личными выводами идея про то,
AA> что нет совершенных методологий, а все они подходят в той или иной
AA> степени только при определённых обстоятельствах, и из каждой методологии
AA> надо брать лучшее.
AA> Я также согласен с Вашим выводами относительно XP. Сам я знаком с ним
AA> только теоретически, и меня всегда возмущала крайняя категоричность
AA> положений этой методологии и высказываний её приверженцев. Несомненно
AA> есть в XP очень разумные идеи, но нельзя его, по моему, применять всегда и
AA> полностью, без оглядки. Особенно у меня вызывают критику положения
AA> "минимум проектной документации и диаграмм". Мне, кажется, для
AA> проектов длиной хотя бы в несколько месяцев это абсолютно неприемлемо,
AA> даже если команда разработчиков состоит из одного человека.
AA> Также меня прямо таки задела за живое библиография.
AA> Во-первых: просмотрев её, я в очередной раз схватился за голову со
AA> словами: "О ужас, какой я темный человек, а ещё называю себя
AA> профессионалом! Сколько необходимых книг я ещё не прочитал! Немедленно
AA> в книжный магазин!". Если все книги и статьи из данной библиографии Вы
AA> прочитали лично в полном объеме, то примите моё искреннее и глубокое
AA> уважение! Сам я от Вас в этом плане значительно отстаю, хотя я на один
AA> год и старше.
AA> Во-вторых: я себе лично определил, что данная библиография подходит
AA> мне, как нельзя лучше, как план для чтения на ближайшие годы.
AA> Я бы сказал, что данная библиография имеет самостоятельную,
AA> независимую от самой книги, образовательную ценность, как ориентир для
AA> чтения для начинающих специалистов и специалистов
AA> среднего уровня по разработке программного обеспечения.
AA> Ну, хватит о хорошем. Перейдём к критике книги. Лёгкой критике.
AA> Позволю себе высказать несколько замечаний по частям книги, с которыми
AA> я немного не согласен (или просто не понял?).
AA> Сначала, небольшие замечания по структуре книги. Глава 7.3.9
AA> "Расслоение системы" показалась мне находящейся не на своем месте.
AA> Во-первых, сразу бросилось в глаза, что принцип Model-View-Controller
AA> является паттерном проектирования, и выглядит нелогично, что есть
AA> отдельная глава "Паттерны проектирования", но MVC выделен отдельно,
AA> причем в другом месте книги. Мне кажется эти две главы должны быть как
AA> то явно связаны, например идти одна за другой или ссылаться друг на друга.
AA> Также сама идея "расслоения системы", по моему, практически идентична
AA> принципу "создавать 'правильные' объекты" (или является его подмножеством),
AA> описанному в главе 7.3.1 "Создание объектов". Разве одной из целей создания
AA> "правильных" объектов не является хорошее расслоение системы на
AA> классы\пакеты\подсистемы с минимальным зацеплением друг с другом для
AA> того, чтобы работал главный принцип борьбы со сложность "разделяй и властвуй"?
AA> Таким образом, мне кажется, что главы 7.3.1 и 7.3.9 должны быть как то
AA> явно связаны или объединены.
AA> Теперь о минусах ООП, приведённых вами в главе 7.3.10 "ООП". К моему
AA> удивлению они у меня вызвали некоторое несогласие.
AA> Рассмотрим из по отдельности:
AA> 1) "снижение скорости выполнения методов". Звучит очень спорно. Если я
AA> правильно понял, Вы имеете в виду накладные издержки при вызове
AA> виртуальных методов? Много раз встречал споры по этому поводу и мой
AA> личный вывод таков: значительного снижения скорости здесь нет (по сравнению с
AA> процедурным стилем). Если я всё правильно понял, то готов
AA> подискутировать на данную тему.
AA> 2) "увеличение размера программы". Имеете ли Вы виду увеличение
AA> исходных текстов? Если да, то я посмею поспорить. По авторитетным мнениям
AA> (кажется Г.Буч) и по своим личным выводам дело обстоит как раз
AA> наоборот. Хорошая (именно хорошая) ОО программная архитектура отличается,
AA> по моему, как раз таки лаконичностью, с которой можно реализовать
AA> каждый метод программы. Вспомните хотя бы цитату из вашей книги: "Код
AA> каждого метода должен быть не более трех строк".
AA> Также, заметьте, одна из главных целей ООП - это повторное
AA> использование, а повторное использование, очевидно, ведет только к
AA> уменьшению суммарного размера исходных текстов.
AA> 3) "повышение сложности системы". Каким образом? Ведь главная цель ООП -
AA> это победа над сложностью предметной области, т.е. упрощение
AA> всей системы за счет грамотной инкапсуляции, распределения
AA> обязанностей программных сущностей (классов, модулей, ...) и т.д.
AA> Может я не так Вас понял?
AA> 4) "значительный рост требований к квалификации разработчиков". С этим
AA> согласен, но это и минусом ООП назвать сложно. ООП в первую очередь
AA> необходим для разработки сложных систем, а чем сложнее система, тем
AA> выше рост требований к квалификации разработчиков, независимо от
AA> используемой методологии. Таком образом первопричина роста требований
AA> к квалификации, - по моему, не в ОПП, а в сложности систем для которых
AA> ООП создан.
AA> Ещё раз повторюсь, книга очень понравилась. Единственно, так это остаётся
AA> ощущение не полноты книги. Такая серьёзная тема так и просит больше
AA> объема, деталей и охвата.
AA> Очень надеюсь, что мои теплые слова добавят вам, хотя бы немного,
AA> творческого и профессионального вдохновения, а моя критика поможет
AA> сделать следующую версии книгу ещё полезней и интересней.
AA> С глубоким уважением, Александр Антонов.
-------------------------------
Здравствуйте!
AA> Сначала, небольшие замечания по структуре книги. Глава 7.3.9
AA> "Расслоение системы" показалась мне находящейся не на своем месте.
Отчасти с Вами согласен. Но я решил выделить MVC в отдельную главу,
т.к. считаю его не просто паттерном, а скорее "философией", которая
помогает строить "правильную" структуру системы.
Паттерны, по моему мнению, это более "мелкие" кирпичики. Поэтому все
они были помещены в одну главу.
AA> отдельная глава "Паттерны проектирования", но MVC выделен отдельно,
AA> причем в другом месте книги. Мне кажется эти две главы должны быть как
AA> то явно связаны, например идти одна за другой или ссылаться друг на друга.
На самом деле в плане написания книги у меня был записан отдельный пункт -
отсортировать главы в к-л логическом порядке. Но в спешке я забыл это сделать
AA> Также сама идея "расслоения системы", по моему, практически идентична
AA> принципу "создавать 'правильные' объекты" (или является его подмножеством),
AA> ...
AA> Таким образом, мне кажется, что главы 7.3.1 и 7.3.9 должны быть как то
AA> явно связаны или объединены.
То, что принцип создавать "правильные" объекты является подмножеством
"расслоения системы" - полностью согласен. На момент написания книги я
о такой связи не думал. Но в принципе, 7.3.1, также как и паттерны,
можно считать идеей более мелкого масштаба, чем 7.3.9 (следовательно
глава 7.3.1 также имеет право на отдельное существование).
AA> 1) "снижение скорости выполнения методов". Звучит очень спорно. Если я
AA> ...
AA> виртуальных методов? Много раз встречал споры по этому поводу и мой
Честно говоря, этот пункт (минус ООП) я написал исходя из тех споров, о
которых Вы говорите, в Интернете, на форумах, в различных книгах и
статьях. Т.е. лично на практике скорость выполнения методов (исходя из
того, что в ООП методы могут быть перегруженными, отнаследованными из
базовых классов и т.п.) я не проверял.
Поэтому в данном случае, могу признать некоторую "сырость" главы про
ООП в общем и пункт про скорость методов в частности.
Надо было больше работать над материалом
AA> 2) "увеличение размера программы". Имеете ли Вы виду увеличение
AA> исходных текстов? Если да, то я посмею поспорить. По авторитетным мнениям
Имеется в виду размер исполняемого кода (EXE, DLL, etc).
Впрочем, на данный момент, размер исполняемого кода программы уже не
важен (главное, надежность, функциональность и гибкость ПО).
Поэтому, этот аргумент, медленно, но верно устаревает.
AA> 3) "повышение сложности системы". Каким образом? Ведь главная цель ООП -
AA> это победа над сложностью предметной области, т.е. упрощение
AA> всей системы за счет грамотной инкапсуляции, распределения
AA> обязанностей программных сущностей (классов, модулей, ...) и т.д.
Все понятно, если речь идет именно о ГРАМОТНОЙ инкапсуляции и т.п.
Чаще всего это не так. По моему мнению, среднему и начинающему
разработчикам значительно легче разобраться в "плоской" структуре
программы, т.е. наборе функций, вызываемых из разных форм + набор
глобальных переменных, чем держать в голове "объемную" модель
программы - т.е. понимать как в текущем контексте работают объекты
разных классов, когда вызывается базовый метод, а когда метод потомка,
что кому делегируется, какие были применены паттерны и т.п.
AA> 4) "значительный рост требований к квалификации разработчиков". С этим
AA> согласен, но это и минусом ООП назвать сложно. ООП в первую очередь
AA> необходим для разработки сложных систем, а чем сложнее система, тем
AA> выше рост требований к квалификации разработчиков, независимо от
AA> используемой методологии. Таком образом первопричина роста требований
AA> к квалификации, - по моему, не в ОПП, а в сложности систем для которых
AA> ООП создан.
Согласен наполовину. Всем понятно, что С++ более мощный, чем
VBasic, но тем не менее, много людей пишут на ВБ.
В ситуации, когда ПО нужно создавать как можно быстрее, а средний
возраст разработчиков в районе 25 лет, то повышение требований к
квалификации (и времени на изучение и получение опыта)
среды/языка/методики можно считать минусом.
Хотя насчет первопричины согласен.
AA> Такая серьёзная тема так и просит больше объема, деталей и охвата.
Если бы мой рабочий график это позволял... если бы дали отпуск...
больше недели...оплачиваемый...
то тогда конечно
С уважением,
Константин Берлинский
-------------------------------
Thursday, August 19, 2004, 4:56:21 Alexandr Antonov wrote:
Доброго времени суток.
N> Честно говоря, этот пункт (минус ООП) я написал исходя из тех споров, о
N> …………
N> Надо было больше работать над материалом
Про "сырость" главы согласен. Я, честно говоря, вообще не был уверен
правильно ли я понял, некоторые утверждения этой главы, в частности про минусы ООП.
Также про скорость могу добавить следующее: по моему мнению,
программы, построенные по всем принципам ООП могут быть более
медленными, чем их процедурно построенные функциональные аналоги,
потому что в ООП программе очень частым явлением является
делегирование, а точнее даже цепочки делегирования, порой довольно длинные.
Происходит это обычно (как Вы и сами знаете) из-за того, что порой
между клиентом и сервером некоторой услуги находятся несколько уровней
абстракции или "слоев" системы. Прямой вызов клиентом метода сервера
был бы значительно эффективнее, но это противоречит главным принципам ООП:
инкапсуляции, минимизации зацепления и т.д.
Мне кажется, это действительно является минусом ООП, причем более
весомым, чем накладные расходы на вызов виртуального метода, которые на
самом деле я считаю абсолютно несущественными, но правда, именно
относительно С++. (готов это обсудить более подробно, есть есть
желание). Про другие языке говорить не буду.
Кстати, про скорость вызова виртуальных методов есть хороший тест здесь
http://www.rsdn.ru/article/devtools/perftest.xml
Его нельзя назвать всеобъемлющим, но все же он подтверждает мои чисто
теоретические выводы (относительно C++ и Object Pascal), хотя про одну
только фактическую скорость рассуждать здесь нельзя. Надо ещё
учитывать, что процедурная программа должна содержать некий дополнительный
код, который эквивалентен механизму вызова виртуальной функции, например
"поле типа" (термин Страуструпа) и его анализ, например, с помощью оператора case.
AA>> 2) "увеличение размера программы". Имеете ли Вы виду увеличение
AA>> исходных текстов? Если да, то я посмею поспорить. По авторитетным мнениям
N> Имеется в виду размер исполняемого кода (EXE, DLL, etc).
С этим частично согласен. Но мне кажется, в наше время больше на
размер исполняемого кода влияют сторонние библиотеки статически
подключаемые к проекту. Также есть у меня подозрение, что в программах
именно на C++ размер хорошо раздувают templates, если один и тот же
template инстанцирован в проекте большим множеством разных типов.
N> Впрочем, на данный момент, размер исполняемого кода программы уже не
N> важен (главное, надежность, функциональность и гибкость ПО).
N> Поэтому, этот аргумент, медленно, но верно устаревает.
Полностью согласен. Я думаю, "минусы" про скорость устаревают по той
же причине.
N> Все понятно, если речь идет именно о ГРАМОТНОЙ инкапсуляции и т.п.
N> Чаще всего это не так.
Не могу спорить.
N> По моему мнению, среднему и начинающему разработчикам значительно в "плоской"
N> ………….
N> что кому делегируется, какие были применены паттерны и т.п.
Так для этого диаграммы и текстовая документация и нужны! (ещё один
камешек в огород XP). Ни один гений не удержит в голове всю архитектуру
большого проекта.
Так что в плоской структуре без проектной документации все же будет
разобраться сложнее, чем в хотя бы поверхностно документированной ООП
структуре. А документация, а именно различные диаграммы, - это один из
неотъемлемых и обязательных аспектов ООП.
Вспомните хотя бы горячо любимый новичками Delphi. Структуру VCL
тривиальной назвать нельзя, размер тоже немаленький, но все же хорошая
документация делает использование VCL довольно простым.
Так что с "повышением сложности системы" не могу согласится.
N> Спасибо еще раз за такую детальную и аргументированную рецензию.
Рад, что угодил. С интересным человеком и коллегой пообщаться и
интересно и полезно. Хотя я обычно письма и реплики в форумы пишу
редко, но, повторюсь, ваша книга как-то задела меня за живое.
N> Если хотите дискуссию сделать публичной, то можете запостить Ваше письмо и мой ответ на форум, где обсуждается книга: http://bbs.vbstreets.ru/viewtopic.php?t=8337.
Я только "за", но данная страница выдаёт у меня серверную SQL ошибку.
Буду только рад, если вы запостите нашу переписку и расскажите, как
все-таки на этот форум зайти.
Меня несколько позабавило название сервера vbstreets. Похоже сайт про
VB, но вопросы обсуждаемые именно в нашей переписке далековаты от мира
VB, хотя сама книга, конечно же, актуальна для всех.
С уважением, Александр Антонов.
- Константин Берлинский
- Начинающий
- Сообщения: 6
- Зарегистрирован: 23.06.2004 (Ср) 20:42
- Откуда: Республика Молдова, Кишинев
Публикация книги "НСП" на англоязычном сайте
Константин Берлинский » 02.09.2004 (Чт) 22:51
Книга переведена на английский язык.
Пугаю буржуев своим английским (при помощи переводчика) по адресу:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=4e05f8e5-57a1-4c53-a544-6e8277788276
(также, материал можно найти в гугле через фразу "SILVER BULLETS TOOLKIT" - под таким названием опубликована книга).
Пугаю буржуев своим английским (при помощи переводчика) по адресу:
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=4e05f8e5-57a1-4c53-a544-6e8277788276
(также, материал можно найти в гугле через фразу "SILVER BULLETS TOOLKIT" - под таким названием опубликована книга).
- udpn
- Обычный пользователь
- Сообщения: 51
- Зарегистрирован: 24.07.2007 (Вт) 11:43
udpn » 05.08.2007 (Вс) 21:33
Странно, что книгу никто не читал больше года (по крайней мере топик с тех пор не обновлялся). Спасибо автору за столь точное изъяснение принципов работы над многопользовательскими проектами.
Минусы:
- Много "воды" в начале, относящейся скорее к автору, нежели к читателю
- Книга расчитана на понимающего читателя - необходимы некоторые знания, также не хватает отдельного раздела для списка сокращений
Книгу сохранил в е-архиве, буду рекомендовать друзьям.
Минусы:
- Много "воды" в начале, относящейся скорее к автору, нежели к читателю
- Книга расчитана на понимающего читателя - необходимы некоторые знания, также не хватает отдельного раздела для списка сокращений
Книгу сохранил в е-архиве, буду рекомендовать друзьям.
Не ищите смысла там, где его не ложили (c) проф. В.В. Горяйнов
- ks_rew
- Начинающий
- Сообщения: 1
- Зарегистрирован: 26.07.2009 (Вс) 22:52
Re: Обсуждение книги «Набор серебряных пуль»
ks_rew » 26.07.2009 (Вс) 22:59
Книга супер!!! Прочитала за 2 часа почти не отрываясь. Много полезной информации для размышлений.
Сообщений: 14
• Страница 1 из 1
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 32