Read books

My professional development like IT specialist I associate with reading IT literature. On this page I update a list of read books (since 2016). While reading I do some notes that seems to me important or just interesting.

2017
  1. Richard Warburton "Java 8 Lambdas"
  2. Benjamin J. Evans and Martijn Verburg "The Well-Grounded Java Developer"
  3. Elegant Objects (Volume 1) "Yegor Bugayenko"
  4. Максим Дорофеев "Джедайские техники"

2016
  1. Kent Beck "Test Driven Development"
    • Дизайн программы должен базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены благодаря чему тестирование кода упрощается.
    • Помните, TDD не обязывает двигаться только микроскопическими шагами, речь идет о способности совершать эти микроскопические шаги. Буду ли я программировать день за днем такими маленькими шагами? Нет. Но когда дела совсем плохи, я рад возможности выполнять хоть такие шаги.
    • Разделяй и властвуй, приятель, — в этом весь смысл! Сначала мы напишем код, «который работает», после чего создадим «чистый код». Такой подход противоположен модели разработки на основе архитектуры, в котором вы сначала пишете «чистый код», а потом мучаетесь, пытаясь интегрировать в проект код, «который работает».
    • Теперь вспомните, что наш цикл состоит из пяти этапов. Иногда последовательное выполнение всех этапов занимает у нас всего несколько секунд, однако в любом случае мы обязательно выполняем каждый из них: 1. Написать тест. 2. Сделать так, чтобы тест откомпилировался. 3. Запустить тест и убедиться в том, что тест не сработал. 4. Сделать так, чтобы тест сработал. 5. Удалить дублирование.
    • На разных этапах решаются разные задачи, преследуются разные цели. То, что совершенно недопустимо для одного из этапов, может быть вполне приемлемым для другого этапа. Однако в целом методика TTD работает только в случае, если ни один из этапов не упущен. Если вы пропустите хотя бы одно звено, развалится вся цепочка.
    • Иногда я плюю на все и пишу тест, не обращая внимания на красную полосу, однако я поступаю так только убедившись в том, что дети уже спят.
    • Цикломатическая сложность (cyclomatic complexity) — это величина, ха­рактеризующая сложность обычного потока управления в программе. Цикломатическая сложность тестов равна 1, так как в тестирующем коде нет ни ветвлений, ни циклов. Цикломатическая сложность функционального кода близка к единице, так как вместо явных ветвлений для передачи управления чаще используется полиморфизм.
    • Как можно оценить качество разработанных нами тестов? Вот два широко распространенных метода: • Покрытие операторов кода (statement coverage). Для оценки качества тестов этой характеристики недостаточно, однако ее можно использовать как отправную точку. Если программист ревностно следует всем требованиям TDD, покрытие функционального кода тестами должно составлять 100 %. Для оценки этой характеристики можно использовать специальные программные средства. • Намеренное добавление дефекта (defect insertion). Это еще один способ проверки качества тестов. Идея проста: необходимо изменить кода и убедиться в том, что тест перестал срабатывать.
    • Существуют три важных навыка, которые необходимо освоить тем, кто впервые изучает TDD: • три основных подхода, которые используются для того, чтобы заставить тест срабатывать: подделка реализации (Fake It), триангуляция (Triangualation) и очевидная реализация (Obvious Implementation); • удаление дублирования между функциональным кодом и тестами — важный способ формирования дизайна; • способность контролировать расстояние между тестами: когда дорога становится скользкой, необходимо двигаться маленькими шажками; когда дальнейший путь ясен, можно увеличить скорость.
    • Когда вы начинаете писать тесты, вы обнаруживаете, что действуете в рамках некоторой общей последовательности (Билл Уэйк (Bill Wake) придумал сокращение ЗА — Arrange, Act, Assert): • вначале вы создаете некоторые тестовые объекты — Arrange; • затем вы заставляете эти объекты действовать — Act; • затем вы проверяете результаты их работы — Assert.
    • Что происходит, когда уровень стресса возрастает? Чем больший стресс вы ощущаете, тем меньше вы тестируете разрабатываемый код. Чем меньше вы тестируете разрабатываемый код, тем больше ошибок вы допускаете. Чем больше ошибок вы допускаете, тем выше уровень стресса, который вы ощущаете. Получается замкнутый круг с позитивной обратной связью: рост стресса приводит к росту стресса. Что надо сделать, чтобы разорвать этот зловещий цикл? Необходимо либо добавить новый элемент, либо заменить один из элементов, либо изменить стрелки. Попробуем заменить тестирование на автоматическое тестирование.
    • «Я только что внес в код изменение. Нарушил ли я тем самым его работоспособность?» При использовании автоматического тестирования, когда я начинаю ощущать стресс, я запускаю тесты. Тесты превращают страх в скуку. «Нет, я ничего не сломал. Тесты попрежнему показывают зеленый цвет.» Чем больший стресс я ощущаю, тем чаще я запускаю тесты. Выполнив тесты, я успокаиваюсь. Когда я спокоен, я допускаю меньше ошибок, а это ведет к снижению уровня стресса.
    • Чтобы убедиться в работоспособности всего приложения, достаточно протестировать каждую из его составных частей. Тестирование части приложения можно выполнить быстрее, чем тестирование всего приложения. Однако самый важный вывод состоял в том, что выполнение одного теста никоим образом не должно влиять на выполнение другого теста. Тесты должны полностью игнорировать друг друга. Если один из тестов не срабатывает, это значит, что в программе присутствует одна проблема. Если не срабатывают два теста, значит, в программе присутствуют две проблемы.
    • Консервативные скалолазы придерживаются одного важного правила. У че­ловека есть две руки и две ноги, всего четыре конечности, которыми он может цепляться за скалу. В любой момент времени по крайней мере три конечности должны быть надежно сцеплены со скалой. Динамические перемещения, когда скалолаз перемещает с места на место одновременно две конечности, считаются чрезвычайно опасными. Методика TDD в чистом виде подразумевает использование похожего принципа: в любой момент времени вы должны быть не дальше одного изменения от зеленой полосы.
    • Каким образом вы можете распространить в своей команде использование авто­матического тестирования? Для любых объяснений используйте тесты и спрашивайте тесты у тех, кто пытается вам что-либо объяснить. Если вы единственный член команды, работающий в стиле TDD вы можете почувствовать себя неуютно и одиноко. Однако вскоре после того, как вы начнете работать в стиле TDD, вы обратите внимание на уменьшение количества проблем, связанных с интеграцией, и снижение количества дефектов, обнаруженных в оттестированном коде. Дизайн вашего кода будет проще и его проще будет объ­яснять. Может случиться так, что ваши коллеги проявят интерес к тестированию и предварительному тестированию разрабатываемого кода.
    • Опасайтесь оголтелого энтузиазма со стороны новичков. Подобный энтузиазм может оттолкнуть тех, кто еще не до конца понял преимущества и необходимость предварительного тестирования. Если внедрение TDD производить насильственными методами, это может привести к негативным результатам. Если вы менеджер или лидер, вы не должны насильно заставлять людей менять стиль, в рамках которого они работают.
    • Что делать, если вы почувствовали усталость или зашли в тупик? Прервите работу и отдохните. Выпейте кофе, пройдитесь или даже вздремните. Стряхните с себя эмоциональное напряжение, связанное с решениями, лами, которые вы набираете на клавиатуре.
    • Дэйв Унгар (Dave Ungar) называет это Методологией душа (Shower Methodology). Если вы знаете, чего писать, пишите. Если вы не знаете, что писать, примите душ и стойте под ним до тех пор, пока не поймете, что нужно писать. Очень многие команды были бы более счастливыми, более продуктивными и пахли бы существенно лучше, если бы они воспользовались этим советом. TDD — это усовершенствование предложенной Унгаром методологии душа. Если вы знаете, что писать, пишите очевидную реализацию (Obvious Implementation). Если вы не знаете, что писать, создайте поддельную реализацию (Fake It). Если правильный дизайн попрежнему не ясен, триангулируйте (Triangulate). Если вы попрежнему незнаете, что писать, можете, наконец, принять душ.
    • Об этом можно не говорить, но я все-таки скажу, что закомментирование теста с целью заставить работать весь тестовый набор строго запрещается и должно приводить к самым серьезным карательным санкциям.
    • Известный слоган гласит: «чистый код, который работает» (clean code that works). Если вы будете решать проблему «чистый код» одновременно с проблемой «который работает», для вас это может оказаться слишком много. Как только вы поймете это, вернитесь обратно к решению проблемы «который работает» и только после этого принимайтесь за решение проблемы «чистый код».
    • Существует проблема: зачастую вам приходится писать больше кода для того, чтобы установить объекты, используемые тестируемым методом, в интересующее вас состояние. Код, инициализирующий объекты, часто оказывается одинаковым для нескольких тестов. Такие объекты называются фикстурой теста (используется также английский термин scaffolding — строительные леса, подмостки).
    • Необходимо понимать, что рефакторинг выполняется не с учетом всех существующих тестов, а с учетом всех возможных тестов. Фраза наподобие: «Я знаю, что там была проблема, но все тесты сработали, поэтому я посчитал код завершенным и интегрировал его в систему», — не может считаться оправданием. Пишите больше тестов.
    • Когда я думаю о необходимом количестве тестов, я пытаюсь оценить приемлемое среднее время между сбоями (MTBF, Mean Time Between Failures).
    • Имеет ли смысл писать тот или иной тест? Это зависит от того, насколько аккуратно вы оцените MTBF. Если обстоятельства требуют, чтобы вы увеличили MTBF от 10 лет до 100 лет, значит, имеет смысл уделить время для разработки самых маловероятных и чрезвычайно редко возникающих ситуаций (если, конечно, вы не можете каким-либо иным образом доказать, что подобные ситуации никогда не могут возникнуть).
    • Взгляд на тестирование в рамках TDD прагматичен. В TDD тесты являются средством достижения цели. Целью является код, в корректности которого мы в достаточной степени уверены. Если знание особенностей реализации без какого-либо теста дает нам уверенность в том, что код работает правильно, мы не будем писать тест. Тестирование черного ящика (когда мы намеренно игнорируем реализацию) обладает рядом преимуществ. Если мы игнорируем код, мы наблюдаем другую систему ценностей: тесты сами по себе представляют для нас ценность. В некоторых ситуациях это вполне оправданный подход, однако он отличается от TDD.
    • Чем больше тестов, тем лучше, однако если два теста являются избыточными по отношению друг к другу, должны ли вы сохранить оба этих теста в наборе? Это зависит от двух критериев: • Первый критерий — это уверенность. Никогда не удаляйте тест, если в ре­ зультате этого снизится ваша уверенность в корректности поведения системы. • Второй критерий — это коммуникация. Если у вас есть два теста, которые тестируют один и тот же участок кода, однако читателем эти тесты рассматриваются как два различных сценария, сохраните оба этих теста.
    • Самая большая проблема заключается в том, что код, изначально написанный без учета тестов, как правило, сложен в тестировании. Интерфейсы и взаимосвязи между объектами не достаточно хорошо спроектированы, поэтому вам сложно изолировать некоторый кусок логики, запустить его и проверить результаты. «Надо это исправить» — скажете вы. Да, однако любой рефакторинг (без применения средств автоматизации), скорее всего, приведет к возникновению ошибок, и эти ошибки сложно будет обнаружить, так как у вас нет тестов. Проблема яйца и курицы. Змея кусает сама себя за хвост. Замкнутый цикл саморазрушения. Что же делать? Прежде всего, скажу, чего делать не надо: не надо писать тесты для всего кода и выполнять рефакторинг всего кода. Для этого может потребоваться несколько месяцев, в течение которых у вас не будет времени добавить в систему новой функциональности. Если вы тратите имеющиеся у вас деньги и при этом не зарабатываете новых, долго вы так не протянете.
    • Поэтому прежде всего мы должны ограничить область планируемых нами изменений. Если мы видим часть системы, которую можно существенно улучшить, но которая вполне может быть оставлена без изменений на текущий момент, мы оставляем их без изменений. Возможно, взглянув на код и вспомнив грехи прошлого, вы не сможете удержаться от слез, однако возьмите себя в руки, — если код не требует немедленного вмешательства, лучше не изменять его.
    • Моя цель заключается в том, чтобы через год работы мне было бы интереснее и приятнее работать над проектом, чем в самом начале проекта, и TDD помогает мне достигнуть этой цели.
    • Когда я добавляю в программу новую функциональность, я не думаю о том, какой дизайн должен быть реализован в данной функции. Я просто пытаюсь добиться срабатывания тестов самым простым из доступных мне спосо­ бов. Когда я переключаюсь в режим рефакторинга, я не беспокоюсь о добавлении в программу новых функций, я думаю только о правильном дизайне. На каждом из этих этапов я концентрируюсь на единственной задаче, благодаря этому мое внимание не распыляется.
  2. Yakov Fain "Enterprise Software without the BS"
    • Simply put, what IT recruiting agencies and real estate agents have in common is that they both work for the other side.
    • The process of getting a job consists of three separate tiers; let's call it an IPO: Getting the Interview, Passing the interview< Considering the Offer I can't stress enough how important it is to work on achieving each of these goals s-e-p-a-r-a-t-e-l-y, one step at a time!
    • Your résumé is the most important entity of tier I. Adjust it for each position you are applying for. (No, I'm not asking you to lie). Make sure it's short and to the point (I've been developing software for more than 25 years and my résumé is only two pages long).
    • You’re in the best position to evaluate an offer, not when your employer decides to let you go or your contract ends, but when you have a stable job, the sky is blue, and the grass is green. A bad offer always sounds better under the pressure of unpaid bills. Have I ever mentioned that you should look for a new job not when your employer decides to let you go or your contract ends, but when you have a stable job, the sky is blue, and the grass is green? This gives you a tremendous advantage: you can consider the offer without being under pressure of unpaid bills.
    • Having software certification does not make your resume stand out. Actually, if a résumé starts with a list of certifications, most likely it's a beginner. I'm not against certifications as they help you to learn the language or a tool, and show that you are willing and can study. But the fact that you have a certificate doesn't mean that you're a skilled professional.
    • What does a good enterprise Java developer have to know in addition to understanding the difference between abstract classes and interfaces? Usually employers are looking for people with at least 10 of the following skills: Java servlets, JSP, Struts or a similar framework, EJB, JMS, any commercial message-oriented middleware, JDBC, JNDI, HTML, XML, Spring, Hibernate, Ant, SQL, one of the major application servers, a couple of relational database management systems, any UML modeling tool, several design patterns (at least a Singleton!), and familiarity with Unix.
    • In the beginning of your career you should switch jobs more often. In general, you shouldn’t work for any employer for more than five years because your technical skills become rusty, you become complacent, and might lose the motivation to learn new skills because the majority of your time is spent not on writing code, but on resolving issues specific to this particular project.
    • You must purchase and read at least five technical books a year. Googling for specific solutions is fine, but you need some more fundamental knowledge. Do not save money on books.
    • Resigning is a very sensitive process, and there are some rules you should be aware of. 1. Don’t resign just because you are angry with your boss. Immediate resignation is not a good answer if the boss was rude, or there was some other conflict at work. Start looking for a job. Don’t resign unless you’ve found a new job or have a substantial amount of cash in your bank account. 2. Announcing the resignation. Give two notices -- one verbal, and the other a written resignation letter or an email. Importantly, the resignation should be short. You shouldn’t write a long letter explaining that you are unhappy, your contribution to the success of the project was not appreciated, etc.. Just write one sentence, for example, “This is a resignation notice, and my last day at work will be October 15, 2008. Thank you for a great experience and a great time, but I’ve gotten an offer that I cannot reject”. This is more than enough. 3. Don’t explain your reasons, and never complain about anything when your. boss or a person from the human resources will be talking to you about your resignation. They may ask, “What did we do wrong? Could you give us some advice so we’d do better in the future?” Do not fall into this trap. They won’ t accept their wrong doings anyway, but your advices will irritate them. Do not forget that you may need to call this person in a month (after resigning) asking for references. Don’t teach them how to run their business. Mind your own business. 4. Never accept counter-offers. 5. Don’t post negative blogs about the company you quit
    • How much does a client pay to your pimp for your services? Typically, your pimp enjoys a 15-30% markup (this number is a lot higher in offshoring situations). The larger the pimp, the higher this number. Is this a reasonable amount? Try not to worry about it. Your pay rate should be your only concern. Do not like it? Try to find a better rate somewhere else. Can’t do? Sit down and shut up. Welcome to capitalism.
    • Hire a professional accountant to do your taxes. Never try to save money by filing your taxes with the help of some inexpensive software. Reputable accountants know how to save your money based on the loopholes in current tax laws in your geographical area.
    • Outsourcing eliminates some jobs and create others. Mostly junior level positions are being outsourced- keep your technical skills in good shape.
    • When the moment is right, you can be ready from a Cialis commercials
    • There are plenty of great programmers who just write code for their employer day in and day out. Raise your head and look around. See what other people with similar skills are up to. You may find a vibrant community of software developers that share your passion. Be a part of it.
    • Being a good software developer is an important part of the game, but you should not ignore something called “managing your manager”. If you are good, you manager has to know about it. Any manager looks for people s/he can depend on, and s/he’ll respect you more knowing about your achievements. Do not just quietly do what you are told to. Do not be shy – manage your manager.
    • Every rejection brings you closer to your goal
    • Henry Ford said, "If you think you can do a thing or think you can't do a thing, you're right". This is my favorite quote.
    • If a cost estimate of one vendor is substantially lower than others, they are either not telling you the whole truth or will be using dirt cheap resources. So how you, the development manager can pick the right vendor that will deliver the project in time (or close to the deadline)? Here’s a solution: give each vendor two weeks and ask them to come back with a working prototype of the system to be developed. Important: you have to pay for this two-week job to each vendor.
    • In the USA, your salary is the most confidential information. Should you even answer the question about your salary? Never. People who are entitled to know this number already know. Only your boss, HR and, sometimes your spouse know this magic number. There’s an unwritten law: never ask your colleagues or even friends how much they make. There is another law: do not brag about your salary trying to impress people.
    • Never use someone's salary in negotiations of your raise
    • You think you are underpaid? Update your resume and hit the job market. Can't do better than now? Sit down and shut up. It's a bit rude, but welcome to the real world.
    • Americans neither ask nor answer questions about salary. But if you run into a newcomer who may ask you directly “What’s your salary?” Just say, ”Even my wife does not know this number”, and give them an American smile.
    • If you are not too happy with this kind of raise, try one of the following two strategies. #1. Do not argue with your boss. Just hit the job market. There are two possible outcomes. Outcome number one: you’ll find out that even $74K is way too much for your skills today, and the best offer you can get is $69K. But the negative result is also a useful result. Keep your current job, improve your technical skills to match the market demand. Just sit tight, study to get your technical skills current and six months later try to hit the market again to see if you can get a better offer. Outcome number two, you’ve got an job offer for $80K. Accept and quit your current job. #2. If you believe that you can make more, explain to your boss why you think so. Give her a chance to re-evaluate your compensation. Wait for a couple of months, and if nothing happens, use the quitting strategy #1. If someone makes you a better offer, quit without thinking twice. The chances are that when you give your two week notice (the industry standard), your current employer will offer you to match or even beat your new deal. And remember the golden rule: don’t accept a counter offer. Can't find a better paid job in your town? Move to a different one. Can't or do not want to? Then do not complain- there is no such thing as underpaid people.
    • Do you think that they pay you too much? Hardly. You worth every penny you make today! If someone will pay you more tomorrow, you’ll be worth every penny too. But that is tomorrow…
    • “Good communication is not 50% listening and 50% talking, It’s more like 80% listening and 20% talking”. It’s very true. Can you listen to someone other than your boss or wife without interrupting for more than three minutes? If yes, you have good communication skills.
    • “Your ideas are worthless”. Exactly! This is long and winding road between your great idea and a PRODUCTION QUALITY software product.
    • “The purpose of 1.0 is to help pay for the development of 2.0”. This means that you should not try to put too many features into the first release of your product – get it out the door and start making some money.
    • Do the same things as other people do, just do them a little better.
    • One day a group of smart software engineers from various companies locked themselves in the room and came out with great principles of developing software projects and published Agile Manifesto http://www.agilemanifesto.org/ : - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan
    • Do not use your employer’s email for sending anything that is not job related. If you are looking for a new job, use your personal email account. Stop sending jokes or funny pictures to your colleagues. Some people do it every day just to let everyone know that they came early today… This also may get you in trouble unless you work for a mom- and-pop company.
    • Let me stress it again, your résumé should be customized for each job that you are applying to. The same facts about your work experience can be presented in multiple ways. As Nelson DeMille wrote in one of his novels, "He never lied. He could give 10 correct answers to the same question."
  3. Chad Fowler "The passionate programmer"
    • Цель бизнеса — делать деньги. Чтобы преуспеть в компании, ты должен четко представлять себе, как ты вписываешься в план добывания денег.
    • Победители рискуют. Они думают о том, чего хотят добиться, а не как подстраховать свои тылы. Планирование карьеры под влиянием страха — это, скорее, не дорога к величию, а ссылка в офис до конца своих дней. Да, это безопасно, но никакого удовольствия при этом получить нельзя.
    • Как правило, наставники не попадают под сокращение
    • Закон Паркинсона является результатом наблюдений, а не неизбежным приговором. Ощущения неотложности, даже надуманного, достаточно, чтобы легко удвоить, а то и утроить твою продуктивность. Попробуй и сам убедишься. Ты можешь справиться с делом быстрее. Можешь сделать все прямо сейчас. Можешь закончить работу, а не
    • обсуждать, как ее закончить. Восприняв рабочий процесс не как пребывание в тюремной камере, а как соревнование, ты сможешь завершить его куда быстрее. Созда-
    • вай движение. Становись тем, кто толкает вперед. Не расслабляйся. Всегда будь тем, кто спрашивает: «А что мы можем сделать прямо сейчас?»
    • Чем более незаменимым ты себя считаешь, тем менее незаменимым ты становишься (и тем меньше людей хотят с тобой работать).
    • Большинство проектов являются долгосрочными. Невозможно пробежать марафон в том же темпе, что и спринт. Если ты начнешь засиживаться допоздна на работе, краткосрочная продуктивность повысится, но в долгосрочной перспективе ты рано или поздно надорвешься настолько серьезно, что затраченное на восстановление время не оправдает результатов, достигнутых за восьмидесятичасовые рабочие недели.
    • Проеки это не спринтерская дистанция, а марафон
    • Распоряжайся своим рабочим временем аккуратно. Работай меньше, и ты начнешь больше успевать. Работа всегда приносит больше удовольствия, когда ты можешь от нее отдохнуть.
    • Человек, всегда говорящий «да», либо обладает невероятными спо- собностями, либо лжет. Чаще всего действительности соответствует второй вариант.
    • Чтобы не доводить дела до логического конца, достаточно не брать на себя никаких обязательств. Если срок исполнения не указан, ничто не заставляет и не мотивирует тебя на трудовые подвиги. Это особенно верно, когда приходится делать нечто не особо интересное. Однако планирование — не горькое лекарство, принимать которое можно, только задержав дыхание. Оно может дать вам освобождение. При наличии слишком большого количества дел именно планирова- ние позволяет перейти от неопределенности, приводящей в замешательство в начале рабочего дня, к четкой уверенности в очередности решения задач.
    • Как мне недавно сказал один начальник, если кто-то делает нечто совершенно фантастическое, но об этом никто не знает, можно считать, что он не делает ничего.
    • Возможно, ты слышал старый философский вопрос: «Если дерево падает в лесу, где никого нет, производит ли оно шум?» Правильный ответ: «А какая разница?»
    • Ты представляешь собой только то, что можешь объяснить
  4. Robert Martin "The Clean Coder: A Code of Conduct for Professional Programmers"
    • Правило бойскаута полностью противоречит отношению некоторых людей к программному коду. Они считают, что серии частых изменений в рабочем коде опасны. Нет! Опасно оставлять код в статическом, неизменном состоянии. Если не проверять код на гибкость, то когда потребуется внести изменения, он может оказаться излишне жестким.
    • Почему многие разработчики боятся вносить частые изменения в свой код? Да потому что они боятся его «сломать»! А почему они этого боятся? Потому что у них нет тестов.
    • Выделенное для самообразование время не должно тратиться на рабочие задачи. Оно должно быть интересным(!) что бы поддерживать энтузиазм оади которого я начал программировать.
    • Проклятие Сантаяны: «Не помнящие прошлого обречены на его повторение».
    • Рабам запрещается говорить «нет». Наемные работники неохотно говорят «нет». Но профессионалу положено говорить «нет». Более того, хорошим руководителям очень нужны люди, у которых хватает смелости сказать «нет». Только так можно действительно чего-то добиться.
    • По собственному опыту могу сказать, что причины намного менее важны, чем факты
    • Если вы не можете выполнить свое обещание, очень важно как можно быстрее сообщить об этом тому, кому вы пообещали.
    • Не пишите код, когда вы устали. Преданность делу и профессионализм проявляются в дисциплине, а не в продолжительности работы. Обязательно следите
    • за сном, здоровьем и образом жизни, что бы вы могли ежедневно посвятить работе восемь хороших часов.
    • У парного программирования есть одно важное преимущество: паре практически невозможно войти в Зону. Состояние зЗоны некомукативно, тогда как парная работа требует интенсивного, постоянного общения. [Что то Боб не любит работать в потоке]
    • На сверхурочную работу можно соглашаться только при выполнении некоторых условий: 1 - лично вы можете себе ее позволить; 2 - аврал будет продолжаться недолго, не более двух недель; 3 - у руководства имеется резервный план на случай, если ваши усилия завершатся неудачей. [Если начальник не может объяснить, что он будет делать в случае неудачного исхода, то не стоит соглашаться на сверхурочную работу]
    • Еще одна профессиональной этики проявляется в том, что опытные программисты берут под опеку молодых программистов и обучают их. Аналогичным образом профессиональная обязанность неопытных программистов заключается в том, чтобы найти наставника и перенять его опыт.
    • Модульные тесты представляют собой документы, описывающие самый нижний архитектурный уровень системы. Они однозначны, точны, написаны на языке понятном для аудитории и достаточно точны и формальны для выполнения. Это самая лучшая низкоуровневая документация, которая только возможна.
    • Одним из самых распространенных аспектов общения между программистами и бизнесом является разработка требований. Бизнесмены описывают то, что по их мнению им нужно, а программисты создают то, что по их мнению им описали.
    • Кент Бек однажды сказал мне очень важдную вещь: "Любой спор, который не удается завершить за 5 минут, не может быть решен обсуждением". Если спор занимает слишком много времени, значит не существует четких доказательств в пользу одной из сторон. В таких ситуациях спор обычно имеет религиозную подоплеку, а не базируется на фактах.
    • Бизнес любит рассматривать оценки как обязательства. Разработчики предпочитают рассматривать их как предположения. Между этими точками зрения существуют принципиальные различия.
    • Важно избегать принятия обязательств на сроки, в соблюдении которых мы не уверены.
    • Один из худших признаков неправильно функционирующей команды - когда каждый программист возводит стену вокруг своего кода и запрещает другим прикасаться к нему. Это верный путь к катастрофе.
    • Профессиональные фирмы-разработчики поручают проекты существующим "притертым" группам, а не формируют группы для конкретного проекта.
    • Проще попросить прощения, чем добиться разрешения.
  5. Frederick Brooks "The Mythical Man-Month"
    • Вторая ошибка рассуждений заключена в самой единице измерения, используемой при оценивании и планировании: человеко-месяц. Стоимость действительно измеряется как произведения числа занятых на количество затраченных месяцев. Но не достигнутый результат. Поэтому использование человеко-месяца как единицы измерения объема работы является опасным заблуждением.
    • Крайне упрощая, сформулируем Закон Брукса: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
    • Архитектура и разработка должны быть тщательно разделены. Как сказал Блау (Blaauw), «архитектура говорит, что должно произойти, а разработка — как сделать, чтобы это произошло».3 В качестве простого примера он приводит часы, архитектура которых состоит из циферблата, стрелок и заводной головки. Ребенок, освоивший это архитектуру, с одинаковой легкостью может узнать время и по ручным часам, и по часам на колокольне.
    • Древнее изречение предупреждает о том, что в море нельзя выходить с двумя хронометрами: нужно взять один или три. То же, очевидно, применимо и к текстовым и формальным определениям. Если имеются оба вида, то один должен быть стандартом, а другой — производным описанием, о чем должно быть прямо указано. Основным стандартом может быть любой из них.
    • Постоянная концентрация сокращает время обдумывания
    • Блок схемы обычно бесполезны и часто создаются задним числом по уже готовой программе
    • Я полагаю, что правильным решением должно быть слияние файлов: включение документации в исходный текст программы. Это одновременно и сильный побудительный мотив к должному сопровождению, и гарантия того, что документация всегда будет самодокументирующимися.
    • Наибольшим вкладом экспертных систем, несомненно, будет предоставление неопытному программисту опыта и всех знаний, накопленных лучшими программистами. И это не мало. Разрыв между лучшими и средними приемами программирования очень велик, возможно, он больше, чем в любой другой инженерной дисциплине. Поэтому средство распространения хороших приемов было бы очень важным.
    • За одинаковые сроки команда может нарастить значительно более сложный объект, чем построить.
    • Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.
    • Задача менеджера не заставить людей работать, а сделать так, чтобы они могли работать.
  6. Steve McConnell "Code Complete"
    • Необходимо программировать с использованием языка, а не на языке.
    • Главный закон контроля качества ПО: повышение качества сокращает сроки и снижает общую стоимость разработки системы.
    • Рефакторинг (определение от Мартина Фаулера) - изменение внутренней структуры ПО без изменения его наблюдаемого поведения, призванное облегчить его понимание и удешевить модификацию.
    • Оптимизация - противоположность рефакторингу, т.к. мы ухудшаем качество кода ради производительности.
    • Лучше сначала писать правильный, понятный код, чем заранее оптимизированный но непонятный. К оптимизации следует приступать только после профилирования, т.к. обычно 20% кода влияют на 80% производительности программы. Следовательно, сначала нужно найти эти 20% кода.
    • Не стоит комментировать плохой код. Его нужно переписать!
    • Тестирование может указать только на наличие ошибок, но не на их отсутствие!
  7. John Sonmez "Soft Skills: The software developer's life manual"

Popular posts from this blog

Java 8 vs GoF: Command

JEEConf 2017 How it was

Java 8 vs GoF: Strategy