Отправляет email-рассылки с помощью сервиса Sendsay

Технологии разработки программ

Рассылка закрыта

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Март 2000   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
29.03.2000
23:21:35
23:21:35
30
31
Автор Гость

Статистика

11.541 подписчиков
за неделю
←   Все выпуски   →

Служба Рассылок Городского Кота


Служба Рассылок Городского Кота

Здравствуйте, уважаемые подписчики.

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

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

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

Еще раз хочу воспользоваться своим положением и призвать ВСЕХ ВАС к активному сотрудничеству. Я буду рад слышать (читать) от вас:

- примеры создания простых, относительно сложных , сложных систем и программ

- примеры использования различных CASE средств

- руководства к различным CASE средствам

- примеры применения новых технологий в проектировании систем в различных предметных областях

- ссылки или предложения различных электронных копий книг, посвященных технологиям написания программ (структурное программирование, модульное программирование, объектный анализ, CASE средства и пр.)

- ваш опыт (можете стать автором целого выпуска рассылки)

- различные материалы, посвященные теоретическим и практическим приемам разработки программ (тоже можете стать авторами ;-))

- вашу критику

- ваши предложения

- ВАШИ ВОПРОСЫ

- ваши отзывы о рассылке

- ваши ответы

- прочее

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

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

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

---------------------------------------------------

Итак, в прошлый раз мы затронули вопросы: кто такой хороший программист, какая программа может считаться хорошей, почему применение CASE средств не столь развито в России.

На первые два вопроса: Кто такой хороший программист ? и Что такое хорошая программа ? большинство ответило: что хороший программист это человек, который пишет хорошие программы, а хорошие программы пишет только хороший программист. Интересный ответ в стиле женской логики (я не имею против такой логики и вашего мнения ничего).

Но были и более интересные ответы, с которыми я наиболее согласен и даже решил опубликовать их:

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

Далее в виде тезисов о программировании в общем:
1. Разработка программы в виде решения поставленной задачи - начальный путь обучения программированию как профессии.

2. На определенном этапе приходит осознание того, что любая программа - система, живущая в реальном мире с полным комплексом взамосвязи с ним. (Помните это - "Программа, не выдающая результат лишена смысла. Если программа выдает результат, она, несомненно, решает какую-то задачу" ?)

3. Способность создания нечто жизнеспособного для реального мира вопрос личностного мироощущения создателя, т.к. программист строит некоторый мир, где нет ограничений физических законов. Из какой-то статьи: " ...неработающая программа бросает вызов программисту как личности...".

4. Личностное мироощущение, философия - как это ни странно - очередной этап обучения программированию. Любая операционная среда (вместе с маркетинговой политикой фирмы-создателя) отражает определенное течение жизненной философии - поэтому спор между приверженцами различных операционных сред - сознательно не употребляю термин "система" - беспредметен, как спор между любителем мяса и любителем яблок. Ну любит - и все тут.

5. Вживание в операционную среду, принятие ее законов, условностей, ограничений - процесс иногда болезненный и сложность его скрывается фривольным тоном заявлений всякого рода "обучалок" - Окна за 24 часа! - Ага, новый мир за сутки жизни. Наверное отсюда у п рограммистов есть бессознательный страх, вплоть до блокировок, перед осмыслением общей идеи операционной среды и что она делает с его осознанием себя по градациям "Я-как Я", "Я- как Мы", "Я-как Чужой". Отсюда и уход только в технические подробности и наслаждение красотой алгоритма. Отсюда и принятие операционной среды как религии.

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

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

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

9. CASE-средства позволили аналитику САМОМУ воплощать его представление о системе в код и получать результат, который он может тут же оценить. Отсюда и прорыв "у них", и здесь мы можем избежать, оценив "их" опыт использования технологии аналитик-кодировщик-тестер, подводного камня превращения творчески мыслящих сегодняшних программистов в кодировщиков, реализующих чужие представления о мире, за счет использования новых технологий, позволяющих свести к минимуму количество кодировщиков.
Прислал Королев Андрей, a-v-k@mail.ru (замечательно, что есть люди постоянно высказывающие столь интересные мнения).

Следующее письмо:

Мое мнение по поводу поставленных вопросов:
1) Кто такой хороший программист?
Это понятие, конечно, очень емкое и зачастую субъективное (как Вами и замечалось). И трактование его можно также рассматривать в разрезе времени. То, что относилось к программисту, скажем лет 20-30 назад - это один набор качеств или понятий. Сейчас (наверное, сказывается развитие как науки и техники, так и общества в целом) - этот набор довольно сильно претерпел изменения. Если раньше программист больше соответствовал кодировщику, то теперь кроме знания предметной области ему необходимо иметь знания (или представление) из других (смежных и не очень) областей (маркетинг, бухгалтерия, взаимодействие с пользователями и клиентами и т.д.).

