Tags: программирование

Ливанов, Холмс

Книги: октябрь

Оригинал взят у egorius в Книги: октябрь

Джеймс Уиттакер, Джейсон Арбон, Джефф Королло, «Как тестируют в Google»


О подходе Гугла к тестированию из первых рук. Для нас, неандертальцев, это, конечно, космос.


Показалось логичным, что разработчики наравне с остальными отвечают за качество и активно вовлечены в тестирование. Другие роли менее ожидаемы: «разработчик в тестировании» (полноценный разработчик, отвечающий за тестируемость продукта) и «инженер по тестированию» (анализирует риски, составляет план тестирования, смотрит на продукт со стороны пользователя).


Кусочки на память.




Когда я пожаловался своему начальнику, он сказал: «Это Google. Если ты хочешь, чтобы что-то было сделано, — сделай это».





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





Тестировщиков, по сути, предоставляют командам разработки продуктов во временное пользование. Они свободно поднимают вопросы безопасности и освещают области, где нет тестов или много багов. Так как мы не подчиняемся команде разработки продукта, нам нельзя ответить, что для нас есть дела поважнее. ... Рутинная работа вокруг фичи входит в обязанности разработчика, ее нельзя переложить на какого-нибудь тестировщика-несчастливчика.





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





Не пропускайте грамматические, орфографические и пунктуационные ошибки. Небрежность плохо скажется на будущем коде. Не создавайте почву для небрежности. [О рецензировании проектной документации]





Автоматизация тестирования — это полноценная разработка ПО со всеми вытекающими. ... Код тестов полезен настолько, насколько он ускоряет процесс разработки. Чтобы этого достичь, его нужно встраивать в процесс разработки основного продукта так, чтобы он стал его естественной частью, а не побочной деятельностью.





Чтобы быть хорошим тестировщиком, нужно быть проницательным и способным к управлению, поэтому многие топ-менеджеры Google вышли именно из тестировщиков.





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





Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимание на точное значение рисков.





Постоянно просите инженеров мыслить масштабно при любой работе!





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





Человек, написавший функцию, должен быть ответственным за выполнение тестов для нее.





Создавайте инфраструктуру, в которой писать тесты будет легко. Тесты должно быть проще написать, чем пропустить.





Примерно 20% всех сценариев использования отражают 80% самого использования. Автоматизируйте эти 20% и не беспокойтесь об остальных.





Сначала все узнать, потом заслужить репутацию и только потом — искать возможности для нововведений.





Забота о качестве — это ежедневная обязанность каждого инженера.



Ливанов, Холмс

Правда жизни.

  The Twelve Networking Truths

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This memo documents the fundamental truths of networking for the
   Internet community. This memo does not specify a standard, except in
   the sense that all standards must implicitly follow the fundamental
   truths.

Acknowledgements

   The truths described in this memo result from extensive study over an
   extended period of time by many people, some of whom did not intend
   to contribute to this work. The editor merely has collected these
   truths, and would like to thank the networking community for
   originally illuminating these truths.

1. Introduction

   This Request for Comments (RFC) provides information about the
   fundamental truths underlying all networking. These truths apply to
   networking in general, and are not limited to TCP/IP, the Internet,
   or any other subset of the networking community.

2. The Fundamental Truths

   (1)  It Has To Work.

   (2)  No matter how hard you push and no matter what the priority,
        you can't increase the speed of light.

        (2a) (corollary). No matter how hard you try, you can't make a
             baby in much less than 9 months. Trying to speed this up
             *might* make it slower, but it won't make it happen any
             quicker.

   (3)  With sufficient thrust, pigs fly just fine. However, this is
        not necessarily a good idea. It is hard to be sure where they
        are going to land, and it could be dangerous sitting under them
        as they fly overhead.

   (4)  Some things in life can never be fully appreciated nor
        understood unless experienced firsthand. Some things in
        networking can never be fully understood by someone who neither
        builds commercial networking equipment nor runs an operational
        network.

   (5)  It is always possible to aglutenate multiple separate problems
        into a single complex interdependent solution. In most cases
        this is a bad idea.

   (6)  It is easier to move a problem around (for example, by moving
        the problem to a different part of the overall network
        architecture) than it is to solve it.

        (6a) (corollary). It is always possible to add another level of
             indirection.

   (7)  It is always something

        (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't
            have all three).

   (8)  It is more complicated than you think.

   (9)  For all resources, whatever it is, you need more.

       (9a) (corollary) Every networking problem always takes longer to
            solve than it seems like it should.

   (10) One size never fits all.

   (11) Every old idea will be proposed again with a different name and
        a different presentation, regardless of whether it works.

        (11a) (corollary). See rule 6a.

   (12) In protocol design, perfection has been reached not when there
        is nothing left to add, but when there is nothing left to take
        away.

Security Considerations

   This RFC raises no security issues. However, security protocols are
   subject to the fundamental networking truths.

http://tools.ietf.org/html/rfc1925
Ливанов, Холмс

Мейер.

Why so many features?

It is easy to complain about software bloat, and examples of needlessly complex system abound. But your bloat may be my lifeline, and what I dismiss as superfluous may for you be essential. To paraphrase a comment by Ichbiah, the designer of Ada, small systems solve small problems. Outside of academic prototypes it is inevitable that  a successful software system will grow in complexity if it is to address the variety of users’ needs and circumstances. What matters is not size but consistency: maintaining a well-defined architecture that can sustain that growth without imperiling the system’s fundamental solidity and elegance.

Кладезь, просто кладезь.
Ливанов, Холмс

Программистский камень.

Прочитал таки "Программистский камень" Алана Картера. Работа довольно объемная, порядка 70 страниц формата А4. Постараюсь далее поделиться теми идеями автора, которые мне показались довольно интересными. Сразу оговорюсь, что английский не простой, так что перевод может изобиловать неточностями.

Начнем с того, что автор задается уже, наверное, риторическим вопросом -- почему одни программисты продуктивнее других. Ответ кроется в модели мышления человеков.
Большинство из нас являются так называемыми паковщиками -- людьми, которые ориентированы на получение пакетов знаний из окружающего мира. Данная модель мышления основана на действии, и в программировании адепты данного мышления не очень-то и преуспели. Противостоят паковщикам в нашем мире картостроители. Картосторители оперируют ментальными картами и, в отличие от паковщиков, ориентированы на достижение понимания. Как следствие, на ниве разработки ПО данные ребята более производительны и созидательны.

Collapse )