Джоэл о программировании. Часть 3

Последняя пачка цитат из книги Джоэла Спольски “Джоэл о программировании”.

Пренебрежительное отношение к работникам, обладающим высочайшей квалификацией, не редкий случай. Почти во всех компаниях есть какая-нибудь оскорбительная и унизительная программа стимулов.
Глава 21. Поощрительные выплаты - это зло

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

...не менее двух десятков исследований, проведенных за последние тридцать лет, убедительно показали, что те, кто рассчитывает получить вознаграждение за выполнение задания или успешную работу над ним, работают просто хуже тех, кто не рассчитывает получить никакой награды.
Глава 21. Поощрительные выплаты - это зло

Пятая причина (неуважительная), по которой у вас нет тестеров.
Я не могу себе этого позволить!
Эта отговорка самая глупая, и ее легче всего развенчать.
Как бы ни трудно было найти тестеров, они все же дешевле, чем программисты. Гораздо дешевле. А если вы не наймете тестеров, вам придется заставить программистов заниматься тестированием. А если вам не нравится, что тестеры часто меняются, посмотрим, как вам понравится, если придется искать замену классному программисту, получающему 100 000 в год, которому надоело ваше требование "потратить несколько недель на тестирование перед выпуском нашего продукта" и который перешел в другую, более профессиональную компанию. Вы могли бы нанять трех тестеров на год за гонорар агента по найму, который найдет вам программиста на замену.
Скупость на тестеров оказывается такой ложной экономией, что я просто поражаюсь, сколь многие люди этого не понимают.

Мы программисты. Все программисты в глубине души - архитекторы, а первое, что хочет сделать архитектор, прибыв на строительный участок, - это выровнять его бульдозером и построить нечто грандиозное. Нас не воодушевляют частичная реконструкция: копаться, улучшать, разбирать цветочные клумбы.
Есть скрытая причина, по которой программисты всегда хотят выкинуть старый код и начать все сначала. Это происходит потому, что прежний код кажется им запутанным. Я так думаю, что они, вероятно, ошибаются. Старый код кажется запутанным, потому что есть важный фундаментальный закон программирования.
Читать код труднее, чем писать его.
Глава 24. То, чего делать нельзя, часть первая

Все счастливые условия работы похожи друг на друга (закрытые офисы, тихая обстановка, отличные инструменты, редкие отвлечения и даже редкие большие совещания). Каждая несчастная рабочая обстановка несчастна по-своему.
Глава 31. Стратегия 5: избавьтесь от отвлечений

Берегись методологий. Они прекрасно обеспечивают жалкое, но терпимое качество труда каждого, но они раздражают людей талантливых, укладывая их в прокрустово ложе ограничений. Талантливый повар, конечно, не будет счастлив, испекая бургеры в Макдональдсе, именно из-за инструкций, насаждаемых Макдональдсом. Почему же ИТ-консультанты так хвалятся своими методологиями? (Не могу понять.)
Глава 33. Биг-Маки против "Голодного повара"

Если вы хотя бы 20 минут в своей жизни писали код, то, вероятно, открыли для себя хорошее эмпирическое правило: все не так просто, как может показаться.
Глава 34. Все не так просто, как может показаться

Синдром "это изобретено не здесь" считается классической патологией менеджмента и состоит в том, что команда отказывается пользоваться технологией, которую создала не она сама. Очевидно, что люди с таким синдромом просто мелочны, не хотят делать того, что выгодно всей организации, потому что им это не принесет никакой славы. (Верно?)
Глава 35. В защиту синдрома "это придумали не здесь"

Когда ваша компания растет быстрее, чем на 100 процентов в год, просто невозможно, чтобы наставники передавали новичкам корпоративную культуру. Если программист перемещен на должность руководителя и получил вдруг пятерых новых подчиненных, набранных за день до этого, просто невозможно осуществлять такое наставничество.
Глава 36. Первое письмо о стратегии: Ben & Jerry's против Amazon

Идея рекламы состоит в том, чтобы врать и не быть пойманным.
Глава 37. Второе письмо о стратегии: что сначала - курица или яйцо.

 

Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:

Часть 1

Часть 2

Справочник бойца по проведению собеседования

Секреты айсберга

Часть 3

Джоэл о программировании. Секреты айсберга

Заказчики не знают, чего они хотят.
Не надейтесь, что заказчики будут знать, чего они хотят.
Этого никогда не будет. Забудьте об этом.
Лучше исходить из того, что вам все равно придется что-то написать, и это что-то должно понравиться заказчику, но он будет несколько удивлен. Вы должны провести исследование. Вы должны придумать, как решить проблемы заказчика удобным для него образом.
Глава 25. Секрет айсберга

