Из серии "Я читаю"
Э. Хант, Д. Томас. Программист-прагматик.
Еще одна книжка по программированию, но не совсем. В "Прагматике" нет сложных алгоритмов, скучных формул, необъятных фреймворков и паттернов с непонятными названиями. Книга ведет речь о тех мелочах, которые встречаются обычному программисту в его работе каждый день, но на которые часто не обращают внимания - до тех пор, пока все не сломается. Большинство вопросов, рассмотренных в книге, так или иначе замечаются разработчиком на подсознательном уровне - книга дает этим вопросам названия, классифицирует их и расставляет по полочкам.
Бывают такие программы, в которых сдвигаешь кнопку в окне на 10 пикселей влево - как вдруг в базе данных что-то отваливается. Прагматичный программист скажет - эта программа недостаточно ортогональна, и у неё высокая связность. В кинге вводятся и разжевываются оба понятия, и дается ряд практических советов, как снизить связность, улучшить ортогональность и поддерживать гибкость архитектуры.
Случается, что команда тратит несколько месяцев на проект, разрабатывает, отлаживает, шлифует, показывает заказчику - и выясняется, что заказчик имел в виду совсем другое. Книга рассказывает прагматичному программисту о прототипах, "стрельбе трассирующими" и настоятельно рекомендует почаще общаться с заказчиком (а лучше - влезть в его шкуру, скажем, на рабочем месте, и понять изнутри насущные потребности клиента).
Со всяким программистом случалось - подходишь ты к коллеге и говоришь: "Слушай, мне нужна твоя помощь. Смотри, вот класс, в нем метод. Метод обращается к такому-то объекту, передавая ему строку и интерфейс ICallback. Так вот, если строка содержит только английские символы, то все хорошо. Если же попадается юникодовая кодировка... погоди, кодировка. Все, я разобрался, спасибо за помощь". Разговор с резиновым утенком, трассировка, тестирование "на доказательство" и другие полезные мелочи зачастую сокращают время отладки в разы.
И др.
Книга легкая, позитивная, содержит множество живых примеров и мало кода. В принципе, доступна для понимания даже непрограммистам, а излагаемые в ней идеи могли бы применяться и в других областях. Рекомендуется. (=
Э. Хант, Д. Томас. Программист-прагматик.
Еще одна книжка по программированию, но не совсем. В "Прагматике" нет сложных алгоритмов, скучных формул, необъятных фреймворков и паттернов с непонятными названиями. Книга ведет речь о тех мелочах, которые встречаются обычному программисту в его работе каждый день, но на которые часто не обращают внимания - до тех пор, пока все не сломается. Большинство вопросов, рассмотренных в книге, так или иначе замечаются разработчиком на подсознательном уровне - книга дает этим вопросам названия, классифицирует их и расставляет по полочкам.
Бывают такие программы, в которых сдвигаешь кнопку в окне на 10 пикселей влево - как вдруг в базе данных что-то отваливается. Прагматичный программист скажет - эта программа недостаточно ортогональна, и у неё высокая связность. В кинге вводятся и разжевываются оба понятия, и дается ряд практических советов, как снизить связность, улучшить ортогональность и поддерживать гибкость архитектуры.
Случается, что команда тратит несколько месяцев на проект, разрабатывает, отлаживает, шлифует, показывает заказчику - и выясняется, что заказчик имел в виду совсем другое. Книга рассказывает прагматичному программисту о прототипах, "стрельбе трассирующими" и настоятельно рекомендует почаще общаться с заказчиком (а лучше - влезть в его шкуру, скажем, на рабочем месте, и понять изнутри насущные потребности клиента).
Со всяким программистом случалось - подходишь ты к коллеге и говоришь: "Слушай, мне нужна твоя помощь. Смотри, вот класс, в нем метод. Метод обращается к такому-то объекту, передавая ему строку и интерфейс ICallback. Так вот, если строка содержит только английские символы, то все хорошо. Если же попадается юникодовая кодировка... погоди, кодировка. Все, я разобрался, спасибо за помощь". Разговор с резиновым утенком, трассировка, тестирование "на доказательство" и другие полезные мелочи зачастую сокращают время отладки в разы.
И др.
Книга легкая, позитивная, содержит множество живых примеров и мало кода. В принципе, доступна для понимания даже непрограммистам, а излагаемые в ней идеи могли бы применяться и в других областях. Рекомендуется. (=
From the series "I read"
E. Hunt, D. Thomas. Pragmatic programmer.
Another book on programming, but not really. In "Pragmatics" there are no complex algorithms, boring formulas, immense frameworks and patterns with incomprehensible names. The book talks about those little things that are encountered by an ordinary programmer in his work every day, but which are often overlooked - until everything breaks down. Most of the questions discussed in the book are somehow noticed by the developer on a subconscious level - the book gives these questions names, classifies them and puts them on the shelves.
There are programs in which you move the button in the window 10 pixels to the left - when suddenly something falls off in the database. A pragmatic programmer will say - this program is not orthogonal enough, and it has high cohesion. King introduces and chews on both concepts, and provides some practical advice on how to reduce connectivity, improve orthogonality, and maintain architecture flexibility.
It happens that a team spends several months on a project, develops, debugs, polishes, shows to the customer - and it turns out that the customer had something completely different in mind. The book tells a pragmatic programmer about prototypes, "tracer shooting" and strongly recommends to communicate with the customer more often (or better - to get into his shoes, say, at the workplace, and understand the client's urgent needs from within).
It happened to every programmer - you come up to a colleague and say: "Listen, I need your help. Look, here is a class, there is a method in it. The method refers to such and such an object, passing it a string and the ICallback interface. So, if the string contains only English characters, then everything is fine. If you come across a Unicode encoding ... wait, encoding. That's it, I figured it out, thanks for the help. " Talking to a rubber duck, tracing, proof testing and other useful little things often reduce debugging time significantly.
And etc.
The book is light, positive, contains many live examples and little code. In principle, it is understandable even for non-programmers, and the ideas presented in it could be applied in other areas. Recommended. (=
E. Hunt, D. Thomas. Pragmatic programmer.
Another book on programming, but not really. In "Pragmatics" there are no complex algorithms, boring formulas, immense frameworks and patterns with incomprehensible names. The book talks about those little things that are encountered by an ordinary programmer in his work every day, but which are often overlooked - until everything breaks down. Most of the questions discussed in the book are somehow noticed by the developer on a subconscious level - the book gives these questions names, classifies them and puts them on the shelves.
There are programs in which you move the button in the window 10 pixels to the left - when suddenly something falls off in the database. A pragmatic programmer will say - this program is not orthogonal enough, and it has high cohesion. King introduces and chews on both concepts, and provides some practical advice on how to reduce connectivity, improve orthogonality, and maintain architecture flexibility.
It happens that a team spends several months on a project, develops, debugs, polishes, shows to the customer - and it turns out that the customer had something completely different in mind. The book tells a pragmatic programmer about prototypes, "tracer shooting" and strongly recommends to communicate with the customer more often (or better - to get into his shoes, say, at the workplace, and understand the client's urgent needs from within).
It happened to every programmer - you come up to a colleague and say: "Listen, I need your help. Look, here is a class, there is a method in it. The method refers to such and such an object, passing it a string and the ICallback interface. So, if the string contains only English characters, then everything is fine. If you come across a Unicode encoding ... wait, encoding. That's it, I figured it out, thanks for the help. " Talking to a rubber duck, tracing, proof testing and other useful little things often reduce debugging time significantly.
And etc.
The book is light, positive, contains many live examples and little code. In principle, it is understandable even for non-programmers, and the ideas presented in it could be applied in other areas. Recommended. (=
У записи 2 лайков,
0 репостов.
0 репостов.
Эту запись оставил(а) на своей стене Владимир Шалимов
