Главная
Попытка заменить пчелу
Предложения советских рационализаторов
Радиоэлектронные собеседники животных
Роботехника в производстве и в быту
Тайна профессора Рентгена
Деталь сама себя обрабатывает и охлаждает
Желтый подводный робот
Ледяные корабли
Открытия и наблюдения советских ученых
Новаторская перевозка грузов
Перпетуум мобиле с Алексеем Воробьёвым-Обуховым
Пишущая машинка стенографирует и расшифровывает
Шахматная махина маэстро кэмпелена
Роторно-винтовые ледоколы
Русскому керосину - 160 лет
Спасение в воздушных просторах
Что умеют машины
|
Главная - Литература Из уважения к теме используйте термины «предложения» и «советы» Избегайте установки жестких «правил» и «стандартов». Старайтесь обходить спорные вопросы, предпочитая давать явные поручения В выборе стиля отступов или размещения скобок поможет такая хитрость; потребуйте прогнать код через средства создания «красивой» печати, прежде чем объявлять его законченным. Пусть форматирование выполняется специальными средствами. Чтобы решить вопрос со стилем комментариев, требуйте, чтобы весь код рецензировался и неочевидный код исправлялся до тех пор, пока не станет ясным. Предложите программистам выработать собственные стандарты Как я уже говорил, детали конкретного стандарта зачастую менее важны, чем факт самого существования стандарта. Не устанавливайте стандарты вашим программистам, но настаивайте на том, чтобы они стандартизовали области, важные для вас. Какие из «религиозных» тем настолько важны, чтобы из-за них ввязываться в спор? Подчинение в небольших вопросах стиля в любой области, возможно, не принесет особой выгоды по сравнению с ухудшением моральной атмосферы в команде. Если вы встречаете беспорядочное использование операторов goto или глобальных переменных, нечитаемый стиль или другие признаки, влияющие на проект в целом, то для улучшения качества кода будьте готовы мириться с некоторыми разногласиями. Если ваши программисты добросовестны, это редко становится проблемой. Самые большие сражения обычно разворачиваются вокруг стилистических нюансов кодирования, и вы можете стоять в стороне от этого без всяких потерь для проекта. Физическая среда Проведите эксперимент: поезжайте за город, найдите ферму, отыщите фермера и спросите его, во что ему обошлось оборудование. Фермер посмотрит в амбар и увидит несколько тракторов, фургонов, зерновой комбайн, молотилку, и скажет, что сумма превышает $100 000 на работника. После этого найдите в городе фирму, занимающуюся разработкой ПО, отыщите менеджера и спросите его, каковы его затраты на оборудование. Менеджер заглянет в офис, увидит стол, стул, несколько книг и компьютер и скажет, что они не превышают $25 ООО на каждого работника. Физическая среда сильно влияет на производительность. Демарко и Листер (DeMarco and Lister) опросили 166 программистов из 35 организаций о качестве их физического окружения. Большинство работников оценило свои рабочие места как неприемлемые. После проведения соревнования по программированию оказалось, что программисты, результаты которых попадают в первые 25%, имеют более просторные, тихие и уединенные кабинеты, а также реже отвлекаются на других людей и телефонные звонки. Вот сводка различий в офисном пространстве между лучшими и худшими программистами: Фактор среды Первые 25% Последние 25% Офисная площадь 9 5 Достаточно тихое рабочее место 57% «да» 29% «да» Достаточно уединенное место 62% «да» 19% «да» Возможность выключить телефон 52% «да» 10% «да» Возможность переадресовать звонки 76% «да» 19% «да» Частые ненужные прерывания 38% «да» 7б% «да» Рабочее место, позволяющее 57% «да» 29% «да» программистам чувствовать себя оцененным по достоинству Источник: «Peopleware» (DeMarco and Lister, 1999). Эти данные показывают сильную корреляцию между производительностью и качеством рабочего места. Программисты из первых 25% были в 2,6 раза производительнее, чем программисты из последних 25%. Де- марко и Листер подумали, что более квалифицированным программистам могли быть предоставлены лучшие условия в качестве поощрения, но дальнейшая проверка показала, что это не так Программисты из одной организации имели сходные удобства независимо от разницы в их производительности. Большие организации, нацеленные на разработку ПО, подтверждают эти данные. Xerox, TRW, IBM и Bell Labs отмечают, что они получили значительный прирост в производительности, увеличив инвестиции с $10 ООО до $30 ООО на одного сотрудника. Возросшая производительность неоднократно компенсировала эти затраты (Boehm, 1987а). По собственным оценкам рост производительности в таких «производительных офисах» составил от 39 до 47% (Boehm et al., 1984). Подводя итоги, можно сказать, что если ваше рабочее место попадает в худшие 25%, вы можете увеличить свою производительность примерно на 100%, улучшив его до соответствия первым 25%. Если у вашего рабочего места средние показатели, вы все еще можете получить 40%-е увеличение производительности, улучшив его качество до первых 25%. Дополнительные ресурсы, посвященные программистам как человеческим существам Weinberg, Gerald М. Tbe Psychology of Computer Programming, 2d ed. New York, NY: Van Nostrand Reinhold, 1998. Это пер- Ь!1р: сс2.еош/2806 вая книга, которая явно определяет программистов как людей, и в ней лучше всего рассматривается программирование как человеческая деятельность. Она наполнена проницательными замечаниями о человеческой природе программистов и ее последствиях. DeMarco, Tom and Timothy Lister. Peopleware: Productive Projects and Teams, 2d ed. New York, NY: Dorset House, 1999. Как сказано в названии, эта книга также рассматривает человеческий фактор в программировании. Она содержит множество анекдотов о менеджерах, офисном окружении, найме и развитии нужных людей, увеличении команд и любви к своей работе. Авторы переусердствовали с анекдотами для поддержки некоторых необычных точек зрения, и их логика порой не- убедительна, но важен душевный настрой книги, ставящий людей на первое место, и авторам, несомненно, удалось донести свою мысль. McCue, Gerald М. «IBMs Santa Teresa Laboratory - Architectural Шр: сс20.согп/2а2О Design for Program Development», IBM Systems Journal 17, no. 1 (1978): 4-25. Маккью рассказывает о том, как в IBM создавали офисный комплекс в Сайта Тереза. IBM изучила нужды программистов и разработала здания с учетом их пожеланий. Программисты принимали участие в проекте на всем его протяжении. Результат: в ежегодных опросах мнений комплекс в Сайта Тереза оценивается в компании как лучший. McConnell, Steve. Professional Software Development. Boston, MA: Addison-Wesley 2004. В главе 7 «ОфЬап5 Preferred» подводятся итоги демографических исследований в среде программистов, включая типы личностей, образование и перспективы работы. Carnegie, Dale. How to Win Friends and Influence People, Revised Edition. New York, NY: Pocket Books, 1981. Написав заголовок для первого издания этой книги в 1936 году, Дейл Карнеги не мог подозревать, какой скрытый смысл он приобретет сегодня. Он звучит так, как будто книга взята с полки самого Макиавелли. Однако дух книги диаметрально противоположен манипуляциям в стиле Макиавелли, и один из ключевых моментов говорит о важности развития неподдельного интереса к другим людям. Карнеги глубоко проникает в ежедневные взаимоотношения и объясняет, как работать с другими людьми с помощью лучшего их понимания. Книга полна запоминающихся историй, иногда по две-три на страницу. Любой, кто работает с людьми, должен когда-нибудь прочесть ее, а тот, кто управляет людьми, должен прочесть ее немедленно. 28.6. Управление менеджером в области разработки ПО часто встречаются как нетехнические менеджеры, так и такие, кто имеет технический опыт, но отстал от жизни лет на 10. Технически компетентные, технически современные менеджеры редки. Если вы работаете с таким, делайте все, чтобы сохранить свою работу. Это необычайное везение. 8 щщщш шщМ patoHMK менеджер более типичен, вы сталкиваетесь с не-стрешйтсшоднтей Д0 сшго завидной задачей управления собственным менеджером, урош Ш01«п«т$нций. «Управление менеджером» означает, что вам нужно объяс- flpmtfm Штра нить менеджеру, что надо делать, а не наоборот. Фокус в том, (Ш РШг гШфЩ что это надо сделать так, чтобы он продолжал считать, что это он вами управляет. Вот несколько подходов к работе с вашим менеджером: посейте идеи того, что вы хотите сделать, а затем дождитесь, пока вашего менеджера посетит мысль, что вам нужно делать именно то, что вы хотите; просвещайте вашего менеджера, как делать правильно; это непрерывная работа, потому что менеджеров часто повышают, переводят или увольняют; сосредоточьтесь на интересах менеджера, делая то, что он или она действительно от вас хочет, и не отвлекайте его внимание несущественными деталями реализации (думайте об этом, как об «инкапсуляции» вашей работы); 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 [221] 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 0.0033 |