Рецензия на книгу "Чистый код" – Роберт Мартин

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

Главы 2-3. "Содержательные имена" и "Функции"

Я объединил их в одну, ибо ничего нового для себя в них не нашёл, всё то же самое, что я сам понял за время своего пути в IT, а именно:

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

Глава 4. "Комментарии"

В целом также для меня ничего нового, но всё же повторение – мать учения.

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

Глава 5. "Форматирование"

Тут я бы сказал, что тоже ничего нового нет, тем более всё сказанное в этой главе любая IDE сама делает. Так же, например, для Python есть PEP8, которая говорит как и что лучше писать.

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

Глава 6. "Объекты и структуры данных"

Во-первых, Закон Деметры, о котором тут говорится, мне дался довольно трудно. Помогла в конце-концов статья в Хабре

Во-вторых,

То, что сложно в ОО, просто в процедурном программировании, а то, что сложно в процедурном программировании, просто в ОО,

– это основная идея, которую я выделил в этой главе и что тоже было не так уж и легко, чтобы понять, но как минимум, что я понял, что пока защищаю процедурное программирование. Так уж сложилось. Думаю как минимум по той причине, что в Python нет модификаторов доступа (public, private, protected)🫠

Глава 7. "Обработка ошибок"

По своему опыту скажу – да, обработка ошибок часто загромождает код и всегда лучше в случае чего использовать try-catch, но и там свои изъяны.

Также, в главе рассматривается 2 способа облегчения кода обработки ошибок настолько, насколько возможно, и их стоит попробовать.

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

Глава 8. "Границы"

Глава довольно маленькая, и если вкратце, то нужно разграничить свой код и какие-либо сторонние API, (например, написав обёртку)

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

Одним словом – инкапсулировать!

Глава 9. "Модульные тесты"

Сразу скажу, что прям писать тесты мне ещё не приводилось, однако я для себя выделил, что один тест должен делать 1 проверку (принцип единой ответственности SRP), а также их лучше писать так же чисто, как и код приложения.

Глава 10. "Классы"

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

Глава 11. "Системы"

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

Глава 12. "Формирование архитектуры"

В самом начале главы нас приветствует текст, что гласит, что архитектура является "простой", если она:

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

Самое главное правило тут, конечно, первое, не то нерабочий код никому не нужен, остальные, кроме последнего важны. Последний не так важен, ибо он может поломать остальные, ибо классы и всё остальное должно обладать SRP, а без большого количества классов – никак.

Глава 13. "Многопоточность"

Одним словом – довольно трудная глава о довольно трудной теме, и хоть на словах всё просто – на деле это труднее, и в главе написано почему.

Глава состоит из тезисных проблем и их решений и общих советов, всё тут писать (даже ещё более кратко) будет долго, а статья уже довольно длинная.

Главы 14-16:

"Последовательное очищение"

"Внутреннее строение JUnit"

"Переработка SerialDate"

Тут уже переход от теории в практику. Автор показывает, как он писал код и очищал его, как очищал и оптимизирован чужой, какой у него был ход мыслей и прочее. Если вы умеете читать чужой код и имеете базовые знания языков программирования (в идеале Java) – считайте, что вы прочли главу. В любом случае, знать, как следует примерно мыслить при очищении кода и очищать его – полезный навык.

Глава 17. "Запахи и эвристические правила"

Тут все правила объединены в одной главе в коротком виде. Вероятно, во время чтения вы думали, что за обозначения на подобие J1, T1 и др. Так вот – это коды правил, все они собраны тут.

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

Итог

Книга Роберта Мартина довольно полезная имеет реально много полезный правил для очистки кода, автор даёт советы и показывает на примере что да как можно сделать, что когда использовать и прочее, для меня, как я говорил, первые главы не были столь полезны, хоть и смог пару правил новых. Для всех советую, даже для тех, кто давно пишет код вроде как чистым, но есть одно правило (точно не помню, как в книге было, так что не совсем цитата из неё):

Нет модуля, который нельзя сделать чище.

Опять же – это моя первая рецензия на проф.литературу, если есть советы и прочее – welcome в комментарии)