Вы знаете, что айсберг на 90% скрыт под водой? Так вот, программное обеспечение обычно на него похоже: в нем есть милый интерфейс пользователя, который требует процентов 10%, а 90% программистского труда скрыто от глаз. А если принять во внимание, что примерно половина времени уходит на отладку, то интерфейс требует лишь около 5% всех трудовых затрат. А если ограничить себя только видимой часть интерфейса, пикселами, тем, что вы увидите в PowerPoint, то речь пойдет вообще об 1% и менее.
Но секрет не в этом. Секрет в том, что люди, не являющиеся программистами, этого не понимают.
Глава 25. Секрет айсберга

Если вы покажете непрограммисту экран с интерфейсом, который будет выглядеть на 90% хуже, он решит, что программа на 90% хуже.
Глава 25. Важное следствие номер один

Если показать непрограммисту экран с интерфейсом пользователя, который на вид готов и красиво выглядит, то он решит, что программа почти готова.
Глава 25. Важное следствие номер два

Интернет-компания, у которой есть феерический веб-сайт, состоящий из четырех или около того страниц, ценится дороже, чем компания с очень функциональным веб-сайтом, предоставляющим архивы за последние 3700 лет, но со стандартным серым фоном.
Глава 25. Важное следствие номер три

Если вам нужно произвести впечатление ожидаемыми результатами, то единственное, что имеет значение для успеха, это снимки экранов. Они должны быть как можно красивее.
Глава 25. Важное следствие номер пять

 

Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:

Часть 1

Часть 2

Справочник бойца по проведению собеседования

Секреты айсберга

Часть 3

Скотт Мейерс. Эффективное использование С++

 На этот раз речь пойдет о замечательной книге Скотта Мейерса “Эффективное использование С++”. И хотя возможно эта книга (и цитаты из нее, соответственно) будут более интересны разработчикам, которые в своей профессиональной деятельности занимаются языком программирования С++, многие идеи положенные в основу некоторых правил будут актуальны и для разработчиков из других областей.

Мое развернутое мнение, в виде рецензии, можно почитать на моем блоге, а также на сайте rsdn.ru.

Независимо от вида ресурсов, важно, чтобы по окончании использования они были освобождены.
Попытки обеспечить это "вручную" представляет сложность при любых условиях, но если принять во внимание исключения, функции со многими путями возврата и приложения, модифицируемое программистами без отчетливого понимания последствий вносимых изменений, то становится ясно, что придумывать в каждом случае особый способ управления ресурсами нежелательно.
Глава 3. Управление ресурсами

Любой интерфейс, который требует, чтобы пользователь что-то помнил, может быть использован неправильно, ибо пользователь вполне способен забыть, что от него требуется.
Правило 18. Проектируйте интерфейсы так, что их легко было использовать правильно и трудно – неправильно

Женщина либо беременна, либо нет. Невозможно быть чуть-чуть беременной. Аналогично программная система является либо безопасной по исключениям, либо нет. Нет такого понятия, как частично безопасная система. Если система имеет всего одну небезопасную относительно исключений функцию, то она небезопасна и в целом, потому что вызов этой функции может привести к утечке ресурсов и повреждению структур данных. К несчастью, большинство унаследованного кода на С++ было написано без учета требований безопасности исключений, поэтому многие системы на сегодня являются в этом отношении небезопасными. Они включают код, написанный в небезопасной манере.
Правило 29. Стремитесь, чтобы программа была безопасна относительно исключений

Сорок лет назад код, изобилующий операторами goto, считался вполне приемлемым. Теперь же мы стараемся писать структурированные программы. Двадцать лет назад глобальные данные ни у кого не вызывали возражений. Теперь мы стремимся данные инкапсулировать. Десять лет назад написание функций без учета влияния исключений было нормой. А сейчас мы боремся за достижение безопасности относительно исключений.
Времена меняются. Мы живем. Мы учимся.
Правило 29. Стремитесь, чтобы программа была безопасна относительно исключений

Не забывайте об эмпирическом правиле "80-20", которое утверждает, что типичная программа тратит 80% времени на исполнение 20% кода. Это важное правило, поскольку оно напоминает, что цель разработчика программного обеспечения - идентифицировать те 20% кода, которые действительно способны повысить производительность программы. Можно до бесконечности оптимизировать и объявлять функции inline, но все это будет пустой тратой времени, если только вы не сосредоточите усилия на нужных функциях.
Правило 30. Тщательно обдумывайте использование встроенных функций

Делая класс D закрытым наследником класса B, вы поступаете так потому, что заинтересованы в использовании некоторого кода, уже написанного для B, а не потому, что между объектами B и D существует некая концептуальная взаимосвязь. Таким образом, закрытое наследование - это исключительно прием реализации. Можно сказать, что закрытое наследование означает наследование одной только реализации, без интерфейса. Если D закрыто наследует B, это означает, что объекты D реализованы посредством объектов B, и ничего больше. Закрытое наследование ничего не означает в ходе проектирования программного обеспечения и обретает смысл только на этапе реализации.
Правило 39. Продумывайте подход к использованию закрытого наследования

