Обсуждение книг рекомендованных для прочтения
Э.Гамма Р.Хелм Р.Джонсон Дж. Влиссидес
(Книга из разряда must have...начинать нужно именно с неё
Книгу рекомендуют несколько раз в теме про книги. Однако, не согласен, что начинать надо с нее, ибо это прыжок через ступень. Или даже через несколько ступеней. Одна из пропущенных ступеней - шаблоны GRASP. Вот это больше похоже на основы.
Экстремальное программирование: разработка через тестирование
(вводная часть в тестирование...сейчас читаю...идет легко, сама по себе небольшая)
Книга интересная, но некоторые утверждения сомнительны. Например, самое главное: что тесты надо писать прежде кода.
Первое возражение - я все-таки должен знать, что тестирую, потому хотя бы примерно должен описать функции (без реализации). То есть код все равно будет писаться немного раньше. Пусть даже в виде диаграмм или текстовых описаний. В общем, и сам Кент Бек говорит про какие-то метафоры.
Второе возражение - использование жульничества с пропавшим звеном.
Например, надо разработать функцию add, складывающую 2 числа.
1. Создаем тест, который проверяет add(1, 3) == 4.
2. Создаем функцию add, которая возвращает всегда 4.
3. Ура! Тест сработал. Создаем еще условие: add(2, 5) == 7.
4. Тест не сработал, потому меняем функцию: если первое данное единица, то возвращаем 4, иначе возвращаем 7.
5. Ура! Тест сработал! Делаем еще один.
...
В конце концов каким-то чудом понимаем, что надо сложить данные и возвратить результат. Откуда это чудо взялось - не ясно. И не ясно, почему мы не остановились на втором тесте (триангуляция же).
Ещё есть замечания по другим книгам, но пока ограничусь этими двумя.
Но нет дорог, ведущих к ним.
Если идти туда, куда укажут вам,
Найдете скользкий,
Покрытый мхом мост.
А вот Ramon действительно,засоряет:)
Ну чтоб усвоить книгу "Паттерны проектирования", на мой взгляд, нужно иметь определенный опыт разработки программного обеспечения, - для понимания зачем это вообще нужно, иначе читатель не будет мотивирован на изучение.(Ака ведь, когда теория ассоциируется с практикой оно всяко лучше изучается)
Помню нам в универе про паттерны рассказывали...тогда в одно ухо информация влетела, на 40% усвоилась и вылетела через другое после сессии:)
А вот после того как паработал пару лет, вот тогда да...
Я говорил про тему, где книги рекомендуют. Её не надо засорять, чтобы удобнее было читать список книг.
...
А вот после того как поработал пару лет, вот тогда да...
Чтобы что-то усвоить, нужно правильное сочетание практики, теории и стимула. Это понятно.
Однако, я не разделяю точку зрения, что опыт тут является единственным источником понимания. Нужны какие-то "средства измерения", чтобы "рассчитать" полезность паттерна в какой-либо ситуации. И такие средства есть, но тот кто перешагнул ступень ознакомления с этими инструментами будет полагаться на интуицию и опыт, которые могут подвести. Тем более, если опыт маленький, то паттерны будут применяться вообще не к месту.
Рекомендована она была тут.
Юмор действительно есть, но не это главное. Большую часть книги автор убеждает читателя в том, что программист не может написать программу, предназначенную для обычных людей, а не для продвинутых пользователей. При чём дело не в том, что он не желает, а в том, что мозг устроен уже по другому. Ну и пишет, как бороться с программистом.
Весьма интересно рассуждение о проектирование взаимодействия с пользователем. Почему-то оно должно создаваться не как проектирование кода (UML и прочее), не как программирование, но другим путем. А именно: программировать и проектировать код многие авторы рекомендуют итеративным путем, меняя направление развития исходя из того, что получится на определенной итерации. Для проектирования взаимодействия рекомендуется один раз создать четкую спецификацию и от неё не отходить.
Теперь о главном. Между делом автор бросает задачки, которые явно не решает. Типа: "Почему пользователь должен что-то знать о файловой системе? Почему он должен делать операции сохранения файла и т.д.? Надо сделать проще." или "Не нужны операции "А уверены ли вы, что хотите сделать операцию?" – надо убрать их, заменив отменой."
Вот подобные задачки можно решать на форуме разным людям, вне зависимости, какой язык программирования они используют. Понятно, что надо решать более конкретные случаи.
Вообще говоря, взаимодействие с пользователем проектирует юзабилист вместе с программистом. Потому как взаимодействие с пользователем - область довольно сложная, со своими неочевидными тонкостями (вспомните недавний дискурс о дереве в общалке), у юзабилиста есть свои (часто неведомые программисту) методы работы и тестирования. Поэтому высказывания об итеративном подходе больше относятся именно к работе юзабилиста.
Кстати, юзабилист - понятие обобщённое. Под этим словом вполне можно понимать аж трёх человек: проектировщика и дизайнера интерфейса, а ещё технического писателя, который помогает первым двум плюс делает свою работу.