План учебника

[vitus_wagner]

Совместными усилиями с snowman_sailor и ramendik написали план учебника по введению в программную инженерию. Вместо двух частей получилось три.

На мой взгляд, проект получился весьма амбициозным, и не уверен что у нас троих хватит квалификации, чтобы раскрыть (особенно, учитывая ограничения на объем) все темы. (правда, как известно, хочешь в чем-нибудь разобраться - прочитай по нему спецкурс).

В общем я бы с удовольствием пригласил на отдельные разделы других авторов, которые лучше меня понимают в соответствующих вопросах. (все это планируется публиковать под CC).

Comments

[schegloff.livejournal.com]

Это не введение, а пятилетний курс для будущих генеральных конструкторов мега-приложений :)

Либо название поменяйте, либо надо сокращать. Введение в специальность - курс на десяток лекций, и тоненькая брошюрка.

[vitus_wagner]

У нас в свое время учебник для курса введение в специальность "Общее землеведение" был вполне нормальной толщины томиком. Страниц на 400, по-моему даже формата А4.

И в первом семестре было 10 теоретичеких курсов с учебниками сравнимой тошщины. Ну ладно, 8 если выкинуть высшую математику и историю КПСС.

[schegloff.livejournal.com]

Вот и назовите "Общее программоведение" :)

[snowman-sailor.livejournal.com]

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

[darkmoor.livejournal.com]

Для генеральных конструкторов мега-приложений структура документа должна быть принципиально иной.

Если конкретно - скромный эпилог под заголовком "Жизнь после релиза" придется развернуть в три самостоятельных раздела, превышающие по объему весь остальной текст, вместе взятый.

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

[wizzard]

Что пришло в голову и чего я часто видел что люди не знают:

1) введение про время, причинность и теорию относительности (что бывают события, про которые нельзя сказать, кто был первым, что сообщения распространяются не мгновенно, и т.д.); - кстати, обьяснять VCS и БД будет проще

2) введение в моделирование данных и онтологию (почему нельзя всему присвоить id, почему вредно считать что чего-то бывает только 1 штука, что такое вообще identity - сравнение по ссылке, по значению, почему нельзя составить Исчерпывающий Список Всего, что делать если мы Машину-5 разобрали на Запчасть-7 и Запчасть-8, а потом собрали из них Машину-10 и Машину-11 и т.д.)
Особенно это в форматах данных важно (версионирование, то-се. СУБД часть вопросов худо-бедно закрывают)

UPD: отличие между неизвестными, ошибочными, неполными и неточными данными еще

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

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

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

Список ни в коем случае не полон, просто не включая мозг написал

[wizzard]

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

[filonov.livejournal.com]

Как-то не вырисовывается концептуальной целостности. Скорее пока какая-то каша, собранная по принципу "а еще я вот про это знаю".
В первой части - каши больше. в третьей - меньше.

Дабы не быть голословным:
- разделы "межпрограмное взаимодействи", "Расширяемые программы", "использование внешних программ", IMHO нуждаются в сведении в
два раздела

[wizzard]

Мне кажется, тут не может быть концептуальной целостности, но можно сделать постепенное углубление.

[filonov.livejournal.com]

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

- разделы "межпрограмное взаимодействи", "Расширяемые программы", "использование внешних программ", IMHO нуждаются в сведении в два раздела - теоретические основы межпрограмного взаимодействия, и обзор используемых реализаций.
- Раздел о виртуализации производит странное впечатление. Объединять ее с кроссплатформенностью смысла нет никакого. Существенная часть того что относят к виртуализации двинулась в сторону изоляции среды исполнения, но при этом альтернативные варианты изоляции оставлены без внимания.

- часть раздела "настройка и персонализация" явно просится в третью часть.

[vitus_wagner]

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

Это что-то вроде онтологической базы системной инженерии. Чему пытается учить ailev. С онтологиями и моделированием оно естетсвенно связанао. А у нас тут приземленная практика.

Ну то есть если вы сумеете впихнуть это в 3-5 страниц. это можно включить во введение. Но боюсь, что тут понадобится более объемное изложение.

Про оценку производительности спряталось под заголовками "нагрузочное тестирование и профайлинг".

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

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

[vitus_wagner]

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

Здесь есть именно обзор реализаций. А теоретические основы будут в каком-нибудь другом курсе.

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

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

[vitus_wagner]

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

[ynot.livejournal.com]

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

к процессу подготовки первокурсников в рамках массового очного первого образования 17-леток отношения не имеет. (простите ради аллаха, вы давно первокурсников "среднего хорошего вуза" вживую видели?)

P.S. (читать "введение в специальность" в течение ДВУХ СЕМЕСТРОВ раз в неделю, как здесь предлагалось - это безумие. Введение должно быть достаточно интенсивным, а не подпороговым, чтобы скорость запоминания хоть немного превышала скорость выветривания)

P.P.S - основной вопрос - пожалуйста, сообщите предпололжительное кол-во учебных часов для этого курса?

[eldhenn]

> введение про время, причинность и теорию относительности

Это надо изучать если не в начальной школе, то по крайней мере не позже полового созревания. Но лучше всё-таки в начальной.

[wizzard]

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

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

[wizzard]

Да, мне тоже кажется, что это интенсивка.

[eldhenn]

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

[eldhenn]

ЗЫ Сам бы с удовольствием прошёл, до меня эти вещи начали доходить не так давно, уже после 30ти.

[wizzard]

Ну дык. Я впервые встретил хоть сколько-нибудь адекватные статьи на тему в 22 года :(

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

[snowman-sailor.livejournal.com]

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

2) Онтологии и моделирование данных там размазаны тонким слоем между управлением знаниями и хранением данных. Возможно, рассказывать про них явно хорошая идея.

3) Оценка производительности есть в тестировании, к которому она, собственно, и относится

4) Инженерию требований может и стоит включить, но насчет "достойна отдельной книги" не уверен. Мне не попадалось ни одной вменяемой книги о работе с требованиями. Все они разводят воду вокруг трех мыслей: аккуратно все записывайте, проверяйте хотелки пользователей на моделях, отслеживайте противоречия между требованиями. Да и работа с требованиями, на мой взгляд, куда больше политика чем инженерия.

[vitus_wagner]

Лично я полагаю, что существующие ВУЗы нужно разогнать совсем. А программистов готовить в колледжах и техникумах. Толковый 14-15-летний ребенок вполне этот курс освоит. Даже помимо учебной программы. Если, конечно хорошо написать.

И переучивание взрослых - тоже занятие нужное.

Насчет учебных часов - это не ко мне. Если оценка "пара в неделю"*"2 семестра" вас не устраивает, что еще надо? По-моему с большей точностью оно не формулируется.

[vitus_wagner]

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

Поэтому переучивать людей придется.

[wizzard]

4) Этих трех мыслей совершенно недостаточно. Потому что хотелки пользователей и проблемы пользователей - это две большие разницы.

Можно вот с вот этого хотя бы начать: Discovering Requirements: How to Specify Products and Services

[alll]

Имхо не хватает раздела про деньги. :) Ну то-есть что-то типа "зачем мы пишем код с точки зрения работодателя и как это влияет на принимаемые решения вплоть до закрытия проекта".