клин код дяди боба
Путают с объяснением дяди Боба по обработке Null объектов в книге Clean Code
Сегодня я читал книгу дяди Боба об обработке исключений, и то, что я мог вспомнить из передачи значений null, заключалось в том, что методы не должны обрабатывать значения null, потому что это загромождает код. Меня это немного смущает. Я всегда думал, что метод всегда должен быть уверен, что его зависимости не являются null (если только они не вводятся в конструктор, а конструктор гарантирует обнуляемость). Например, если у меня есть метод
3 ответа
Я пытаюсь использовать чистую архитектуру дяди Боба в своем приложении android. Итак, я последовал за замечательной реализацией этого парня, основанной на RxAndroid, Dagger 2 для DI. Я знаю, что для получения данных из хранилищ данных (Cloud или локальной БД или диска) Интеракторы (классы.
В настоящее время я разрабатываю приложение Android, используя чистую архитектуру дяди Боба как часть обучения чистой архитектуре. В одном из действий я прошу пользователя ввести имя и DOB, я определяю возраст от DOB. Мой вопрос заключается в том, что в слое презентации я создаю класс модели.
Есть две перспективы:
С одной стороны, при вашем подходе вы всегда скажете вызывающему, что именно он сделал неправильно, вызвав ваш метод. Что отлично подходит для вызывающего абонента, потому что он может исправить это сразу же, как только получит ваше исключение. Это было бы верно и справедливо, если бы вы писали код API, который используется третьей стороной.
С другой стороны, если вы сами вызываете свой метод, разумным аргументом для создания исключения является то, что вы хотите иметь возможность справиться с этой ситуацией с помощью блока catch внутри вызывающего кода! Если у вас нет причин обрабатывать его где-то, зачем вообще создавать исключение? Единственная причина, которую я вижу, заключается в том, чтобы иметь подробное ведение журнала ошибок, перехватив эти исключения в GlobalExceptionHandler.
Таким образом, вы видите, что у нас есть две категории исключений: одна для разработчиков, чтобы избежать неправильного использования APIs, а другая для использования в качестве результата ошибки метода.
Если вы пишете код API, который будет использоваться другими, ваш выбор будет заключаться в том, чтобы не слушать Боба 😉
Для тех, кто не читал CleanCode, Боб предлагает две вещи:
1.You не следует писать методы, возвращающие null (чтобы избежать ненужных проверок впоследствии). Поэтому вместо того, чтобы писать это:
. вы должны быть в состоянии написать это:
2.You не должен передавать null вашим методам, чтобы избежать ненужных проверок в начале метода, как здесь:
Суть этих правил такова: если вы будете придерживаться их, вы будете знать, что вам не нужно писать эти null-проверки, и ваш код станет чище и легче читать. Но в тот момент, когда вы используете сторонний код, вы не можете сказать, применили ли они те же правила в своем API, поэтому вы снова начинаете предварительную или последующую проверку. То же самое происходит, когда вы пишете API для других: как потребители вашего API узнают, что вы закодировали с учетом правил Bobs.
Я не читал эту книгу, но могу только представить, что дядя Боб выступает за использование шаблона объекта Null вместо явной обработки ссылок null.
например, вместо того, чтобы
На мой взгляд, это отличается от вашей явной проверки предварительных условий, которую вы имеете в своем примере
Я читал 30 дяди Боба. И я попытался реализовать простые примеры. У меня есть эта схема: Я не могу понять, как я могу реализовать часть в красной линии. Например, у меня есть простая веб-страница: У меня есть 2 кнопки, один отредактированный текст и одна метка. Если я нажму кнопку Отправить на.
Это зависит от того, какой тип кода вы пишете. Если ваш общедоступный метод предназначен для использования широким кругом разработчиков, не знакомых с его использованием, всегда имеет смысл проверить параметры и создать подробное исключение.
Если вы пишете частный метод, который используется только из того же класса или какого-то внутреннего, вызываемого другим дружественным классом, также написанным вами или вашим сотрудником, имеет меньше смысла проверять paranoia null. Ваш дизайн инъекции и тесты должны гарантировать, что ваши внутренние устройства не получают значения null.
И если частные/внутренние параметры метода все еще получают нули, в любом случае уже слишком поздно. Выбрасывание исключения ArgumentNull из частного/внутреннего метода не помогает внешнему пользователю устранить причину, поэтому для него не имеет значения, получит ли он исключение ArgumentNull или NullReference.
Похожие вопросы:
Учитывая чистую архитектуру дяди Боба (или луковую архитектуру) У меня есть следующий сценарий: Я хочу показать пользователю информацию о месте: название, категория, координаты. Я также хочу, чтобы.
Я пытаюсь использовать чистую архитектуру дяди Боба в своем приложении android. Итак, я последовал за замечательной реализацией этого парня, основанной на RxAndroid, Dagger 2 для DI. Я знаю, что для.
В настоящее время я разрабатываю приложение Android, используя чистую архитектуру дяди Боба как часть обучения чистой архитектуре. В одном из действий я прошу пользователя ввести имя и DOB, я.
Я читал 30 дяди Боба. И я попытался реализовать простые примеры. У меня есть эта схема: Я не могу понять, как я могу реализовать часть в красной линии. Например, у меня есть простая веб-страница.
Является ли моя реализация рисунка 12-1 правильной? Это пример реализации загрязнения интерфейса из книги дяди Боба Agile принципы паттерны и практики в C#. Я попытался реализовать его следующим.
Сейчас я читаю книгу дяди Боба Clean Architecture. До сих пор это удивительная книга с большим количеством знаний для меня, но есть кое-что, что я не могу понять. Насколько релевантна инверсия.
Клин код дяди боба
v1: checkout to the v1 branch
Proposed on 2017, archived to v1 branch on 2018
Desc: Initial proposal by me. The story can be read here: https://medium.com/@imantumorang/golang-clean-archithecture-efd6d7c43047
v2: checkout to the v2 branch
Proposed on 2018, archived to v2 branch on 2020
Desc: Improvement from v1. The story can be read here: https://medium.com/@imantumorang/trying-clean-architecture-on-golang-2-44d615bf8fdf
v3: master branch
Proposed on 2019, merged to master on 2020.
Desc: Introducing Domain package, the details can be seen on this PR #21
This is an example of implementation of Clean Architecture in Go (Golang) projects.
Rule of Clean Architecture by Uncle Bob
This project has 4 Domain layer :
The original explanation about this project’s structure can read from this medium’s post : https://medium.com/@imantumorang/golang-clean-archithecture-efd6d7c43047.
It may different already, but the concept still the same in application level, also you can see the change log from v1 to current version in Master.
How To Run This Project
Make Sure you have run the article.sql in your mysql
Since the project already use Go Module, I recommend to put the source code in any folder but GOPATH.
Run the Applications
Here is the steps to run it with docker-compose
In this project, I use some tools listed below. But you can use any simmilar library that have the same purposes. But, well, different library will have different implementation type. Just be creative and use anything that you really need.
About
Go (Golang) Clean Architecture based on Reading Uncle Bob’s Clean Architecture
Uncle Bob’s Clean Code Use Case Definition
THE Question
Do «Application Detail(s)» specific adapters, gateways, and the like, belong in a Use Case Interactor? Or; are Interactors meant to be clean from all adapter abstractions and only interact with Entities and return a POJO?
I have one question and one question only, the one above. All else is just me trying to prove my point or back up my question
Note: What Uncle Bob calls «Application Details» are things like Networking, Databases, API Calls, and methods of delivery (in general)
Example(s):
I have looked and looked. I cannot find any reference to what EXACTLY constitutes as a «use case», within Uncle Bob’s Clean Code Architecture. There is lots of information about how they orchestrate things, how they abstract and hide implementation, sure. But, the more common conversation(s) I tend to see about «Clean Code Use Case Functions» usually talk about stuff that leaves me with more questions than answers. Typically, I read about how the use cases are interactors and how they alone interact with the data layer. When I read about what a use case is (at a high level) as per Uncle Bob’s definition and examples, the «use cases» in these interactors are basically just a UML concept of «use cases». Or at least all of his blog posts and live talks seems to go over the use cases like abstract UML use cases and he never gets into the real code or concepts other than just words as a black-boxed user would know. These use cases describe an abstract set of steps that are SO abstract, one cannot really use them to just start coding right away. You have to interpret his concepts and I believe I might be failing to do so.
I know how to use dependency injection with adapters or gateways in the use case function itself. This hides the implementation from the use case, and instead just calls the function name from an interface. But, technically the use case in the interactor function now always must check for the adapter in question and then fire the interface function. So. the use case kinda «knows» about the «application details». doesn’t it? It doesn’t know the implementation but it still needs to ask, «are you there, adapter? If so, do x».
I have heard talk of «Uncle Bob’s Use Cases» reading like a written sentence (almost) due to the high level of abstraction. But yet, I don’t know how you could do that if you had to include «Application Details» in your use case interactor method. I have yet to see anyone mention what level or scope of «Application Detail» specific code, lands in these use case interactor methods. Do we use adapters via dep-injection here and make fetch calls that return from the API calling function as a POJO? Or is it highly inappropriate to call «Application Detail» specific functionality in the interactor methods?
I am trying not to be specific by saying that the adapters are injected via «constructor» or «method injection» since all languages can use Clean Code, supposedly. But, all languages do not contain interfaces/classes. Anyway.
I noticed that Uncle Bob’s UML use cases always include things like «Update cart» or «Complete transaction». So my assumption was that he is injecting the adapter into the use case and simply calling a function like «completeTransaction». To this, I could imagine him saying,
«we don’t care that there is a network call to be made, we just ask if there is a network adapter present in the parameter list and if so, call the function we require via the interface. A function called completeTransaction «.
It doesn’t matter what the implementation of the completeTransaction function is to the use case function, it just calls the function name inside the adapter and lets the adapter worry about the implementation and the requirement of the function name.
That all being said. now I am tightly coupled to needing «at least 1 Network Adapter», which means my use case function both «knows about the network adapter» but «doesn’t care about what it’s up to».
«You’ll be able to run your tests without delay. You’ll be able to defer decisions about the UI. You’ll be able to test business rules without the UI present. That kind of flexibility and decoupling always speeds you up.»
However, if I include adapters or gateways that use «Application Detail» specific libraries and or classes, then my tests are immediately blocked by needing to start mocking that service. If I started with a use case that used 4 different «Application Detail» specific service(s) (i.e. network call, DB, notification system, and state update) then I would start by immediately being blocked by 4 mocked services.
How does this speed us up and let us use TDD? It’s pretty hard to drive your development with tests when each test starts by being blocked multiple ways.
My Assumption
(what I came to have validated or corrected by asking this question, this isn’t my question. )
I should not be using anything related to any «Application Detail» (such as Network calls, Databases, etc) within a use case no matter how abstract the function seems to be. I should only have 100% business logic in my use case interactors and when I return a POJO from my use case function, the controller that called the use case should then do «Application Detail» specific functionality. I think perhaps Uncle Bob is wanting us to make the domain-level use case functions only interact with Entities and Business Objects in the next layer down (Data), rather than doing anything with injected adapters and controllers. If you remove all non-business-logic-related concepts from your use case, then you are freed up to test without mocking and use these Use Case Function(s) more throughout your codebase, or other codebases in the future (with similar domain knowledge)
What Keeps Confusing Me
UML Use Cases always depict an abstract wording of a concept that requires an Application Detail to accomplish (it seems). Example:
Also, doesn’t it change the use case to include the Network Adapter into a use case function? For example, the following could change:
From this example, you can see that it’s really unclear how to handle the edge case «I have a network connection, but no DB present».
О книге Боба Мартина «Чистый код»
(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))
У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.
Вот и получается, что идеальной аудиторией для этих книг является продвинутый разработчик, окрепший достаточно, чтобы критически оценивать советы «гуру», но при этом не настолько матерый, чтобы эти советы не звучали из разряда «Спасибо, Кэп!».
Хотя, нужно признать, что если в книге «Принципы, паттерны и методики гибкой разработки» спорных советов с моей точки зрения было очень много, то в «Чистом коде» приводится значительно больше разумных и прагматичных советов.
Но поскольку паранойи в книге тоже достаточно, поэтому я хочу начать именно с неоднозначных моментов, а уже потом перейти к радостям.
Спорные и сомнительные моменты
В «Чистом коде» есть несколько откровенно сомнительных моментов. Во-первых, в ней довольно много кода, читать который на страницах книги очень сложно. В 15-й главе рассматривается улучшение парсера командной строки на 60 страницах, 40 из которых – это сплошной код на Java. Главы 16-17 написаны в том же формате, но они короче, поэтому следовать рассуждениям автора проще.
СОМНИТЕЛЬНЫЙ СОВЕТ
Первое правило: функции должны быть компактными. Второе правило: функции должны быть еще компактнее. … Из сказанного выше следует, что блоки в командах if, else, while и т.д. должны состоять из одной строки, в которой обычно содержится вызов функции. Это не только делает вмещающую функцию более компактной, но и способствует документированию кода, поскольку вызываемой в блоке функции можно присвоить удобное содержательное имя.
Некоторые главы откровенно слабые. Мне вообще не понятна цель главы 13 о параллелизме, в которой даются лишь общие сведения о проблемах многопоточности, а затем в приложении А разбираются те же самые темы, но уже более детально и с необходимыми примерами.
Но больше всего меня смущает неоднозначное отношение автора к состоянию и побочным эффектам.
Побочные эффекты суть ложь. Ваша функция обещает делать что-то одно, но делает что-то другое, скрытое от пользователя. Иногда она вносит неожиданные изменения в переменные своего класса – скажем, присваивает им значения параметров, переданных функции…
Несмотря на этот совет, автор во многих примерах использует код с побочными эффектами и отговаривает всеми силами использовать аргументы, используя вместо этого состояние объекта:
СОМНИТЕЛЬНЫЙ СОВЕТ
… Аргументы создают массу проблем с точки зрения тестирования. Только представьте, как трудно составить все тестовые сценарии, проверяющие правильность работы кода со всеми комбинациями аргументов.
В чем разница с точки зрения тестирования между статическим методом с четырьмя аргументами и экземплярного метода объекта с четырьмя полями? Количество граничных условий в обоих случаях одно и тоже; просто в первом случае мы все входные данные протаскиваем явно, а во втором случае – неявно через this.
Стилю кодирования в книге уделено много внимания, при этом большинство советов вполне разумными. Но встречаются и очень неоднозначные:
СОМНИТЕЛЬНЫЙ СОВЕТ
Стандарт кодирования определяет, где объявляются переменные экземпляров; как именуются классы, методы и переменные; как располагаются фигурные скобки и т.д. Документ с явных описанием этих правил не нужен – сам код служит примером оформления.
Перевод
Перевод, мягко говоря, не порадовал. Иногда он «радовал» настолько, что приходилось лезть в оригинал, чтобы понять, о чем идет речь:
ЦИТАТА
Когда у вас появился полный набор тестов, можно заняться чисткой кода и классов.
Для этого код подвергается последовательной переработке (рефакторингу). Мы добавляем несколько строк кода, делаем паузу и анализируем новую архитектуру.
WTF! Как добавление двух строк может повлиять на архитектуру. Есть два варианта: либо мы имеем дело с очень длинными строками, или же авторы здесь говорят не об архитектуре, а о чем-то ином, например, о дизайне! Вся глава 12 (из которой взята эта цитата) полностью испорчена тем, что термин “design” переведен в ней как «архитектура», что делает многие советы автора спорными.
Как обычно, переводчики не потрудились оставить оригинальные термины, так что приходилось догадываться, что же имеется ввиду под терминами «логическая привязка» или «многопоточность» (оказывается, что это high coupling и concurrency, соответственно).
Поскольку содержимое книги относительно простое, то переводчикам удалось лишь «подпортить» впечатление, но не запороть ее полностью.
Дельные советы
На самом деле, все не настолько плохо и «дядюшка» Боб сотоварищи дают много хороших советов. Вот некоторые из них:
Об именовании
Не используйте имена, передающие информацию о реализации. Имена должны отражать уровень абстракции, на котором работает класс или функция.
О понятности кода
Легко писать код, понятный для нас самих, потому что в момент его написания мы глубоко понимаем решаемую проблему. У других программистов, которые будут заниматься сопровождением этого кода, такого понимания не будет.
О длине и выразительности имен
Длина имени должна быть связана с длиной его области видимости. Переменным с крошечной областью видимости можно присваивать очень короткие имена, но у переменных с большей областью видимости имена должны быть длинными. … Таки образом, чем длиннее область видимости, тем более длинным и точным должно быть ее имя.
О содержимом функций
Все операторы в функции должны находиться на одном уровне абстракции, который должен быть на один уровень ниже операции, описываемой именем функции.
Совет кажется простым, но он очень ценен. Код должен читаться, как хорошая проза, а для этого просто необходимо, чтобы функция содержала операторы одного уровня.
Юнит-тесты в качестве инструмента изучения библиотек
Изучение чужого кода – непростая задача. Интеграция чужого кода тоже сложна. Одновременное решение обоих задач создает двойственные сложности. А что, если пойти по другому пути? Вместо того, чтобы экспериментировать и опробовать новую библиотеку в коде продукта, можно написать тесты. Проверяющие наше понимание стороннего кода. Джим Ньюкирк (JimNewkirk) называет такие тесты «учебными тестами».
Этому совету я следую давно и использую юнит-тесты для изучения новых инструментов и библиотек. Это позволяет лучше разобраться с библиотекой и легко возвращаться к примерам использования, поскольку они всегда под рукой.
Очень повеселил один совет. Давайте так: что вам говорит магическая константа 5280? Ничего? Странно, по словам автора, это одно из значений, которое можно спокойно «хардкодить»!
Некоторые числа так легко узнаются, что их не обязательно скрывать за именованными константами – при условии, что они используются в сочетании с ясным кодом. … Число 5280 – количество футов в миле – настолько хорошо известно и уникально, что читатель сразу узнает его, даже если оно будет располагаться вне какого-либо контекста.
Качество книги можно косвенно оценить по количеству интересных цитат и количеству блог-постов, появившихся в процессе чтения. И если в процессе чтения «Принципов, паттернов и методик» появились критические статьи типа «Контракты, состояние и юнит-тесты», то в результате «Чистого кода» появились «Пять принципов чистых тестов» и «Лучшая метрика для определения качества кода».
Достоинства: приличное количество приличных советов
Недостатки: часть советов весьма спорны; иногда советы непоследовательны; перевод хромает на обе ноги.
Книги, которые в 2019 году должен прочесть каждый разработчик-джуниор.
Книги – это один из лучших источников информации для программистов. Будь вы начинающим разработчиком или достаточно опытным программистом, рано или поздно вы начинаете понимать, что количество лет стажа не определяет объема знаний и навыков в программировании. Успех в этой отрасли зависит от самообразования. Ниже приведены несколько из лучших книг на 2019 год. Они высоко ценятся профессионалами в отрасли разработки.
1. Clean Code («Чистый код», автор – Роберт Сесил Мартин (Дядя Боб))
Освоить данную книгу будет хорошей идеей, когда вы овладеете основами разработки и немного освоитесь в написании кода и решении проблем. Благодаря книги вы поймёте, что написать рабочий код с первого раза – это не так сложно, как сделать ваш код лёгким для понимания, читаемым для других людей и пригодным для внесения изменений.
function calculateIt (a, b) <
if (a.delta
Эта книга не техническая, она учит вас, как стать профессионалом в сфере разработки. Под профессионалом понимается человек, который, сталкиваясь с трудностями и неопределенностью, продолжает рассматривать создание ПО как искусство и продолжает придерживаться своих профессиональных ценностей.
В этой книге много практических советов по оценке нужного количества времени и ресурсов, рефакторингу, тестированию, разрешению конфликтов, составлению расписаний, предотвращению профессионального выгорания и многим другим темам. Автор данной книги занимался этим десятки лет.
Одна из лучших вещей, которым учит эта книга, – знание того, когда нужно сказать «нет», и умение это сделать.
3. Refactoring («Рефакторинг. Улучшение существующего кода», автор – Мартин Фаулер)
«Весёлый» стиль написания этой книги очень примечателен среди других. Автор также невероятно хорош в объяснении сложных тем, делая это простым языком, не утомляя читателя. Создатель Ruby on Rails однажды сказал о книге «Рефакторинг», что ее «стоит прочитать, прежде чем писать следующую строчку кода».
Фаулер в своей книге проводит вас по пути рефакторинга простого приложения, знакомя со многими техниками, которые он сам собрал и каталогизировал за годы работы.
Фаулер показывает, как переключаться с написания кода на рефакторинг, как часто нужно делать коммиты и когда писать тесты.
В последнюю версии книги включены примеры на JS.
4. Design Patterns: Elements of Reusable Object-Oriented Software («Приёмы объектно-ориентированного проектирования. Паттерны проектирования», авторы – Эрих Гамма, Ричард Хелм, Ральф Джонсон и Джон Влиссидес)
Если хотите почитать что-то поновее и «подружелюбнее», также можно посоветовать «Head First Design Patterns: A Brain-Friendly Guide» («Паттерны проектирования» из серии Head First) Эрика Фримена.
5. Domain-Driven Design: Tackling Complexity in the Heart of Software («Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем», автор – Эрик Эванс)
Чтобы крупные кодовые базы имели возможность масштабирования, нам нужно логически разбивать код на отдельные части. Идея состоит в том, чтобы делить код таким образом, чтобы над разными его частями могли независимы работать разные команды.
Такой подход базируется на концепции предметно-ориентированного проектирования (DDD). Он становится очень важным при расширении кодовой базы. Крупные компании применяют DDD, чтобы поручать различные части кодовой базы компании отдельным командам разработчиков.
Автор вводит понятие «общего языка». Под ним подразумевается создание общего, всеобъемлющего языка, понятного любым пользователям этой отрасли. Использование этого языка гарантирует, что все самые важные концепции будут правильно поняты и смоделированы в программе.
Эта книга немного сложнее, чем остальные, но если вы разберетесь в её материале, то будете лучше понимать, каким образом крупнейшие современные компании поддерживают свои кодовые базы в управляемом и масштабируемом состоянии.
6. Soft Skills: The Software Developer’s Life Manual («Путь программиста», автор – Джон Сонмез)
Книга «Путь программиста» посвящена вещам, не связанным напрямую с написанием кода, но имеющим большое значение. К ним относятся продуктивность, карьерные цели, личные финансы. Автор также затрагивает тему инвестиций, рассказывает, как он вышел на пенсию в 33 года, дает советы относительно здорового образа жизни и поддержания хороших отношений с людьми. То есть, говорит о вещах, редко упоминаемых в сообществе разработчиков.
Главы книги можно читать по отдельности, выбирая наиболее актуальную для вас на этом этапе.
7. Clean Architecture («Чистая архитектура. Искусство разработки программного обеспечения», автор – Роберт С. Мартин (Дядя Боб))
В учебных заведениях больше внимания уделяется алгоритмам и меньше – принципам проектирования программ. Это скорее минус, ведь в реальности вы не так уж часто встречаетесь с алгоритмическими задачами. Гораздо чаще перед вами встает необходимость структурировать свой код таким образом, чтобы он был модульным, гибким, читаемым и позволял вам быстро добавлять новый функционал по мере изменения требований. Книга «Clean Architecture» посвящена основным принципам проектирования и шаблонам, которые вы сможете применять для решения указанных выше проблем.
Лучшие идеи из этой книги – стоимость зависимостей, стабильный и нестабильный код, а также принципы SOLID. Все это помогает писать более понятный, гибкий и поддерживаемый код.
Кроме того, очень полезными являются концепции «кричащей архитектуры» и «покомпонентной упаковки», касающиеся того, как нужно организовывать модули, чтобы они практически «кричали» читателю о том, что такое этот проект.
Эта книга хорошо сочетается с «Domain-Driven Design», поскольку предметно-ориентированное проектирование становится возможным благодаря использованию «Многоуровневой архитектуры» или, как называет ее Дядя Боб, «Чистой архитектуры». Отличная книга для каждого, кто хочет усовершенствовать свои приемы работы и узнать, как эффективно проектировать систему на высоком уровне.
8. The Effective Engineer («Справочник эффективного инженера», автор – Эдмонд Лау)
9. The Pragmatic Programmer («Программист-прагматик. Путь от подмастерья к мастеру», авторы – Эндрю Хант, Дэвид Томас)
Эту книгу хвалят за простоту изложения и доступность для понимания. Она должна стать настольной книгой каждого разработчика. Эндрю и Дэвид – программисты, которые не только много лет посвятили своей работе: они при этом еще и обращали пристальное внимание на свои действия и пытались определить, можно ли в этих действиях что-то улучшить.
Плодом подобных упражнений в самоанализе стала книга «Программист-прагматик». В ней изложены идеи, которых разработчикам следует придерживаться в своей карьере. Например, принцип «делать единожды или автоматизировать».
В этой книге вы найдете простые, но подробные советы, которыми стоит вооружиться, прежде чем писать следующую строчку кода или начинать новый проект.