«Проблема с программным обеспечением»
Мне всегда было интересно найти новые ценные книги по разработке программного обеспечения, и в своей статье 5 лучших современных книг по разработке программного обеспечения я составил список моих текущих фаворитов. Проблема с программным обеспечением: почему умные инженеры пишут плохой код Адама Барра (2018) - если бы я читал его раньше - вероятно, попал бы в этот список. Вот обзор и рассказы из моего личного опыта, относящиеся к некоторым из содержания книги.
Коренные причины
Барр в основном представляет долгую историю компьютерных наук и технологий и критически обсуждает тот факт, что нет единого мнения о стандартах и разумных подходах к SE. Он утверждает:
В отличие от других инженерных дисциплин, наличие степени в области разработки программного обеспечения не гарантирует, что вы разбираетесь в известном корпусе инструментов и методов программирования, потому что таких вещей не существует.
В книге не так много конкретных советов, как «Если вы структурируете свои методы подобным образом, вы улучшите дизайн своего программного обеспечения и напишете меньше плохого кода». Вместо этого автор сосредотачивается на некоторых коренных причинах и объясняет, почему состояние отрасли такое, как оно есть сегодня. (Спойлер: среди прочего, оператор GOTO и язык программирования C несут ответственность за множество плохих вещей, происходящих в программном обеспечении.)
Первая пара глав была немного длинноватой, а вторая половина показалась мне более интересной и заставляющей задуматься. Вероятно, это связано с тем, что, несмотря на некоторое раннее знакомство с BASIC, когда я был ребенком Commodore C64 и Amiga 500, я мог больше относиться к последним событиям из моего профессионального опыта. Однако даже в первых главах цитируются важные фрагменты исследований в области SE:
«Существует уникальный аспект обслуживания, который называется« восстановление знаний »или« понимание программы ». Он становится основным компонентом затрат по мере старения программного обеспечения (предположим, что 50% улучшений и исправления дефектов)». Половина ваших будущих затрат на обслуживание будет потрачена на повторное изучение деталей вашей программы, которые вы тем временем забудете!
or
«… Следовательно, большинство программистов не могут эффективно тестировать свои собственные программы, потому что они не могут заставить себя сформировать необходимую психологическую установку: установку на выявление ошибок».
Вызовы
В целом, мне очень понравился сбалансированный, продуманный стиль письма и обширные знания Барра как в промышленности, так и в исследованиях. В первую очередь он исследует основной вопрос «Действительно ли разработка программного обеспечения сложна или разработчики программного обеспечения не умеют это делать?» с разных сторон. Кроме того, что мне нравится, так это то, что он не утверждает, что знает все ответы, что в его случае, безусловно, является формой преуменьшения и смирения. (Я вернусь к этому в конце статьи.) Автор выделяет некоторые из своих личных проблем, вызванных отсутствием стандартных знаний в области SE и отраженных в таких утверждениях, как:
Я мог наставлять людей, как ориентироваться в корпоративной жизни, но это был общий совет, который они могли получить от кого угодно. Как и у других, мое руководство было расплывчатым: «Ну, в этом одном случае я помню, что такого рода вещи работали нормально, так почему бы не попробовать это?»
Контекст
Влияние контекста на проекты SE и явление, которое он упоминает под названием эффект амнезии Гелл-Манна, становятся еще более очевидными, когда Барр говорит:
Если вы расскажете членам одной команды Microsoft об инженерном опыте другой команды, они сразу же смогут определить - благодаря своим знаниям о внутреннем устройстве Microsoft - чем эта другая команда отличается от своей команды, и, следовательно, уволить руководство как не относящееся к делу. Между тем, они с радостью пропустили руководство по Scrum, даже если оно было совершенно неприменимо к их команде, потому что они не знали деталей среды, в которой оно было успешным.
В главе «Дизайн-мышление» он освещает такие темы, как преимущества шаблонов проектирования, и объясняет в каких ситуациях они могут быть полезны, например, когда вы, вероятно, захотите изменять или расширять код в будущем (поскольку многие шаблоны ориентированы на будущую расширяемость). Однако их применение может быть бессмысленным, если будущие изменения модуля маловероятны, и в этом случае они только усложнят. Кроме того, глава содержит ссылки на забавные термины от известных людей, таких как Спольски (например, «Астронавт архитектуры» - кто-то видит более широкие абстракции и закономерности…) или другие остроумные наблюдения:
Хотя обоснованные архитекторы программного обеспечения в настоящее время считаются лучше, чем те, кто лишен кислорода, тот факт, что архитекторам необходимо постоянное погружение в текущий проект своей команды, является еще одним признаком того, что не хватает общепринятых знаний и словарного запаса в области разработки программного обеспечения.
Автор подчеркивает, что «разумные советы» из таких книг, как «Чистый код» и «Прагматичный программист», не представляют «конкретных подходов». Дизайн программного обеспечения уникален в том смысле, что разработанные системы практически не сопоставимы друг с другом. Поскольку мы часто имеем дело с совершенно новыми областями и бизнес-проблемами, качество результатов проектирования сильно варьируется даже для очень опытных людей. Барр утверждает, что «когда вы убираете ерунду из дизайна программного обеспечения, у вас остаются шаблоны проектирования и ничего больше».
В некоторой степени связанный с контекстом, в главе «Ваш любимый язык» он упоминает, что основная проблема нашего множества разных языков программирования и их самоуверенного дизайна заключается в том, что их очень мало руководство о том, когда один язык превосходит другой для решения определенной проблемы. И снова позже, в главе «Agile», у нас мало знаний о том, когда именно методологии и практики гибкого программного обеспечения, такие как Scrum, действительно ценный. Глава завершается следующими словами:
Хотя Agile может немного облегчить простые задачи, он не помогает решить сложные. Это привлекательно для программистов, но чтобы сделать программную инженерию более инженерной дисциплиной, необходимо кое-что еще.
Исследовать
Когда я провел пару лет в исследованиях и преподавании в университете, после прочтения соответствующих статей или книги «Создание программного обеспечения» (одной из редких книг, которые пытаются донести исследования SE до более широкой аудитории), я был удивлен, узнав, сколько исследований SE существует на самом деле. Однако часто это оставляло меня каким-то образом неудовлетворенным выводами, поскольку вы втайне ожидали универсальных ответов, таких как «Нет, TDD бесполезен» или «Да, шаблоны проектирования ценны» - аргументы, которые вы надеялись использовать в своих следующих обсуждениях с коллегами, чтобы их разобрать. их религиозные аргументы и анекдотические свидетельства. Конечно, из-за ограничений экспериментального дизайна ответы часто были похожи на «Да, в этих условиях и в этом конкретном контексте это может иметь смысл…». Более того, я часто чувствовал, что дизайн исследования не очень хорошо отражает реалии разработки программного обеспечения (что является одной из основных проблем в области SE, основанной на фактах).
Кодирование Додзё
Мне особенно понравилась последняя глава «Будущее» и предложения автора о том, что мы действительно можем сделать, чтобы улучшить ситуацию, и, естественно, многие идеи Барра связаны с образованием, как мы учим SE. в университете и как студенты готовятся к работе в отрасли. Эта глава вдохновляет, и если снова вспомнить мой собственный академический опыт, то разрыв между академическим сообществом и промышленностью всегда беспокоил меня. Барр цитирует Вайнберга, который пишет:
Программные проекты, реализуемые в университетах, обычно не должны обслуживаться, использоваться или тестироваться другим человеком.
Пытаясь немного восполнить этот пробел, мы с моим коллегой тогда придумали новую концепцию курса для наших студентов под названием «Coding Dojo». Основная идея заключалась в том, чтобы организовать многодневный интенсивный семинар, чтобы научить участников тому, что мы считали важным для дальнейшей работы в промышленности, и чему они в противном случае не узнали бы в учебной программе по информатике. Поэтому мы провели мозговой штурм, придумывали идеи, напечатали флаер, который должен привлечь студентов, и создали интерактивную систему для обучения таким темам, как читаемость кода, запахи кода, рефакторинг и т. Д. Мы потратили все наши пасхальные каникулы на разработку этой системы реального времени, которая могла бы представлять интерактивную упражнения с автоматическими оценками и попытались включить все, что мы знали по теме на тот момент, включая материалы из таких книг, как «Code Complete» или «Refactoring».
Я по-прежнему горжусь этой концепцией, и курс оказался успешным (по крайней мере, с точки зрения отзывов и популярности), но, насколько мне известно, до сегодняшнего дня он все еще был разовым. Кроме того, такие семинары, как «Coding Dojo», не помогут решить проблему, заключающуюся в том, что студентам обычно не приходится работать с «более крупными программами», которые, по словам Барра, рано знакомят их с программами, которые «построены из соединений через границы API» и, таким образом, ставят перед ними важные задачи разработки, такие как чтение, понимание и отладка значительно больших систем.
Специализация
В учебных программах CS и SE есть что улучшить, и, как утверждает Барр, специализация может помочь, поскольку вся область знаний стала слишком широкой и сложной, чтобы получить полное представление обо всем. Таким образом, вместо того, чтобы делать такие темы, как компиляторы, графика и расширенные структуры данных - темы с хорошо изученными основами - обязательными, студенты бакалавриата могут сосредоточиться на своих предпочтительных предметах. Это затем поможет сформировать их профиль для будущих работодателей и повысит доверие к степени. Барр пишет:
В настоящее время инженеры-программисты, окончившие колледж, считаются взаимозаменяемыми; Ожидается, что любой программист, если он будет признан компетентным в ходе любой используемой процедуры найма, сможет приступить к работе над любой частью программы. Однако по мере того, как программное обеспечение становится все более сложным, людям становится все более целесообразно специализироваться в разных областях.
Интеллектуальное смирение
И, наконец, мой любимый совет, упомянутый в книге и также услышанный в других местах в прошлом, - «скромное улучшение», подчеркивающий, что если вы сохраняете любопытство и продолжаете учиться, сохраняя настрой «Несмотря на имея многолетний опыт, я не претендую на звание эксперта в этой теме, и всегда есть что узнать ». Несмотря на то, что этот совет может показаться простым, меня неоднократно ошеломляло, насколько высокие кандидаты, претендующие на должность SE, оценивают свой собственный уровень навыков (мы просим кандидатов заполнить «лист самооценки» перед техническим собеседованием). У меня сложилось впечатление, что обычно это признак старшинства, когда люди со значительным опытом не дают себе наивысших оценок в определенных областях, что свидетельствует о том, что они остаются интеллектуально скромными и на самом деле могут быть теми, кто лучше всего совершенствует свои навыки.
