(Каждый из вас может получить самостоятельное представление о содержимом этой книги по адресу – programmer.97things.oreilly.com)
Представьте, что вы просыпаетесь среди ночи с озарением: я хочу написать книгу! Вы при этом понимаете, что писать книгу с нуля муторно, наработок толком нет, да и с темой еще не определился. Но поскольку уснуть не получается, то вы бродите по дому всю ночь в поисках решения. И вот, когда за окном уже начинает светать к вам приходит озарение: миру не хватает книги с общими советами, бесполезными любому программисту! Менеджерам повезло, для них уже вышла книга "97 Things Every Project Manager Should Know", так почему бы не сделать аналогичное доброе дело для программистов?!
Сказано – сделано! Все, что нам нужно, это найти 5 десятков авторов разной степени известности и попросить их поделиться своими сакральными знаниями! От каждого из них нам потребуется всего ничего: вумных мыслей в размере не более одной страницы! А что если у автора уже есть свои известные статьи? Тем лучше, тогда мы попросим выкинуть из нее весь код и "скукожить" в размерах, чтобы даже самому автору она перестала быть понятной! После этого, мы возьмем сотню заметок на самую разную тематику, выкинем 3 лишних, чтобы получить волшебное число 97, тщательно их перемешаем, чтобы от последовательного чтения книги вообще не осталось никакого смысла, напишем введение и ... вуаля, книга готова!
Иногда, размер имеет значение
В чем главная проблема 97 этюдов? Размер глав! Несмотря на то, что книга содержит 97 советов и размер ее составляет 250 страниц, по факту на один совет приходиться даже меньше одной страницы печатного текста в чистом виде.
Проблема любого совета типа "используйте Х", "не используйте Y", "изучите Z" в том, что он контекстно-зависим. Любой взрослый программист знает, что серебряных пуль нет и основная сложность заключается в поиске компромиссов при принятии решения. Нужны ли комментарии или они вредны? Можно ли дублировать код или это главная проблема нашей индустрии? Что лучше ФП или ООП? На эти вопросы очень сложно дать ответ на одной странице так, чтобы они звучали убедительно и раскрывали контекст, в котором этот совет применим.
Ну а поскольку многие советы таки зависят от контекста, то в книге появляются прямо противоположные рекомендации. Один автор утверждает, что принцип DRY (Don't Repeat Yourself) является абсолютно фундаментальным и его нарушение ведет к нарушению всех остальных принципов проектирования, а другой автор пишет, что иногда на реюз можно положить болт, поскольку это может приводить к ненужной связности независимых кусков кода.
Очень расстроили известные статьи, "скукоженные" до неузнаваемости. Один из моих любимых принципов проектирования я почерпнул из замечательной книги Скотта Мейерса "Эффективное использование С++" о проектировании API. Звучит он так: "Проектируйте класс/модуль так, чтобы его легко было использовать правильно и сложно использовать неправильно".
Следование этому совету приведет к использованию специализированных доменных типов (типа UserId вместо Int); передаче в С++ обязательного параметра по константной ссылке, а не по указателю; использование паттерна Builder и генерация исключений в конструкторе, что позволит уберечь пользователя от использования объектов в невалидном состоянии. Хорошо продуманным классом легко пользоваться правильно, не читая стостраничный талмуд по его применению.
Этот же совет Скотт дает и в этой книге в главе Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly, но он настолько короткий, что читатель может ему лишь поверить, но проникнуться им до глубины души шансов у него не много.
Другим примером "скукоживания" может служить описание известного принципа единой ответственности Боба Мартина. The Single Responsibility Principle занимает целых полторы страницы и содержит два примера кода, но едва ли можно считать его полным, исчерпывающим и убедительным.
Проблема в том, что иногда размер играет значение! Программисты – это такой народ, который не любит верить на слово. Многие знают или интуитивно понимают, что слепое следование советам легко может привести к культу карго, да и сам факт наличия противоречивых советов в книге вряд ли поможет навести порядок в голове читателя.
Недостаточно просто сказать, "ребята, изучайте функциональное программирование – это круто!", как это сделано во второй главе этой книги. Почему бы не привести хотя бы несколько примеров, как это сделал тот же Мартин в своей статье "Functional Programming Basics", и расписать «функциональное» мышление и то, какое влияние оно оказывает на дизайн и реализацию? Вот и выходит, что многие советы просто бесполезны: либо это баян, и вы им и так давно уже следуете в своей работе или же вы просто пройдете мимо даже не обратив на него внимания!
Набор несвязанных фактов
Хороший код рассказывает историю. Его можно читать как книгу, сверху вниз, он прост и понятен и не требует большого количества переключения контекста; он "цельный" (cohesive) и предназначен для решения четко определенной цели; он опирается на небольшое количество строительных блоков более низкого уровня; он иерархичен, что позволяет справляться со сложностью реальных систем.
Чего-то подобного мы ожидаем и от книги. Мы хотим, чтобы книга содержала разделы, посвященные определенным темам; мы хотим, чтобы каждая глава была "цельной" и рассказывала свою историю от начала до конца. Мы не хотим дублирования, когда одна и та же тема рассмотрена в 3 местах под разными соусами; мы не хотим голословных советов, а ждем обоснованных суждений; мы не ищем серебряной пули, а просто хотим узнать, что же, по мнению нашего сообщества, должен знать каждый программист.
Читать же сотню советов один за другим, перескакивая от чистого кода к инфраструктуре, от парадигм программирования к дизайну и обратно, не всегда удобно. Хочется, чтобы после прочтения подобной книги в голове выстраивалась четкая картинка, а вместо этого остаются лишь смутные воспоминания от вселенской мудрости.
Так что же должен знать каждый программист?
У каждого есть свое мнение о том, что должен знать каждый программист. Конечно, есть некоторый набор ключевых знаний, без которых, вроде бы, никуда, но и он может отличаться от области к области.
Кто-то скажет, что знание computer science является обязательным, а кто-то возразит, что это теоретическая хрень, которая не применяется на практике.
Кто-то будет отстаивать важность понимания устройства операционной системы и основных принципов ее работы, а для другого это будет лишь бесполезной тратой времени.
Кто-то скажет, что важно знать несколько языков и парадигм программирования и никто в здравом уме не будет возражать, но всегда найдутся противники здравого смысла, которые будут возражать против любого совета.
Кто-то будет отстаивать важность IDE и умения с ней работать, а другой будет настаивать на важности инструментов командной строки.
Кто-то будет настаивать, что отладка является самым важным навыком, на что получит возражения о пользе чистого кода и покрытия его тестами.
Кто-то будет говорить о важности дизайна и паттернов проектирования, а кто-то все это считает ересью и обвинит сторонников паттернов в ООП головного мозга.
Кто-то скажет, что без баз данных никуда и нужно в совершенстве знать SQL и принципы реляционной алгебры, но найдутся и сторонники NoSQL и будут тыкать CAP-теоремой в свою защиту.
Я буду отстаивать важность контрактов и ценность книги Мейера для любого программиста, но всегда найдутся сторонники защитного программирования или ярые сторонники юнит-тестов, которые будут убеждать в бесполезность контрактов или убогости их реализации на платформе .NET.
Одни будут говорить, что "бесплатный завтрак завершен" и нам нужно всерьез задуматься о параллелизме, но всегда найдутся те, кто считает параллелизм уделом избранных и ненужным для "мейнстрима".
Кто-то будет твердить о важности методологии и что "правильный" процесс решит все проблемы, но любой здравомыслящий человек скажет, что люди делают команду успешной, а не методологии.
Единственное, что должен знать каждый программист, так это то, что он знает лишь малую толику того, что есть в нашей области, что перед ним лежит бескрайние просторы знаний и он коснулся едва ли тысячной их части. Каждый программист должен знать, что он не совершенен и стараться пополнить багаж своих знаний.
Вердикт книги: легкое чтиво, с небольшой пользой для читателя.
Комментариев нет:
Отправить комментарий