Полезные конспекты книг и авторские заметки по информационным технологиям. Без формул
Автор-составитель Алексей Сергеевич Лот
ISBN 978-5-0060-3257-6
Создано в интеллектуальной издательской системе Ridero
Книга содержит упоминание организаций, запрещенных на территории РФ: «Фейсбук».
Полезные высказывания из книги «Agile для всех» Лемея
В разделе приведены цитаты из [1].
Agile – термин, описывающий схожие по сути, но различные по методикам подходы. Самый популярный Agile-подход – это скрам:
1) работа разбивается на двухнедельные периоды, называемые спринтами;
2) в конце каждого периода должно быть что-то действительно завершенное и готовое для выпуска;
3) в течение каждого спринта проводится ежедневная планерка (daily standup) или скрам-митинг (scrum meeting);
4) во время митинга каждый член команды делится тем, что он завершил, над чем работает и что может препятствовать прогрессу;
5) идея получать что-то готовое каждые две недели – стимул для повышения производительности и укрепления морального духа;
6) необходимость личного общения каждое утро – способ улучшить коммуникацию в команде (выявить разногласия);
7) приоритизация и передача результатов в двухнедельные циклы позволяют объективировать противоречия в видении продукта высокого уровня;
8) утренние планерки показывают отставание по срокам;
9) цель – повысить эффективность команды;
10) скрам дает набор рабочих процедур для структурирования деятельности компании.
Agile требует соответствия предпринимаемых действий достигаемым целям, ставя вопрос о том, почему сотрудники, команды и организации делают так, а не иначе. Agile предполагает выполнение большего объема работ за меньшее время при условии привлечения больших ресурсов: энергии, открытости, готовности честно размышлять над трудными вопросами. Agile призывает превращать предположения в факты.
Agile можно применять во всех отраслях. Нет лучшего или правильного подхода к Agile.
Принципы и ценности «Почему» – Практики «Как» – Результаты реального мира «Что» – Принципы и ценности «Почему».
Если мы чувствуем, что не соответствуем «Почему», то можем менять «Как», а если «Как» не срабатывает для «Что», то нужно пересмотреть «Почему». Сначала нужно понять, почему возникла потребность в изменении привычного способа работы. Основополагающие принципы Agile:
1) мы начинаем с наших клиентов;
2) мы сотрудничаем на ранних стадиях и часто;
3) мы планируем неопределенность.
Манифест Agile:
– люди и взаимодействие важнее процессов и инструментов;
– работающий продукт важнее исчерпывающей документации;
– сотрудничество с заказчиком важнее согласования условий контракта;
– готовность к изменениям важнее следования первоначальному плану.
Важное здесь не отрицает остального. Mindset – образ мышления.
2001 – основание Agile-движения.
1995 – Scrum.
90-е – Crystal.
1999 – XP.
2005 – LeSS.
2011 – SAFe.
Agile Alliance: Agile – способность создавать изменения и реагировать на них, чтобы добиться успеха в неопределенной и турбулентной среде. Ошибочный путь наименьшего сопротивления:
– люди в организации будут избегать работы с клиентами, если она выходит за рамки их повседневных обязанностей и не приносит бонусов;
– люди в организации будут отдавать предпочтение работе, которую могут выполнить с наименьшими усилиями, не покидая собственную команду или отдел;
– работа над текущим проектом будет продолжаться до тех пор, пока не вмешается самый старший из тех, кто его одобрил.
В Agile команда выдает готовый результат за каждый временной блок (time box). В конце каждого временного блока собирается обратная связь от предполагаемой аудитории, и на ее основе планируется следующий набор временных блоков, называемых итерацией. В реальном мире идеальный Agile недостижим. Движения наподобие Agile отвечают на один и тот же вопрос: «Как организации могут адаптироваться к потребностям клиентов в быстро меняющемся мире?» Движения отличаются метриками успеха организации:
Agile – скорость (velocity), с которой команда выпускает продукты;
Lean – количество потерь, которое команда исключает из производства;
Design Thinking – количество ценности, которую продукты команды предоставляют клиентам.
При использовании трех подходов важность метрик определяется ранжированием движений в организации. Чтобы не менять подходы Agile один за одним, нужно до выбора подхода задаваться вопросом: «Какие у нас цели и как наш способ работы помешал их достигнуть?», а после: «Какие Agile-ценности и принципы помогут достичь конкретных целей?» Клиентоориентированность означает думать о потребностях, целях и опыте, прежде чем думать о конкретной вещи, которую мы собираемся доставить клиентам. Потребности и цели коллег, руководителей и клиентов могут не совпадать, но их нужно примирять. Гибкость измеряется способностью меняться и развиваться в зависимости от потребностей клиента, а не скоростью выполнения работ. Dogfooding – разработка версии приложения для тестирования и внутреннего использования. Вопросы в Agile нужно ставить с точки зрения клиента. Сотрудники организации должны работать с клиентами напрямую. Клиенты выбирают тот опыт, который наилучшим образом соответствует их потребностям и целям, а не тот, который является самым «инновационным» или «прорывным». Во втором принципе Agile сотрудничество на ранних стадиях означает сотрудничество во время как стратегических, так и тактических переговоров, открывая возможность поиска новых и неочевидных решений, что требует открытости, восприимчивости и готовности делиться идеями; частое сотрудничество означает продолжение обсуждений на протяжении всего процесса создания и реализации, обеспечивая согласованность стратегии и тактики, чтобы получить больше возможностей для корректировки курса по мере необходимости. Модель Spotify – многоуровневая многофункциональная система, где люди работают на уровне «отрядов», «кланов», «отделов», «гильдий». Нужно поддерживать неформальное общение друг с другом, а не ждать совещания. На каждое совещание должно отводиться строго определенное количество времени – идея тайм-боксинга. При встраивании в рабочий процесс сначала задать вопрос: «На каком мы этапе? Кто занимался решением этой задачи?» Ежедневные планерки должны длиться не более пятнадцати минут, во время которых все стоят на ногах и отвечают на вопросы:
– что я сделал вчера, чтобы помочь команде разработки достичь цели спринта?
– что я сделаю сегодня, чтобы помочь команде разработки достичь цели спринта?
– какие препятствия мешают мне или команде разработки достичь цели спринта?
Ретроспектива – это совещание в конце спринта или подведение итогов по проекту, на котором команда обменивается мнениями по поводу проведенной совместной работы и определяет изменения, которые можно внести при подготовке к следующему спринту или проекту, но не критикует проведенную работу. Ретроспектива дает командам возможность выстроить общее понимание цели и ответственности в рамках работы. Основные вопросы: «Как вы считаете, наш рабочий процесс помогает нам воплощать в жизнь наши методы и достигать наших целей?», «Каким образом мы будем действовать в следующий раз?» Post mortem – собрания, во время которых участники открыто обсуждают ошибки, не боясь наказания. Ретроспектива дает возможность менять Agile-методы команды. Сворачивание проекта означает, что вы открыты к возможным изменениям клиентов и не собираетесь тратить дополнительные ресурсы на проект, которому не суждено стать успешным. Абсолютные количественные параметры оценки Agile-методов превратят Agile в бессмысленный список задач. Большинство людей предпочитают определенность страданий страданиям неопределенности. Названия принципов Agile: клиентоориентированность, сотрудничество, открытость к переменам. Необязательно использовать все три принципа. Нельзя скрывать от руководителей плохие новости. Процесс крайне прост: голова, сердце, руки. Нужно отслеживать скорость рынка чаще скорости внутри компании.
Полезные высказывания из книги «E-mail маркетинг» Демина
В разделе приведены цитаты из [2].
Сегодня, чтобы человек совершил покупку, потенциальный клиент должен увидеть вашу рекламу, новость о вас или ваш логотип 24 раза.
Главная цель e-mail маркетинга – не просто продажа товаров (услуг), а формирование доверия и лояльности клиента.
Сформируйте доверие; покажите, что вы – профессионал в своем деле, поделитесь интересной, ценной или полезной информацией, и продажи неуклонно пойдут вверх.
E-mail маркетинг приносит денег больше, чем любая другая реклама.
Чем подробнее сегментирована база по различным характеристикам клиентов, тем выше продажи.
Для рассылок нужно использовать специальные почтовые сервисы, чтобы обычный почтовый ящик не заблокировали.
Бесплатный сервис до 2000 подписчиков – MailChimp.
Единственное, где понадобится бюджет, – сбор активных подписчиков.
В рассылках можно писать новости, обзоры удачных и неудачных сайтов, выдавать свой опыт по частям, делиться фотоотчетами.
Выбирают часто тех, кто в рассылке показал свою деятельность и уровень навыков.
Рассылка позволяет не зависеть от рекламных агентств, промоутеров и продавцов.
Схема работы e-mail маркетинга:
1. Стратегия и задачи, оценка своего нынешнего состояния (о клиенте, о проблеме).
2. Форма регистрации/подписки.
3. Одностраничник.
4. Привлечение подписчиков.
5. Выбор сервиса для отправки почты.
6. «Пряник» за регистрацию.
7. Виды писем: тестовые письма, письма-подтверждения, транзакционные письма, автописьма, цепочки писем, триггеры, разовые письма.
8. «Мягкие» продажи.
9. Усиление накала.
10. Акция или специальное предложение.
11. Сегментация.
12. Замедление, выдача контента.
Чтобы люди вас читали и ждали писем, рассылка должна решать конкретную проблему или ряд проблем и быть написана для одного человека или нескольких.
Составьте портрет каждого вашего потенциального клиента, максимально близкие к конкретному человеку.
Критерии сегментации:
– имя;
– пол;
– семейное положение;
– если женат/замужем – кто супруг (а);
– дети;
– какие отношения с детьми;
– чем человек занимается, на что живет;
– в чем его самая большая неудовлетворенность;
– какое самое сильное внешнее желание (человек говорит об этом; для бизнесмена – расширение бизнеса);
– сокровенные желания (чего хочет на самом деле); например, лежать и ничего не делать;
– кто раздражает и сердит.
Затем ответьте, какую проблему этого человека решает ваша рассылка.
В интернете взаимодействуют с контентом не более 1% аудитории (ставят лайки, оставляют комментарии).
Анализируйте работу конкурентов и учитесь у них.
Почтовые сервисы предоставляют код формы подписки для размещения на своем сайте.
Максимально эффективно можно использовать имя клиента, e-mail и номер телефона.
В среднем лишь 30% оставленных номеров реальные.
Всплывающие окна с формами подписки повышают конверсию в среднем на 30%.
На «приземляющей» странице обычно есть текст о товаре (услуге), фотографии товара или клиентов, отзывы, видеоролики, графики, форма подписки или заказа. Нет лишь ссылок на другие страницы и ресурсы, поэтому одностраничники дают самую высокую конверсию.
Большие одностраничники делают с целью продажи чего-либо.
Заголовок «приземляющей» страницы должен быть конкретным и содержать конечную выгоду – это первое, на что обращают внимание посетители.
До 80% эффективности любой рекламы зависит именно от заголовка.
На одностраничном сайте ничто не должно отвлекать клиента от совершения задуманного вами действия: ни ссылки на другие сайты, ни странные картинки, ни заумный текст. Если вы сомневаетесь в необходимости какого-то элемента, смело его удаляйте.
Незамысловатые, простые и близкие человеку видео вызывают намного больше доверия, чем рекламные ролики.
Можно рассказать о товаре своими словами, продемонстрировать главные преимущества.
Описывайте не сам продукт, а преимущества, которые благодаря ему получит ваш клиент.
Посетитель должен понимать, что ему нужно сделать, чтобы воспользоваться вашим предложением: ввести свои данные, нажать кнопку, позвонить. Отсутствие такого элемента может снизить эффективность страницы до 70%.
Отзывы реальных клиентов повышают доверие к вам и вашей организации: они могут быть в виде текста или видео. Для максимального эффекта от текста нужна фотография человека, оставившего отзыв, его имя и название организации, в которой он работает. Идеально, если будет некликабельный адрес сайта. Каждый отзыв начинается с подзаголовка – это может быть ударная фраза или главные преимущества товара (услуги).
Маркированные списки – это краткое описание товара. Короткие фразы привлекают внимание, быстро читаются и дают понять, чем вы отличаетесь от конкурентов.
Кнопки соцсетей помогут пользователю поделиться ссылкой на ваш одностраничник и так привлечь новых клиентов.
Дизайном пренебрегать не стоит. Графики, диаграммы и инфографика отлично привлекают внимание и удерживают читателя.
Нужно составить техзадание:
– дизайнер делает сам дизайн, подбирает картинки, цветовую гамму, шрифты и так далее;
– копирайтер наполняет страницу продающими текстами, которые буквально заставляют купить товар (услугу);
– программист собирает все пазлы в единую картину (можно обойтись услугами веб-дизайнера).
Есть сервисы создания одностраничников.
Самые популярные сервисы по статистике сайта:
– Google analytics;
– LiveInternet;
– «Яндекс. Метрика».
Если на сайт зашли 1000 человек, а подписались на рассылку 100 – значит, конверсия страницы – 10%.
Способы привлечения подписчиков:
1. Статьи в СМИ (в них максимум указать название организации, себя как автора и ссылку на сайт).
2. «Вирусный» маркетинг.
3. Форумы – создать тему с бесплатной консультацией на свою тему.
4. «Твиттер».
5. «Фейсбук1.
6. «Ютуб» – запись максимум 2—3 минуты.
7. Паблик в «ВКонтакте».
Чем уже тематика, тем более качественных подписчиков получите.
8. Купонные сайты.
9. Отзывы.
10. Subscribe.
11. Сервисы ответов.
12. Обмен ссылками, SEO-оптимизация.
wordstat.yandex.ru
13. Википедия.
14. Собственная партнерская программа.
15. Ссылка с призывом в подписи.
16. PodFM.
17. Социальные комментарии к вашему сайту или страничке (в соцсети).
18. Клиенты на «живых» мероприятиях.
19. Официальные документы, книги, договора, счета и тому подобное.
20. Доменное имя.
21. Всплывающие окна PopUp.
22. RSS-лента.
23. Создайте материал, которым хочется поделиться.
24. Реклама подписки в других тематических рассылках.
25. Ссылка на форму подписки в счете.
26. Офлайн-подписка.
27. Предложение о подписке на визитке.
28. QR-код.
29. Конкурсы, викторины, розыгрыши.
30. Ограничьте ваше предложение.
31. Просто попросите распространить.
32. Сосредоточьтесь на интересах существующих подписчиков.
33. Учитывайте конфиденциальность данных подписчиков.
«Яндекс. Директ», Google AdWords.
Реклама: в почтовой выдаче, на тематических площадках.
Именно контекстная реклама – один из самых простых способов сразу получить горячих подписчиков.
CTR.
Ищите слова, которые еще никто не додумался использовать для объявлений.
Подписка через VK только для массового потребителя.
Большая часть информации в соцсетях воспринимается визуально.
Картинка в рекламном посте и на приземляющей странице должны иметь что-то общее.
Первым откликом на рекламу в соцсети могут быть гневные отзывы.
Пряник – бесплатность за подписку.
Кнут – любой прием, который вынуждает человека действовать незамедлительно.
Можно начать продажу в первом письме.
Профессиональные сервисы рассылок: emailVision, exactTarget, intelligentEmails.
Полупрофессиональные сервисы рассылок: Pechkin-mail, SmartResponder, mailigen, mailChimp, epochta, Subscribe, justclick, unisender.
Письма с подтверждениями люди открывают чаще всего. Не забывайте о «взрослении» аудитории.
Принципы (элементы) копирайтинга:
1.Заголовок должен заставить человека прочесть первый абзац. Шрифты в заголовке отлично привлекают внимание в вызывают больше доверия. Ровным числам – 10, 20, 30 – люи доверяют меньше, чем неровным – 15, 17, 21.
2. Подзаголовок раскрывает суть заголовка.
3. Короткое первое предложение.
4. Заголовки параграфов помогают быстро оценить текст.
5. Первый абзац – простой и понятный.
6. Снимок или рисунок (текст с изображением больше привлекает внимание).
7. Подпись под изображением – мощная фраза.
8. Описание продукта.
9. Технические характеристики.
10. Отзывы, свидетельства, награды (нельзя подделывать!).
11. Цена.
12. Вид обратной связи для вопросов.
13. Предугаданные возражения.
14. Итоги.
15. Призыв к действию (чего хотите от читателя?).
16. Причина реагировать сейчас.
17. Способы оплаты – можно платежный агрегатор.
18. Гарантия.
19. Постскриптум.
Максимальное внимание привлекает первый квадрат 500 на 500 пикселов.
Не более 3-х шрифтов в письме.
Самые читаемые – четырех-пятистрочные абзацы.
Оптимальная ширина письма – 600 пикселей, или 60—80 символов 10—12 pt.
Фон в письме – белый или светлых оттенков.
С HTML можно создать уникальный дизайн или фирменный стиль писем, чтобы сразу понимали, что речь идет о вашей компании, можно вставить в письмо кнопки соцсетей.
С картинкой в письме обязательно должен быть текст.
Вопросы для проверки своего письма: что хотите сообщить заказчику; почему вам должно быть это интересно; что вы хотите, чтобы сделал подписчик; куда попадают ваши подписчики после переходов по ссылкам в письме; не перегружает ли дизайн текст или другие объекты.
Проверять письмо в разных браузерах до отправки и проверять ссылки.
Рассылать разную рекламу для проверки реакции на содержимое.
B2B – на вы.
B2C – на ты или вы.
Обязательна ссылка в письме, но не более 3-х.
Рассылка должна быть регулярной.
Чем больше о вас знают потенциальные клиенты, тем лучше.
В 2016 году в мире будет отправляться более 192 млрд писем в день.
Разбивать аудиторию хотя бы на 3 группы.
Чем больше вы знаете о подписчиках, тем лучше.
Переподписка – раз в несколько месяцев.
В e-mail маркетинге важны взаимоотношения с клиентом, а не хитрости и уловки.
Отписываться будут всегда.
Чем больше неактивных клиентов, тем чаще письма будут попадать в спам, поэтому неактивных лучше удалять самостоятельно.
Рассылку надо планировать на 3—6 месяцев.
Анализировать отношение открытий к переходам.
Полезные высказывания из книги «Чистый код» Мартина
В разделе приведены цитаты из [3].
Единственный способ выдержать график – постоянно поддерживать чистоту в коде.
Поэтому нужно развивать «чувство кода».
Чистый код:
– элегантный и эффективный;
– логика прямолинейна;
– зависимости – минимальные;
– обработка ошибок – полная;
– производительность – близкая к оптимальной;
– решает одну задачу;
– поддерживается в чистоте с течением времени.
Следующая книга – «Agile software development; Principles, patterns, and practices», 2002.
Содержательные имена:
– имена всех объектов должны отвечать на все главные вопросы: почему существует, что делает и как используется, не требуют дополнительных комментариев, содержательные, передают намерения программиста;
– код очевиден, контекст следует из самого кода;
– не содержат ложных ассоциаций, затемняющих смысл кода;
– не используются слова со скрытыми значениями, отличными от предполагаемого;
– лучше обойтись без кодирования типа контейнера в имени.
Имена не содержат малозаметных различий, непохожи друг на друга излишне.
Имена не дезинформируют.
0 не равен O, 1 не равна l.
Используется правильный шрифт.
Используются осмысленные различия.
Имена не дублируют зарезервированные слова с незначительными изменениями.
Если имена различаются, они должны обозначать разные понятия.
Различия имен содержательны.
Префиксы используются, если создают осмысленные различия.
Не содержат неинформативных, избыточных слов.
Имена не отличаются только суффиксами.
Читателю кода понятен смысл различающихся имен – нет соблазна использовать 2 похожих имени по одному назначению.
Имена удобопроизносимы.
Программирование – социальная деятельность.
Не должны состоять из одних сокращений.
Состоят преимущественно из слов разговорной речи.
Удобны для поиска.
Легко находимы в большом объеме кода.
Относительно редкие.
Длинные имена лучше коротких.
Однобуквенные используются только для локальных переменных в коротких методах.
Длина имени соответствует размеру его области видимости.
Имя не содержит информации о типе или области видимости.
Не создает хлопот при расшифровке.
Неразумно заставлять каждого нового работника изучать очередной «язык» кодирования.
Имя остается понятным даже в случае опечатки.
Имя не усложняет изменение типа переменной.
Типы в именах не кодируются.
Переменные классов без префиксов.
Классы и функции компактны – можно обойтись без префиксов.
Имя не содержит балласта.
Имена интерфейсов без префиксов.
Имена не содержат лишней информации.
Не заставляют мысленно преобразовывать имена в другие.
Используются имена из пространств задачи и решения.
Счетчик цикла с малой областью видимости можно назвать 1 буквой – это традиция.
Ясность превыше всего.
Код понятен для других людей.
Имена классов и объектов – существительные и их комбинации без глаголов, не содержат обобщенных понятий – Manager, Processor, Data, Info.
Имена методов – глаголы или глагольные словосочетания.
Методы чтения или записи и предикаты образуются из значения и префикса get, set и is.
При перегрузке конструкторов использовать статические методы-фабрики с именами, описывающими аргументы (принудительное инспользование таких методов).
Нет остроумных шуток.
Ясность предпочтительнее развлекательной ценности.
Нет просторечий и сленга.
Нет шуток.
Одно слово для каждой концепции.
Имена функций законченные и логичные.
Нет эквивалентных методов с именами fetch, retrieve, get в разных классах.
Нет controller, manager, driver в одной кодовой базе.
Имена различны принципиально.
Единый согласованный лексикон.
Не используется одно слово в двух смыслах.
Две разные идеи не обозначены одним термином.
Нет каламбура.
Мысли в коде выражаются доступно.
Используются имена из пространства решения: термины из области информатики, названия алгоритмов, паттернов, математические термины, технические имена.
Используются имена из пространства задачи (клиентские): если нет подходящего программиста, узнаются у специалиста в предметной области.
Разделение концепций из пространств задачи и решения.
Несодержательные сами по себе имена помещаются в определенный контекст для читателя кода – классы, функции и пространства имен с правильно выбранными названиями.
В крайнем случае контекст уточняется префиксом.
Контекст не должен вычисляться.
Функции разделяются на меньшие смысловые фрагменты.
Нет избыточности контекста.
Нет работы против собственного инструментария.
Короткие имена лучше длинных, если только их смысл понятен читателю кода.
Имена экземпляров более точные.
Развивать описательные навыки и единый культурный фон.
Не должно быть опасения возражений при переименовании.
Функции:
Первый уровень структуризации.
Длина не избыточна.
Не содержит повторяющихся фрагментов кода.
Один уровень абстракции.
Функции компактны.
Функции еще компактнее.
Функции желательно не более 20 строк.
Все функции предельно очевидны.
Блоки в командах if, else, while и так далее должны состоять из 1 строки, в которой обычно – вызов функции.
Функции не содержат вложенных структур.
Не более 1—2 отступов.
Функция должна выполнять только одну операцию. Она должна выполнять ее хорошо. И ничего другого она делать не должна.
Если функция выполняет только те действия, которые находятся на одом уровне под объявленным именем функции, то эта функция выполняет одну операцию.
Функции пишутся прежде всего для разложения более крупной концепции (иначе говоря, имени функции) на последовательность действий в следующем уровне абстракции.
Чтобы определить, что функция выполняет более 1 операции, надо попробовать извлечь из нее другую функцию, которая бы не являлась простой переформулировкой реализации.
Функцию, выполняющую только одну операцию, невозможно осмысленно разделить на секции.
Все команды функции находятся на одном уровне абстракции.
За каждой функцией должны следовать функции следующего уровня абстракции.
Switch, длинные цепочки if-else скрывать в низкоуровневом классе и не дублировать в коде (использовать полиморфизм).
Принцип единой ответственности (single responsibility principle).
Принцип открытости-закрытости (open-closed principle).
Программа не содержит неограниченного количества других функций с аналогичной структурой (можно использовать абстрактную фабрику).
Имя точно описывает, что делает функция.
Длинное имя функции лучше короткого невразумительного.
Не бойтесь расходовать время на выбор имени функции.
В именах функций использовать те же словосочетания, глаголы и существительные, что и в модулях.
В идеальном случае количество аргументов функции равно нулю.
Использовать функции 1 аргумента:
– для проверки некоторого условия, связанного с аргументом;
– для обработки аргумента, его преобразования и возвращения;
– для события (вход есть, выхода нет);
– должно быть предельно ясно, что перед читателем событие;
– остальных форм функций с 1 аргументом лучше избегать;
– не использовать аргументы-флаги.
Бинарные функции оправданны, если оба аргумента – упорядоченные компоненты одного значения.
Использовать все доступные способы для сведения функций к унарной форме.
Аргументы должны иметь естественную связь и естественный порядок.
Хорошо подумать перед созданием тернарной функции.
Упаковывать аргументы в объекты.
Если переменное количество равноправных аргументов – упаковать в List.
Хорошее имя функции способно объяснить смысл функции, порядок и смысл ее аргументов.
В унарных функциях функция и аргумент должны образовывать естественную пару «глагол – существительное».
Функция не делает чего-то скрытно от пользователя.
Нет побочных временных привязок функции.
Нет побочных эффектов.
Нет причин лишний раз обращаться к сигнатуре функции (нет повторных заходов).
Выходных аргументов следует избегать.
Функция может изменять состояние только владельца.
Функция либо что-то делает (команда), либо отвечает на какой-либо вопрос (запрос).
Функция либо изменяет состояние объекта, либо возвращает информацию об этом объекте.
Исключена неоднозначность имен функций.
Функции-команды не возвращают коды ошибок.
Вместо возвращения кодов ошибок используются исключения.
Тела блоков try/catch выделены в отдельные функции.
Функции выполняют 1 операцию.
Обработка ошибок – одна операция.
Нет магнитов зависимостей – классов или перечислений, импортируемых и используемых многими другими классами.
Нет дублирования алгоритмов.
Уменьшена вероятность ошибки.
Goto не используется.
Много return, break, continue допускается в компантных функциях.
В коде сначала излагаются мысли, а затем «причесываются».
Система рассматривается как история, которую нужно рассказать.
Комментарии – неизбежное зло.
Только код может правдиво сообщить, что он делает.
Свести использование комментариев к минимуму.
Комментирование – причина повысить качество кода.
Вместо юридических комментариев – ссылки на них.
Информацию лучше передавать в имени функции.
Использовать комментарии для информации о намерении.
Комментарии – в случае неудобочитаемых форм данных.
Комментарии для предупреждения о последствиях.
Комментарии TODO на будущее.
Комментарии для подчеркивания важности обстоятельства.
Не делать комментарии на скорую руку.
Комментирий не приводит к поиску расшифровки в других модулях.
Использовать аналог Javadoc.
Не комментировать бормотанием.
Не комментировать избыточно.
Комментарии точнее кода.
Комментарии точные и соответствуют коду.
Комментарий не вводит в заблуждение и не дезинформирует.
Бессмысленные или обязательные комментарии исключены.
Комментарий не повышает риск обмана и недоразумений.
Длинные журналы комментариев исключены.
Комментарии не загромождают и не усложняют код.
Комментарии-шумы исключены.
Комментарии не утверждают очевидное, не предоставляя новой информации.
Комментарии не бесполезны.
Комментарии не вызывают желания игнорировать их.
Комментарии не содержат эмоций.
Комментарии делают работу приятной и эффективной.
Комментарии не используются там, где можно использовать функцию или переменную.
Заголовки в комментариях применяются, когда приносят ощутимую пользу.
Закрывающие скобки не комментируются.
Ссылки на авторов в комментариях заменяются использованием системы контроля версий.
Нет закомментированного кода.
Нет HTML-комментариев.
Комментарии описывают код, к которому отнесены.
Комментарии не содержат дискуссий, исторических подробностей, не относящихся к делу.
Связь между комментарием и его кодом очевидна.
Цель комментария – объяснить код, который не объясняет сам себя.
Комментарий не нуждается в объяснении.
Комментарии для API общего пользования не помещаются в коде, не предназначенном для общего потребления.
Комментарий упрощает понимание алгоритма пользователем.
Код должен быть хорошо отформатирован.
Форматирование облегчает передачу информации.
Маленькие файлы понятнее больших.
Типичная длина файла 200 строк, предел – 500.
Исходный файл выглядит как статья.
Имя файла простое, но содержательное.
Имени файла достаточно, чтобы определить. этот модуль нужен или нет.
Начальные блоки файла описывают высокоуровневые концепции и алгоритмы.
Степень детализации увеличивается к концу файла.
В конце файла собираются все функции и подробности низшего уровня.
Код читается слева направо и сверху вниз.
Законченные мысли отделяются пустыми строками.
Строки кода с тесной связью должны быть сжаты по вертикали.
Тесно связанные концепции не находятся в разных файлах.
Следует избегать запущенных переменных.
Читателю не нужно прыгать туда-сюда по исходным файлам и классам.
Переменные объявляются максимально близко к месту использования.
Переменные перечисляются в начале каждой функции.
Управляющие переменные циклов объявляются внутри конструкции циrла.
Переменные экземпляров объявляются в начале класса.
Если одна функция вызывает другую, то они располагаются вблизи друг друга по вертикали.
Вызывающая функция располагается над вызываемой.
Концептуально родственные фрагменты кода располагаются близко друг к другу по вертикали.
Важные концепции излагаются сначала с минимальным количеством второстепенных деталей.
Строки делать по возможности короткими.
Пробелы для визуального обозначения приоритета операторов.
Длинные списки – причина для разделения на классы.
Горизонтальное выравнивание не применяется.
Отступы выделяют области видимости.
Не применяются вырожденные области видимости.
Группа разработчиков согласует единый стиль форматирования.
Код продукта оформлен в едином стиле.
Внешний пользователь не в курсе деталей реализации.
Методы интерфейса устанавливают политику доступа к данным.
Классами предоставлены абстрактные интерфейсы, посредством которых пользователь оперирует с сущностью данных.
Пользователь не имеет представления о фактическом формате данных.
Объекты скрывают свои данные за абстракциями и предоставвляют функции, работающие с этими данными.
Структуры данных раскрывают свои данные и не имеют осмысленных функций.
Процедурный код (код, использующий структуры данных) позволяет легко добавлять новые функции без изменения существующих структур данных.
ООП-код упрощает добавление новых классов без изменения существующих функций.
Процедурный код усложняет добавление новых структур данных, так как требуется изменение всех функций.
ООП-код усложняет добавление новых функций, так как требуется изменение всех классов.
Данные необязательно представляются в виде объектов.
Закон Деметры – модуль не должен знать внутреннее устройство объектов, с которыми работает.
Метод f класса С должен ограничиваться вызовом методов следующих объектов: С; объекты, созданные f; объекты, переданные f в качестве аргумента; объекты, хранящиеся в переменной экземпляра С.
Метод не должен вызывать методы объектов, возвращаемых любыми из разрешенных функций.
Не использовать цепочки вызовов (разделять).
Не используются гибриды объектов и структур данных.
Разные уровни детализации не смешиваются.
Объекты передачи данных – Data transfer object – классы с открытыми переменными без функций используются для преобразования низкоуровневых данных, получаемых из базы, в объекты кода приложения.
Bean – компоненты из приватных переменных, операции с которыми осуществляются при помощи методов чтения и записи, преимуществ не имеют.
Активные записи – active records – структуры данных с открытыми переменными, а также с навигационными методами – это структуры данных и бизнес-логику не содержат.
Обработка ошибок не заслоняет логику программы.
Ошибки обрабатываются стильно и элегантно.
Используются исключения вместо кодов ошибок.
Начинать с написания команды try-catch-finally для кода, способного вызывать исключение.
Тип исключения сужается до реально инициируемого.
Блоки try должны напоминать транзакции.
Использовать непроверямые исключения.
С исключениями передавать содержательные сообщения об ошибках.
Из сведений об исключении должно быть понятно, с какой целью выполнялась операция.
Классы исключений определены в контексте потребностей вызывающей стороны.
Инкапсулированы вызовы сторонних API.
Для обработки особых случаев использовать паттерн особый случай.
Вместо null выдается исключение или особый случай.
Для API, возвращающего null, – делать обертки.
Не возвращать null из методов.
Не передавать null при вызове методов.
Запрещать передачу null по умолчанию.
Чистый код должен быть надежным.
Вместо приведения типа контейнера лучше использовать параметризованные контейнеры.
Ограничить передачу граничных интерфейсов по платформе (можно инкапсулировать).
Для стороннего кода писать тесты.
Сторонний код тестировать в рамках понимания его работы.
Конструкторы по умолчанию должны иметь конфигурацию.
Писать учебные тесты, граничные тесты.
Можно заранее определять интерфейсы, затем писать паттерн-адаптер к готовым.
Для граничного кода необходимо четкое разделение сторон и тесты, определяющие ожидания пользователя.
Количество обращений к границам стороннего кода сводится к минимуму.
Законы TDD:
– не пишите код продукта, пока не напишете отказной модульный тест;
– не пишите модульный тест в объеме большем, чем необходимо для отказа (невозможность компиляции является отказом);
– не пишите код продукта в объеме большем, чем необходимо для прохождения текущего отказного теста.
Тесты не уступают в качестве коду продукта.
Тесты развиваются вместе с продуктом.
Модульные тесты обеспечивают гибкость, удобство сопровождения и возможность повторного использования кода.
Без тестов любое изменение становится потенциальной ошибкой.
Некачественные тесты приводят к некачественному коду продукта.
Чистый тест характеризуется удобочитаемостью: ясностью, простотой и выразительностью.
В тестах использовать паттерн «построение – операции – проверка».
Тесты не делают ничего лишнего, в них используются только действительно необходимые типы и функции.
Использовать наборы функций и служебных программ, использующих API.
Код тестов не такой эффективный, как код продукта.
Чтобы избежать дублирования, можно воспользоваться паттерном шаблонный метод.
Не более 1 assert в функции теста.
Одна концепция в тесте (1 тест – 1 проверка).
Характеристики чистых тестов:
– тесты должны выполняться быстро;
– тесты не зависят друг от друга;
– тесты дают повторяемые результаты в любой среде.
Результатом выполнения теста должен быть логический признак (результат очевиден).
Тесты создаются своевременно непосредственно перед кодом продукта.
Класс должен начинаться со списка переменных.
Сначала перечисляются открытые статические константы.
Далее следуют приватные статические переменные.
За ними идут приватные переменные экземпляров.
Затем открытые функции.
Приватные вспомогательные функции, вызываемые открытыми функциями, непосредственно за самой открытой функцией (газетная статья).
Открытые переменные обычно не используют.
Предпочтительно объявлять переменные и вспомогательные функции приватными.
Иногда переменную или вспомогательную функцию приходится объявлять защищенной, чтобы иметь возможность обратиться к ней из класса.
Ослабление инкапсуляции должно быть последней мерой.
Классы должны быть максимально компактными.
Компактность класса определяется его ответственностью.
По имени класса можно определить его размер.
Краткое описание класса должно укладываться в 25 слов, без выражений «если», «и», «или», «но».
Принцип единой ответственности: SRP – класс или модуль должен иметь одну и только одну причину для изменения (одну ответственность).
Система должна состоять из множества мелких классов со сформированной структурой.
Класс взаимодействует с другими классами для реализации желаемого поведения системы.
Классы должны иметь небольшое количество переменных экземпляров.
Чем с большим числом переменных работает метод, тем выше связность этого метода со своим классом. Создавать классы с высокой связностью не рекомендуется.
Высокая связность означает, что методы и переменные класса взаимозависимы.
Рост числа переменных экземпляров свидетельствует о необходимости выделения класса.
Рефакторинг может удлинить программу.
Приватные методы, действие которых распространяется на небольшое подмножество класса, – признак возможности усовершенствований.
Структурирование проводится с учетом изменений.
Время, необходимое для понимания класса, падает почти до нуля.
Вероятность того, что одна из функций нарушит работу другой, ничтожно мала.
Принцип открытости-закрытости: классы должны быть открыты для расширений, но закрыты для модификации.
Структура системы должна быть такой, чтобы обновление системы создавало как можно меньше проблем.
В идеале новая функциональность должна реализовываться расширением системы, а не внесением изменений в существующий код.
С помощью интерфейсов и абстрактных классов класс изолируется от конкретных подробностей.
Принцип обращения зависимостей: классы системы должны зависеть от абстракций, а не от конкретных подробностей.
В программных системах фаза инициализации, в которой конструируются объекты приложения и «склеиваются» основные зависимости, должна отделяться от логики времени выполнения, получающей управление после ее завершения.
Инициализация – область ответственности.
Код инициализации пишется системно и отделен от логики времени выполнения.
Удобные идиомы не ведут к нарушению модульности.
Приложение ничего не знает о main или о процессе конструирования.
Все аспекты конструирования помещаются в main или в модули, вызываемые из main.
Если момент создания объекта должен определяться приложением, то использовать паттерн «Фабрика».
Вся информация о конструировании хранится на стороне main.
Приложение изолировано от подробностей построения.
Использовать внедрение зависимостей Dependency Injection или обращение контроля Inversion of Control для отделения конструирования от использования.
Итеративная разработка – сегодня реализуем текущие потребности, а завтра перерабатываем и расширяем систему для реализации новых потребностей.
Архитектура программных систем может развиваться последовательно, если обеспечить правильное разделение ответственности.
Компонент-сущность (entity bean) – представление реляционных данных в памяти.
Применять АОП – модульные конструкции, называемые аспектами, определяют, в каких точках системы поведение должно меняться некоторым последовательным образом в соответствии с потребностями определенной области ответственности (изменения вносит инфраструктура без необходимости вмешательства в целевой код).
Посредники (proxies) хорошо подходят для простых ситуаций – вызова методов отдельных объектов или классов.
Использовать POJO-объекты.
DAO – Data accessor object – объект доступа к данным.
Использовать aspectJ.
Не полагаться на BDUF.
На каждом уровне абстракции архитектура должна оставаться простой и обладать минимальными привязками.
Хороший API должен исчезать из вида большую часть времени.
Один человек не может принять все необходимые решения.
Принятие решений лучше всего откладывать до последнего момента.
Стандарты применяются разумно, когда они приносят очевидную пользу.
Главная задача – реализовать интересы клиента.
Использовать DSL (их код читается как структурированная форма текста, написанного экспертом в данной предметной области).
Используйте самое простое решение из всех возможных.
Четыре правила простой архитектуры:
– архитектура обеспечивает прохождение всех тестов;
– не содержит дублирующегося кода;
– выражает намерения программиста;
– использует минимальное количество классов и методов.
Система должна делать то, что задумано ее проектировщиком.
Существует простой способ убедиться в том, что система действительно решает свои задачи.
Система, тщательно протестированная и прошедшая все тесты, контролируема.
Обеспечение полной контролируемости системы повышает качество проектирования.
Для системы необходимо написать тесты и постоянно выполнять их.
Рефакторинг – последовательная переработка кода.
Рефакторинг проводится при наличии полного набора тестов.
В системе не дублируется реализация.
Применять повторное использованием даже в мелочах.
Дублирование – главный враг системы.
Код системы возможно понять без глубокого понимания решаемой проблемы.
Постараться сделать код выразительным.
Неравнодушие – драгоценный ресурс.
Использовать прагматичный подход взамен бессмысленного догматизма.
Применять нагрузочное тестирование.
Многопоточность – стратегия устранения привязок.
Многопоточность – аналогия работы нескольких компьютеров.
Многопоточность повышает быстродействие не всегда.
Многопоточность может изменить архитектуру.
При многопоточности нужно предусмотреть проблемы многопоточной взаимной блокировки, одновременное обновление.
Многопоточность требует больше производительности и кода.
Правильная реализация многопоточности сложна.
Ошибки в многопоточности обычно не воспроизводятся.
Многопоточность обычно требует фундаментальных изменений в стратегии проектирования.
Предусмотреть перебивание потоками друг друга (требуется знание обработки байт-кода и атомарных операций модели памяти).
Многопоточные архитектуры должны отделяться от основного кода.
Код реализации многопоточности имеет собственный цикл разработки, модификации и настройки.
При написании кода многопоточности возникают специфические сложности.
Предусмотреть обработку обращений к общему объекту.
Инкапсулировать данные: жестко ограничить доступ и область видимости общих данных.
Вместо использования общего объекта каждому потоку можно предоставить копию.
Использовать синхронизацию.
Потоки должны быть как можно более независимы.
Постараться разбить данные на независимые подмножества, с которыми могут работать независимые потоки (возможно, на разных процессорах).
Использовать потоково-безопасные коллекции.
Использовать неблокирующие решения.
Изучать доступные классы на предмет потоково-безопасности.
Модели логического разбиения поведения программы при многопоточности:
– производители-потребители: потоки-производители создают задания и помещают в буфер или очередь. Потоки-потребители извлекают задания из очереди и выполняют их. Производители перед записью дожидаются появления свободного места в очереди, а потребители дожидаются появления заданий в очереди. Производитель записывает задание и сигнализирует о том, что очередь непуста. Потребитель читает задание и сигнализирует о том, что очередь не заполнена. Обе стороны готовы ждать оповещения о возможности продолжения работы;
– модель читатели-писатели: писатели пишут в общий ресурс, который считывают читатели. Писатель может блокировать читателей. Нужно найти баланс между потребностями читателей и писателей, чтобы обеспечить правильный режим работы, нормальную производительность и избежать зависания;
– модель обедающих философов: за круглым столом сидят философы-потоки и думают, в центре – тарелка еды. Каждому философу для еды доступно 2 вилки-ресурсы – по 1 от соседей. Когда философ проголодается – берет вилки, поел – кладет обратно. Сложности проектирования – взаимные блокировки, обратные блокировки, падение производительности и эффективность работы.
Изучать базовые алгоритмы, разбираться в решениях.
Избегать использования нескольких методов одного совместно используемого объекта.
Избегать зависимостей между синхронизированными методами.
Или использовать 3 стандартных решения:
– блокировка на стороне клиента;
– блокировка на стороне сервера;
– адаптирующий сервер.
Код не должен перегружаться лишними синхронизированными объектами, так как блокировки создают задержки и увеличивают затраты ресурсов.
Синхронизированные секции должны иметь минимальные размеры.
Корректное завершение не может быть бесконечным ожиданием потока.
Реализовать логическую изоляцию конфигураций многопоточного кода.
Протестировать программу с количеством потоков, превышающим число процессоров.
Применять инструментовку кода для повышения вероятности сбоев.
Сначала отлаживать основной код.
Не игнорировать системные ошибки, считая их случайными разовыми сбоями.
Убедиться, что сам код работает вне многопоточного контекста, созданием POJO-объектов, вызываемых из потоков.
Реализовать многопоточный код так, чтобы он мог выполняться в различных конфигурациях: с разным числом потоков, тестовых заменителей, времени работы тестов, количеством повторов тестов.
Найти средства измерения производительсноти системы в разных конфигурациях.
Реализовать систему так, чтобы количество программных потоков могло легко изменяться, в том числе во время работы системы, в том числе с автоматическим регулированием количества потоков.
JVM не гарантирует вытесняющей многопоточности.
Протестировать систему во всех средах, которые могут использоваться для ее развертывания, начиная с ранней стадии.
Заставить поток исполняться по разным путям в тесте методами object. wait (), object.sleep (), object. yield (), object.priority () – инструментовка кода.
Автоматическая инструментовка с использованием Aspect-Oriented Framework, CGLIB, ASM, ConTest.
Суть тестирования – сломать предсказуемость пути выполнения.
Использовать стратегию случайного выбора пути выполнения для выявления ошибок.
Типичные источники многопоточных ошибок: работа с общими данными из нескольких потоков, использование пула общих ресурсов.
Использовать длительное тестирование многопоточного кода перед включением в систему.
Программирование ближе к ремеслу, чем к науке.
Спасать положение нужно именно сейчас.
Во время переработки кода не добавлять в программу новые возможности.
Предусмотреть, в каких местах будет появляться новый код.
Множество разных типов со сходными методами – причина выделить класс.
TDD: не вносить в систему изменения, нарушающие работоспособность системы.
Добавление теста или класса ничего не нарушит.
Удалять бесполезные функциии.
Тесты всегда должны хотя бы запускаться.
Прочитать последовательное очищение.
Переработка кода напоминает кубик Рубика.
Важный аспект хорошей архитектуры – логическое разбиение кода.
Плохой код тянет группу ко дну.
Открытый код требует смелости и доброй воли.
Полезные высказывания из книги «Отладка приложений для Microsoft. Net» Джона Роббинса
В разделе приведены цитаты из [4].
Большинство команд тратит в среднем 50% цикла разработки на отладку.
Отладка требует специального обучения.
Для того чтобы эффективно отлаживать любую технологию, нужно знать намного больше, чем может дать книга, сфокусированная на конкретной технологии.
Книги по программированию бывают посвящены менеджменту и технологиям.
Основные программы отладки. NET: VisualStudio и WinDBG.
Разработчики должны использовать только учетные записи, обладающие привилегиями пользователя.
[email protected] – автор.
Ошибки помогают понять работу вещей.
Ошибки в ПО могут привести к смене работы.
Ошибка – все что угодно, что заставляет пользователя страдать.
Категории ошибок: аварии и зависания, низкая производительность и масштабируемость, неверные результаты, нарушения безопасности, противоречивые пользовательские интерфейсы, неудовлетворенные ожидания.
Нельзя выпускать на рынок продукт с авариями и зависаниями.
Windows Error Reporting.
Пользователи иногда перестают пользоваться продуктом из-за одного неудачного опыта.
С точки зрения управления проектами главное – уделить внимание производительности.
Должны быть заданы конкретные цифры, связанные с производительностью.
Не делать продукт более медленным, чем его предыдущая версия.
Тестировать приложения по сценариям, наиболее точно отражающим реальный мир.
Наборы данных из реального мира брать у клиентов.
Реальные данные должны быть модифицированы – удалена конфиденциальная информация.
Писать код проверки результатов.
Выставлять требования к производительности, масштабируемости, безопасности.
Проводить тестирование безопасности и моделирование угроз.
Интерфейс приложения не должен противоречить интерфейсу среды.
Приложение не противоречит сочетаниям клавиш среды запуска.
«Designing web usability: the practice of simplicity» Якоб Нильсен.
«Don’t make me think! A common sense approach to web usability» Стивен Круг.
cnn.com – лучший пример дизайна.
joelonsoftware.com/articles.
Все члены команды должны посещать клиентов и наблюдать за использованием ПО.
Никогда не обещать того, чего не сможете дать, и всегда реализовывать обещанное.
Категории причин появления ошибок: слишком короткие или нереальные сроки выполнения; подход «сначала код, потом подумаем»; неправильное понимание требований; невежество разработчиков или недостаточное качество обучения; наплевательское отношение к работе.
Учитывать время на обучение, необходимое для того, чтобы реализовать какую-либо функцию.
Команда разработчиков должна быть истинным хозяином своего расписания, определять реалистичные даты выпуска за счет сокращения числа функций.
Перед написанием кода хорошенько подумать об архитектуре.
Продумать все «что, если».
Определить все риски проекта.
Члены команды не должны отдавать контроль над конструированием системы не умеющим это делать людям.
Не начинать сразу кодировать при получении плана.
Должна быть реалистичная оценка технологии и план разработки еще до включения компьютера.
Исключить добавление новых функций в планировании, которые изначально не планировались.
Чем больше деталей будет обнаружено в ПО и продумано до начала кодирования, тем меньше будет ошибок.
Нарисовать пользовательский интерфейс и полностью проработать каждый сценарий использования.
Коридорное тестирование.
Инженеры должны проявлять желание изучать предметную область.
Лучшие инженеры – это не те, кто умеет жонглировать битами, а те, кто качественно решает проблему пользователя.
Разработчики должны знать достаточно хорошо операционную систему, язык, технологию, которые используются в проектах.
Эффективно использовать выделяемые на обучение средства, проанализировав сильные и слабые стороны команды.
Лучший способ узнать что-то о технологии – сделать что-либо с применением этой технологии.
Все, о чем в действительности заботится ваш менеджер, – это возможность ежедневно сообщать своему боссу, чем вы занимаетесь день за днем.
Настоящие инженеры проникнуты глубокой гордостью за то, что они производят, и хотят тратить время и усилия на всех этапах разработки.
Компании и люди с реальной приверженностью качеству демонстрируют множество общих черт: тщательное предварительное планирование, личную ответственность, жесткий контроль качества и отличные коммуникационные навыки.
Только те, кто уделяет внимание деталям, выпускают продукты вовремя и с отличным качеством.
Проводить ревизии эффективности работы ежемесячно.
Регистрировать число ошибок в продукте ежемесячно (общее число обнаруженных за месяц).
«Software reliability: measurement, prediction, application» Джон Мьюз.
В среднем коде содержится одна ошибка на каждые 10 строк.
«Code complete» МакКоннелл.
По мере того как продукт создается, цена исправления ошибки растет экспоненциально, как и цена отладки.
Ускорять отладку и тестирование на этапе планирования.
Хороший отладчик = хороший разработчик.
Самая важная черта отладчика – интуиция.
Чтобы превратиться в отличного отладчика, необходимо быть специалистом в следующих областях: ваш проект, ваш язык, ваша технология/инструменты, ваша операционная система/среда.
Должна быть хорошая документация или объяснение на 15 мин от разработчиков, чтобы лучше узнать проект.
Нужно знать, что используемый язык делает за сценой.
Необходимо четко представлять себе, где можно найти более подробную информацию на случай, если она понадобится.
Писать утилиты.
Показывать свой код интервьюерам – сразу попадаем в первые 20%.
Изучение кода других инженеров и добавление новых функций – хорошая практика.
Читать код framework.
Друзья и коллеги-инженеры – лучшие источники знаний о разработке и отладке.
Подход к отладке:
Воспроизведите ошибку.
Опишите ошибку.
Всегда предполагайте, что это ваша ошибка.
Разделяйте и властвуйте.
Думайте творчески.
Используйте инструменты.
Начните тяжелую отладку.
Убедитесь, что ошибка исправлена.
Извлеките урок и поделитесь им с другими.
Полезные высказывания из книги «Надежный код» Бруно
В разделе приведены цитаты из [5].
Более высокий уровень абстрагирования позволяет больше времени уделять важным элементам любого проекта.
Нет единого мнения по вопросу, что именно должны знать и уметь все разработчики.
Разработка ПО – это не инженерия.
Настройка производительности и безопасности не должна откладываться на конец проекта.
После прочтения советов необходимо выработать привычку их применения.
На практике методология водопада работает не очень хорошо, поскольку многие важные особенности программы проявляются лишь на этапе реализации.
Нереалистично тестировать ПО в конце цикла разработки.
agilealliance.org.
agilemanifesto.org/principles.html.
Сейчас используются Scrum (наиболее широко применяется в Microsoft), XP, TDD.
blogs.msdn.com/e7.
Шаги разработки:
– сбор сведений от заказчика, совместное обсуждение требований, детальное тестирование, описание параметров компонентов и общей архитектуры системы;
– процедуры контроля качества кода – стандарты, совместная разработка, оптимизация, модульное тестирование;
– обширное тестирование системы и сборки.
Методы контроля качества применять как можно раньше.
Чем больше кода написано, тем сложнее его тестировать.
Стремиться и сосредоточиться на качестве, надежности, безопасности.
Применять итеративную разработку с итерациями не более 6—8 недель, полностью завершать один компонент перед началом работы, разделять работы на несколько автономных групп, достаточно часто обмениваться информацией о состоянии проекта.
Использовать типичные методологии развертывания, оборудования и инструментов, планировать процессы, стремясь к предсказуемости и повторяемости процедур.
Для ускорения процессов создания и развертывания, упрощения обмена информацией использовать в командах общие инструменты и процедуры для управления исходным кодом, сборки, ведения баз данных, общие подходы к программированию и единую терминологию.
Отказаться от модели водопада.
Создавать проверяемые модули.
Ежедневно запускать сборку и запускать автоматические BVT-тесты.
Использовать продукты компании в ее работе, начиная с самых ранних стадий их разработки.
Идентифицировать участников приложения (типы) и способы их взаимодействия друг с другом (прототипирование; концепции, взаимоотношения и взаимодействия проверяются на полноту и корректность; здесь же анализируются риски дизайн).
В приложениях на управляемом коде в качестве языка метапрограммирования, позволяющего изменять поведение приложения во время выполнения, применять XML.
Производительность с самого начала часть любого проекта.
Факторы масштабирования – часть дизайна приложения.
Безопасность закладывается в дизайне приложения.
Тестеры гарантируют полное покрытие кода тестами.
Учиться эффективно управлять памятью.
Использовать безопасное программирование.
Сердцем программирования являются этапы анализа требований и проектирования.
Цикл разработки ПО:
– анализ требований;
– проектирование;
– спецификации;
– программирование;
– тестирование;
– развертывание;
– обслуживание.
Написанию кода обязательно должен предшествовать этап проектирования.
Дизайн приложения в идеале не зависит от особенностей реализации.
В ООП 40—50% времени разработчик тратит на проектирование кода.
Число написанных строк кода – неверный показатель труда.
Секрет успеха заключается в неизменности цели.
На устранение проблемы на этапе тестирования требуется в 4 раза больше времени, чем на этапе проектирования.
C# – прямой потомок C++.
Существительные из предметной области могут стать объектами, глаголы и глагольные группы – поведением.
Проектирование должно управлять реализацией, но не наоборот.
Из списка объектов предметной области удаляются не взаимодействующие с другими.
Использовать UML для моделирования в проектировании.
Типы UML-схем см. в книге.
Изоляция классов друг от друга – один из принципов ООП.
В конструкторе классов VS изменения в схеме классов немедленно отражаются в коде и наоборот.
Один из способов повысить гибкость кода – писать его как можно меньше.
Метаданные хранить в xml-файлах конфигурации в корневом каталоге приложения (не использовать ini и реестр).
Использование метаданных позволяет разработчику отделить конкретные логические детали от исходного кода.
Настройки, применимые ко всем приложениям на данном компьютере, хранятся в machine.config.
Храните в метаданных настройки приложения.
Храните в метаданных данные приложения.
Управляйте поведением приложения при помощи метаданных.
Все компоненты должны при возможности управляться конфигурацией.
Изменение файлов конфигурации не требует регрессионного тестирования.
Использовать сжатие данных, передаваемых по сети.
Не использовать множество маленьких статических избражений.
Стандарт HTTP/1.1 предполагает одновременную загрузку браузером только двух ресурсов с одного имени хоста (новые браузеры игнорируют это требование).