info21 писал(а):
ScrollLock писал(а):
... написание технической документации проще, чем сочинения - не нужно понимание литературных персонажей, более простой и прямолинейный язык доков, нет пафосных вступлений и заключений.
Вот, наконец, золотые слова.
Не понимаю, где тут золото... Тем, кому не нтавится пафос - пусть не добавляют его во вступление и заключение. Но чем провинились сами начало и концовка? Ведь, также можно добавить, что между ними тоже полно пафоса, и дело закончится тем, что заказчик получит программный продукт и документацию - чистый лист бумаги.
Не помню, что говорили в школе насчёт введения для художественных произведений, но подозреваю, что именно то, к чему я пришёл спустя некоторое время после её окончания. А именно: оно устанавливает направление движения мысли автора, которое раскрывается в дальнейшем повествовании. Насчёт заключения, правда, не могу припомнить, когда оно в документации потребовалось бы.
Кстати, в документации по ББ есть вступления. Например, описывающие триаду Модель-Отображение-Контроллер. Или отступление, даже не знаю. Но без такого дополнительного объяснения данной триадой было бы пользоваться затруднительно. Обучение проходило бы по принципу проб и ошибок. Я понял, почему обращение к файлам настолько громоздкое, и почему нельзя было сделать более удобного способа только после прочтения той части документации, которая в мейнстриме содержит только пафос. Встречаются такие вступления как:
"Мы задумали новый проект. Однако мы всё крутились и крутились, однако никак и с места сдвинуться не могли. Так мы и сидели, пока меня не 'осенил' кирпич. Так, собственно, и зародился наш Супер Проект."
Однако, отказываться от проверенного веками элемента произведения толь ко потому, что последние лет 20 он только и делает, что отнимает время на прочтение из-за неумелого использования, всё-таки не стоит.
Далее, в школьную литературу попадают в основном произведения классиков, которые потому и стали классиками, что у них были хорошие мысли и они грамотно и доходчиво их передавали. Школьникам не приходится делать сверхусилий для понимания образов. Соответственно, сочинения не такая уж сложная штука (я говорю про сочинение как таковое, а не про очень хорошее сочинение). В случае же с документацией, вам предлагается стать этим самым классиком, чтобы грамотно и доходчиво передать способ использования инструмента, а не простое описание графического интерфейса. Чем грамотнее документация написана, тем реже в её придётся потом подсматривать.
Это я к тому, что хотя язык технических документов и проще, не стоит забывать о тех сложностях, которые подстерегают документописателя.
info21 писал(а):
Подозреваю, что такое упражнение имеет смысл даже с точки зрения обучения программированию самого по себе. Разбавить обезъянье тыканье в клавиши чем-нибудь напрягающим мозги.
Я даже могу кое-что предложить, но это будет не для 7 класса. Это поможет заставить уважать проектирование и поумерит пыл при "обезъянем тыканьи в клавиши". Как я заметил, программы, которым предшествовало проектирование, проще описать. Человек при проектировании описывал проект довольно простыми понятиями (для данного проекта), поэтому документация содержит довольно чёткие определения действий и описания процессов. Если же сначала был получен код, и лишь затем взялись за документирование, то понятия вычленять очень сложно. К тому же, они всё равно страдают невнятностью.
Упражненьице будтет состоять в следующем: на первом занятии класс делится на две группы. Первая группа проектирует, а вторая - пишет программу. На втором занятии (Когда оно будет? Через неделю?) все составляют документацию. На третьем занятии - вторые делают проект написанной программы, а первые - пишут код.
Тут важно, чтобы документацию оценивали как сочинение. Может, для этого выделить один урок русского языка? Так как проверяться будет всё: лексики до вложенного смысла.