3) Что такое хорошая программа?
Хорошая программа - это программа, которая после создания легко (во всяком случае без больших трудностей) сопровождается, может дополняться и изменяться. Это можно считать мнением, присущим больше эксплуатационнику, чем программисту, но для кого в конце концов
пишутся все программы и формы?
И еще: программа без комментариев не имеет права даже претендовать на звание хорошей.

Прислал Шимшит Евгений ( Evg_Shimshit@zp.ukrtel.net)

>Кто такой хороший программист ?
Действительно, в России очень часто роли аналитика, кодировщика, и тестера совмещаются в одном человеке. В принципе это перечисление можно классифицировать и дальше. Например аналитиков можно разделить, на экспертов в предметной области, непосредственно аналитиков и проектировщиков. Кодировщиков можно разделить на множество категорий,
например: специалистов по пользовательскому интересу, по БД, инструментальщиков, системных (работающих с функциями ОС). И т.д. Для каждой конкретной категории существует свой список достоинств. Поэтому человек, считающийся профессионалом в одной области, может оказаться совершенно беспомощным в другой.

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

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

>Что такое хорошая программа ?
Это программа, написанная хорошим программистом. (Хороший программист это тот, кто пишет хорошие программы.) ;-)
Всем хорошо известен распространенный цикл разработки программ: анализ, проектирование, несколько итераций кодирования, тестирование.
Стадии разработки должны быть хорошо сбалансированы В силу известных причин, часто наблюдается исключение из цикла всех стадий, кроме кодирования. Причем оно делается за один проход. Очень трудно ожидать качества от программы, написанной таким образом (зато быстро и иногда дешево).

Прислал Nikita (supernikita@chat.ru)

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

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

CONST23: 3443 ; R.I.P.L.V.B

После некоторых часов размышления над комментарием, программист решил, что он является ключом ко всем тайнам комментария. Оказалось, что 3443 соответствует дате 1827 - дате смерти Бетховена (Ludvig Van Bethoven). Можно представить, как мало забавного нашел в этом руководитель проекта и сам программист.

На этом позвольте завершить вышеупомянутую тему и перейти от философских вопросов к теоретическим. (Хотя вопрос о хорошей программе я еще затрону).

---------------------------------------------

МОДУЛЬНОЕ ПРОГРАММИРОВАНИЕ

Модульность в программировании подобна честности в политике: каждый утверждает, что она - одно из его главных достоинств, но кажется никто не знает, что она собой представляет, как ее привить, обрести или добиться . Э.Йодан.

Каждый знает, что модульная программа - это программа, в которой любую часть логической структуры можно изменить, не вызывая изменений в остальных частях программы.. Но существует ли какая-либо мера модульности ? Разве можно сказать, что моя программа в 3,141 раз модульней вашей ?

Если бы мы знали как писать модульные программы, то исчезли бы проблемы отладки, модификации и сопровождения программ. Однако до сих пор нет теории как писать модульные программы

Но не будем спешить. Неужели никто из вас не знаком с концепциями структурного программирования, нисходящей (восходящей) разработки программ ? Эти методы появились как следствия неразвитости модульного подхода, стремясь воплотить его в жизнь.

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

- Ассемблер (модульность реализовать очень тяжело)

- Фортран, Бейсик (невозможно)

- Паскаль (появляются подключаемые модули, которые мы можем не менять)

- С, С++ (появляются классы, библиотеки классов)

и т.д.

---------------------------------------

Вот на этом и завершим наш ОБЗОР модульного программирования. Следующие два (или больше) выпуска будем более подробно рассматривать теорию и методы модульного программирования.

Ссылки:

http://www.case.ru - снова обращаю ваше внимание на этот сервер, содержащий множество теоретических и практических материалов, касающихся применения CASE средств.

http://www.miracle.ru - материалы, касающиеся разработки высокотехнологичных программных систем, быстрого проектирования информационных систем.

Вопросы к подписчикам:

- Насколько глубоко хотелось бы вам узнать о модульном программировании (с азов или поверхностно, глубоко) ?

- Не кажется ли вам, что появление распределенных вычислений, тоже результат стремления к модульности ?

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

Поиск:

- Ищутся соавторы, авторы, практики и т.п. с целью оказания рассылке информационной поддержки.

- Ищется РЕКЛАМОДАТЕЛЬ. Пока всего 2400 подписчиков, но это тоже не мало, тем более, что это число постоянно увеличивается

С уважением, Сергей (trbps@newmail.ru )

http://www.citycat.ru/
E-mail: citycat@citycat.ru
В избранное