P.S. Спасибо Алексею Ершову за идею цитат из этой замечательной книги, и за отличную цитату об эволюции в области разработки ПО (вторая цитат из правила 29).

Джоэл о программировании. Справочник бойца по проведению собеседования

Сегодня я опять возвращаюсь к замечательной книге Джоэла Спольски “Джоэл о программировании”.

На этот раз здесь будут цитаты всего лишь из одной главы, главы 20 “Справочник бойца по проведению собеседования”. Мне кажется (хотя, нужно признать, что не только мне), что это одна из самых интересных и полезных глав из этой книги, в которой (спасибо, кэп) автор раскрывает проблемы проведения собеседований. Хотя эта тема достаточно избита, Джоэл умеет красиво (и главное с пользой дела) рассказать даже о таких, казалось бы банальных вещах.

Все соглашаются, что люди - самая главная часть программного проекта, но никто не знает толком, как решить эту проблему. Первое, что надо правильно сделать, если вы хотите, чтобы у вас были хорошие программисты, - это нанять правильных программистов. А это значит, что вы должны уметь определить, какие программисты правильные, что обычно делается во время собеседования.

Всегда старайтесь, чтобы каждого кандидата на работу интервьюировало не меньше шести человек, причем не менее пяти из них должны иметь одинаковый с ним ранг (т.е. программисты, а не менеджеры).

Гораздо, гораздо лучше отклонить хорошего кандидата, чем принять плохого. Плохой отнимет много денег и сил, а также время у других для исправления его ошибок. Увольнение нанятого по ошибке может отнять месяцы и оказаться очень сложным, если он будет склонен к сутяжничеству. Иногда просто невозможно кого-нибудь уволить. Плохие работники деморализуют хороших. При этом они могут быть плохими программистами, но прекрасными людьми, или им очень нужна эта работа, поэтому вам тяжело уволить их или их увольнение вызовет всеобщее неудовольствие, а могут быть и еще причины. Очень тяжелая ситуация.

Как же определить, что этого человека надо принять?
В принципе просто. Искать надо тех, кто:
1. Умен
2. Доводит дело до конца

На что нужно обращать внимание, задавая открытые вопросы?
Первое: Ищите увлеченность. Умный человек увлекается проектом, над которым работает. Он очень возбуждается, рассказывая о предмете... Плохие кандидаты просто равнодушны и не проявляют никакого энтузиазма во время интервью.
Второе: хорошие кандидаты стараются понятно излагать вещи на любом уровне. Я отказываю некоторым кандидатам, потому что, рассказывая о своем недавнем проекте, они были не в состоянии описать его языком, понятным нормальному человеку... Вам не стоит брать их на работу, потому что у них не хватает ума, чтобы понять, как сделать свои мысли понятными другим.
Третье: Если проект был групповым, посмотрите, есть ли у кандидата качества руководителя. Помните, умен и доводит дело до конца. Узнать о ком-либо, что он доводит дело до конца, можно, только проследив, была ли у него в прошлом тенденция доводить дело до конца.

 

Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:

Часть 1

Часть 2

Справочник бойца по проведению собеседования

Секреты айсберга

Часть 3

Объектно-ориентированный анализ и проектирование. Часть 3. Объектная модель. Основные определения.

При использовании той или иной методологии очень важно разговаривать с собеседниками на одном языке. Для этого нужно одинаково понимать термины, на основе которых строится общение или выражение собственной точки зрения.

В мире объектно-ориентированного анализа и проектирования также есть своя терминология и ключевые определения. Что такое ООП, что такое абстракция, что такое инкапсуляция и т.д. Всего определений огромное количество, поэтому в этом сообщении я ограничусь лишь основными, взятыми из главы 2. “Объектная модель” замечательной книги Гради Буча “Объектно-ориентированный анализ и проектирование с примерами приложений”.

Объектно-ориентированное программирование - это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образую иерархию наследования

Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.

Объектно-ориентированный анализ - это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.

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

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

Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

Иерархия - это упорядочение абстракций, расположение их по уровням.

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм (concurrency) - это свойство, отличающее активные объекты от пассивных.

Сохраняемость (persistence) - способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.

Путь камикадзе. Часть 1

Сложно сказать что-либо новое о легендарной книге Эда Йордона “Путь камикадзе”, т.к. она уже давно стала классической в своей области. В бумажном виде у меня есть только первое издание, а оригинал вышел еще в 1997 году (хотя автор вовсю уже работает над третьим, подробности можно почитать здесь). Но если немного перефразировать Фредерика Брукса (правда он говорил это по отношению к другой легендарной книге в области управления проектами - “Peopleware”): этой книге уготована долгая жизнь по той же причине, почему рассказы Гомера пережили тысячи лет: эти рассказы о людях, и они также верны сегодня, как и тысячу лет назад.

