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

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