Нужен совет.⁠⁠

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

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

а давайте ебнем сразу 12-ти томник.

раз есть php,то есть предложение включить CSS и HTML

почему так модно стало учить программировать? когда научился и не знаешь куда применить знания что ли?

Блин включи java если будет возможность)

Вопросов несколько:

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

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

3) То же самое относится к ООП - пока проекты не начнут становиться достаточно сложными и комплексными, никто не сможет понять как и для чего нужно ООП (опыт и мой, и практически всех моих знакомых)

4)

3.2.4 Повторное использование кода

3.3 Оформление кода

3.4 Безопасность приложения

3.5 Определение целей и задач

3.6 Структура программы

3.6.1 Библиотеки

3.6.2 Функции

3.6.3 Строки

3.6.4 API
Буквально вся эта часть смотрится очень странно для человека, который еще не написал ни одной строчки кода. Какое оформление? Какое повторное использование? Какая безопасность?

Ну и последнее, судя по моему опыту, нужно очень, очень много внимания уделять составлению алгоритмов. Я в свое время учился программированию на паскале, на задачнике для 11 класса, где просто нарешивал и нарешивал десятки и сотни задач. А потом брал олимпиадные задачи и опять нарешивал. И, как мне кажется, это лучший путь, потому что выучить стиль кода, ООП не так сложно, когда у тебя нет проблемы с вопросом, а как в принципе решить задачу, и ты можешь сконцентрироваться на том, чтобы решить ее самым оптимальным или красивым способом. Так что писать, писать и еще раз писать код!

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

Вообще да, но в javascript они, вроде как, тоже есть.

Проверка функции pow с любыми значениями на входе и выходе. Никак не покажет ошибку в функции факториала.

Ну и это по сути и есть ручное тестирование?

Ну и зачем мы тогда программируем, чтобы все делать вручную?

Что такое эмуляция? Интеграционное тестирование?

События и делегаты )

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

Что значит "под ключ"? Нельзя же за одну книгу подготовить программиста, которого сразу в Google возьмут, например.

"Экспериментально хочу попробовать сделать вариативное содержание" у Кнута эта идея реализована - можно взять в качестве примера. Я про Искусство Программирования.

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

"Си, наверное стоит либо выставить факультативом (как пролог) или выкинуть совсем." я бы викинул его совсем. Если хочется показать что-то уровнем ниже, чем С++ то сразу стал бы рассказывать про Assembler. Заодно и архитектуру процессора подробнее описать можно.

"Для больших проектов есть другой способ - эмуляция" дык это же и есть то тестирование, о котором идёт речь =)

Как бы вы применили второй принцип, если разрабатываете, например, GUI? Там граничные значения вычислить почти никогда не получится. Зато тестированием большинство багов отлавливаются "на раз" и малой кровью. А что важнее - когда кто-то добавил новую кнопку, то не нужно заново для всех предыдущих окон кнопок и менюшек пересчитывать "граничные значения". Это правда удобно, а для больших проектов - жизненная необходимость.

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

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

Теперь, зная цели, можно поставить вместо себя "типичного представителя ЦА". Он берёт книгу по программированию, начинает её читать - и видит какие-то системы счисления, логические операции. "Зачем мне вся эта чушь? Я программировать хочу!" и откладывает вашу книгу, берёт другую книгу.

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

Поэтому я бы Главу 2 поставил первой (2.1 просто выкинуть или куда-то в самый конец положить - это полезно только для тех, кто уже серьёзно подумывает о карьере девелопера) и главу 5 поставил второй. Глава 3 пусть остаётся третьей (то бишь после Python), иоб я не понимаю, как вы собирались рассказывать про оформление кода когда сам код ученики ещё ни разу так и не видели. Что оформлять? :)

Python - отличный язык для обучения. Но вот почему дальше идёт С? Почему не сразу С++? Мы только что научили человека пользоваться классами и объектами, а теперь зачем-то просим его забыть об этом. Причём я не увидел по содержанию, что ученик получит, если откажется от изечнных фич (на деле я, конечно, знаю области применения С, но это опять же только для тех, кто уже не нуждается в таких книгах). Так что лично я бы вместо С сразу поставил С++.

Также ОБЯЗАТЕЛЬНО нужно рассказывать про структуры данных. Хороший прогаммист обязан понимать разницу между вектором и списком. Почему иногда мы хотим использовать дерево поиска, а иногда - хэш-таблицу. Всё это нужно вынести в отдельную главу "Структуры данных" (название взял с неба) и описывать после С++, т.к. там придётся говорить про указатели и работу с памятью.

Сам в качестве хобии преподаю информатику/программирование уже 8 лет. Если ещё будут вопросы или с чем-то из написанного не согласны - комментируйте, обсудим.

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

так вы не писали что с ней не работали)

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

2.1 как-то не к месту, на мой взгляд. Может это в конце ?

Обычно SQL и БД учат после основ программирования, хотя, Вам виднее.

Не очень понятно чему именно вы собираетесь научить людей. Если курс наподобие "Основ программирования", то стоит сделать упор на алгоритмистику, способы построения алгоритмов, структуры данных и т.д.

Если с уклоном в web-программирование, что мне кажется более логичным по вашему содержанию, то имеет смысл ограничиться языками Python и близкими к нему, а также рассмотреть клиент-серверную архитектуру, хотя бы чтобы дать основное представление зачем всё это и где применяется.

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

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

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

Тем не менее, удачи вам в своих начинаниях)

Офигенная штука должна получиться, но как заставить себя это читать? ))

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

ссылочку на бумстартер будь добр,или пикабу это расценит как рекламу?

А если в код пишут 2 программиста. И функция возведения в степень использует функцию, вывода, обработчик ошибок, и функцию умножения. А функцию pow использует функция факториала.

То как одному программисту гарантировать, что изменения в одном участке кода не приведут к появлению ошибок в другом участке кода?

Тесты. Если этого до сих пор нет в содержании, лучше ничему не учить других.