В существовании безнадежных проектов виновато высшее руководство, а также наивность и безрассудство пользователей.
Предисловие

Неразумное поведение корпораций заключается в том, что они делают одно и то же снова и снова, каждый раз ожидая различных результатов.
Глава 1.

Под безнадежным проектом я понимаю такой проект, параметры которого отклоняются от нормальных значений по крайней мере на 50%.
Глава 1.1 Определение безнадежного проекта

Другой способ охарактеризовать безнадежный проект заключается в следующем: беспристрастная, объективная оценка риска такого проекта (включая риск, связанный с техническими проблемами, человеческим фактором, законами, политикой и т.д.) определяет вероятность провала свыше 50%.
Глава 1.1 Определение безнадежного проекта

Наверно, слишком тягостно представить себе, что вы идиот, окружены идиотами и руководят вами идиоты. Наверно, вы рассматриваете как оскорбление даже саму возможность такого предположения.
Глава 1.3 Почему существуют безнадежные проекты?

Многие разработчики ПО клянутся, что не дадут втянуть себя в политические игры, поскольку они считают это не своим делом. Кроме того, они полагают, что все связанное с политикой, - отвратительно. Увы, уйти от политики невозможно; как только в какое-либо совместное предприятие войдут двое или более человек, тут же начнется политика.
Глава 1.3.1 Политика, политика, политика

Если вы - революционер или мученик, то можете повоевать с корпоративной культурой, но вряд ли у вас при этом хоть что-нибудь получится.
Глава 1.3.5 Менталитет "Морского Корпуса": Настоящие программисты могут работать без сна!

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

“Джоэл о программировании”. Часть 2.

Вторая порция цитат из замечательной книги Джоэла Спольски “Джоэл о программировании”.

Вы хватаете за рукав первого попавшегося вам в коридоре человека и требуете, чтобы он поработал с кодом, который вы только что написали. Проделайте это пять раз и вы найдете 95% всех проблем с юзабилити в своем коде
("Корридорное тестирование")
Глава 3. Проводится ли юзабилити-тестирование на случайных людях?

Продвижение хороших кодеров выдвижением их на другие должности, где требуется писать на человеческом языке, а не на С++, служит классической иллюстрацией принципа Питера: люди продвигаются по службе, пока не достигнут своего уровня некомпетентности.
Глава 7. Как принимать на работу менеджера программы?

Многие неопытные менеджеры полагают, что могут "стимулировать" более быструю работу своих программистов, если будут задавать для них трудные, "напряженные" (нереалистично быстрые) графики. Я думаю, что такого рода мотивация - глупость. Если я выбиваюсь из графика, я чувствую себя обреченным, подавленным и немотивированным. Если же я работаю с опережением графика, я чувствую себя бодрым и работоспособным. Психологические игры с графиком очень опасны.
Глава 9. Ни в коем случае не позволяйте программистам занижать оценку времени.

Если у вас есть кучка деревянных кубиков, которые не помещаются в коробку, есть два выхода: взять коробку побольше или убрать некоторые кубики. Если вы думали, что сможете сделать продукт через 6 месяцев, а по графику получается 12, вам придется либо отложить выпуск продукта, либо отказаться от каких-то функций. Сделать кубики меньше вы не можете, а если вы считаете, что можете, значит, вы лишаете себя полезной возможности реально смотреть в будущее и лжете себе о том, что вы там видите.
Глава 9. График похож на набор кубиков

Исправлять ошибки необходимо только тогда, когда сохранение ошибки обходится дороже, чем ее исправление
Глава 11. Тотальное уничтожение ошибок

Я заметил, что начиная с самой первой моей работы я как разработчик в среднем лишь два или три часа могу продуктивно писать код, и это меня изумляет. Когда я летом стажировался в Microsoft, то мой коллега-стажер рассказал мне, что фактически он ежедневно активно работал с 12 до 5. Пять часов, минус обед, и его бригада восхищалась им, потому что ему все удавалось сделать гораздо больше среднего. Я обнаружил, что со мной происходит то же самое. Я испытываю легкое чувство вины, замечая, как напряженно, по-видимому, работают все остальные, а у меня получается два или три часа настоящей работы в течение дня, и тем не менее я всегда был одним из самых результативных членов бригады. Видимо по этой причине "Peopleware" и экстремальное программирование настаивают на отмене сверхурочной работы и на строго 40-часовой рабочей неделе, будучи уверенными в том, что объем продукции команды от этого не уменьшится.
Глава 15. Огонь и движение

 

Все цитаты из книги Джоэла Спольски “Джоэл о программировании”:

Часть 1

Часть 2

Справочник бойца по проведению собеседования

Секреты айсберга

Часть 3