Искусство войны в применении к разработке программного обеспечения

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

Чего вы, возможно, не знаете, так это того, что эта парадигма восходит к старой политической стратегии (название происходит от латинского выражения « разделяй и властвуй» ), которая предполагает, что можно сохранять контроль над своими подчиненными или подданными, поощряя разногласия между ними.

Эта стратегия использовалась бесчисленным количеством политиков и военачальников на протяжении всей истории, таких как Юлий Цезарь (который использовал ее во время Галльских войн, чтобы победить сильных в военном отношении галлов) и Наполеон (французский специалист по артиллерии разделял вражеские войска, чтобы ни одна часть не была сильнее) чем его собственные войска, а затем нарушить их связь, препятствуя усилиям противника по координации и проведению атак).

Искусство войны: применение древних принципов к развитию

Однако правило « разделяй и властвуй » — не единственная политическая стратегия, применимая к разработке программного обеспечения. Хотя политика и война имеют мало общего с разработкой программного обеспечения, так же как политики и генералы, разработчики должны руководить подчиненными, координировать усилия между командами, находить лучшие стратегии для решения проблем и управлять ресурсами.

«Искусство войны» — древний военный трактат, написанный в пятом веке до нашей эры и приписываемый Сунь-Цзы, древнему китайскому военному стратегу, чьи теории оказали глубокое влияние как на восточную, так и на западную философию.

Несмотря на свой возраст, этот текст до сих пор включен в учебную программу многих военных училищ в Восточной Азии и внесен в список рекомендованных к прочтению в некоторых военных академиях на Западе. Текст разделен на 13 глав, каждая из которых посвящена разным аспектам ведения войны.

Однако, помимо ведения войны, принципы и учения Сунь-Цзы имеют практическое применение в политике, бизнесе, спорте и, хотите верьте, хотите нет, в разработке программного обеспечения. На самом деле, возможно, вы просто применяете некоторые из этих принципов в своей повседневной жизни, даже не зная об их происхождении.

Ниже вы найдете краткий список основных тактик и советов, объясненных в «Искусстве войны». Они, вероятно, могут быть применены к вашей работе в индустрии программного обеспечения или в любой из ряда других отраслей.

Время имеет решающее значение в любой кампании

Глава II, пункт 2

Когда вы вступаете в настоящую битву, если победа не за горами, то оружие людей затупится, а их пыл угаснет.

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

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

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

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

Глава II, пункт 18

Итак, на войне пусть вашей главной целью будет победа, а не длительные кампании.

Эту фразу можно интерпретировать двояко:

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

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

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

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

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

Нет лидерства, нет результатов

Глава III, пункт 11

Теперь генерал является оплотом государства; если бастион цел во всех точках, государство будет сильным; если бастион неисправен, государство будет слабым.

Эта цитата описывает важность роли менеджера в команде разработчиков: успех проекта зависит от силы всех вовлеченных людей , а менеджер является оплотом проекта. Ответственность начинается сверху.

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

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

Глава VI, пункт 28

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

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

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

Конечно, изучение нового языка программирования или использование неизвестного API поначалу может быть дорогим, но в долгосрочной перспективе качество программного обеспечения будет выше, и вы станете лучшим разработчиком.

Глава XIII, пункт 27

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

Эту фразу можно интерпретировать как важность использования инструментов мониторинга и библиотек журналирования на этапе обслуживания.

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

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

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

Работа в команде и мотивация

Глава X, пункт 24

Тот, кто продвигается вперед, не ища славы, Кто отступает, не избегая порицания, Тот, чья единственная цель — защищать свой народ и служить своему господину, Этот человек — драгоценность Царства.

По сути, это древнекитайская версия «в команде нет я» . Важнее работать вместе с другими, чем преследовать личную выгоду.

Разработка программного обеспечения — это сложная деятельность, которая требует от разработчиков эффективной совместной работы. Хороший разработчик — это не тот, кто исправляет больше всего ошибок, реализует больше функций или заканчивает работу раньше срока; хороший разработчик — это тот, кто помогает команде достичь ее целей.

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

Глава VII, пункт 21

Подумайте и обдумайте, прежде чем сделать шаг.

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

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

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

Глава X, пункт 25

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

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

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

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

Нестандартное мышление

Глава V, пункты 7, 8 и 9

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

Существует не более пяти основных цветов, но в сочетании они дают больше оттенков, чем можно когда-либо увидеть.

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

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

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

Глава III, пункт 1

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

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

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

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

• Если вы действительно не уверены в том, что делаете, замена работающего участка кода означает, что вы рискуете внести новые ошибки или баги.

Это не означает, что фраза «Если это не сломано, не чините это» является хорошей стратегией, но что у каждого проекта есть приоритеты, цели и временные ограничения. Итак, если вы найдете код, который можно улучшить, обсудите его с остальной частью команды или с менеджером проекта, чтобы выяснить, когда его оптимизировать.

Глава VIII, пункт 3

Есть дороги, по которым нельзя ходить, армии, на которые нельзя нападать, города, которые нельзя осаждать, позиции, которые нельзя оспаривать, приказы государя, которым нельзя подчиняться.

Даже если прямо об этом не говорится, мы можем интерпретировать этот принцип как предупреждение избегать антишаблонов.

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

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

Заключение

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

Однако « Искусство войны» — не единственная книга, содержащая принципы, применимые к разработке программного обеспечения. Например, «Государь » Никколо Макиавелли.

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

1. Лев не может защититься от ловушек, а лиса не может защититься от волков. Следовательно, нужно быть лисой, чтобы распознавать ловушки, и львом, чтобы пугать волков.
2. Никогда не пытайтесь завоевать силой то, что можно завоевать обманом.
3. Никогда ничего великого не достигалось без опасности.
4. Тот, кто желает постоянного успеха, должен со временем менять свое поведение.
5. Люди обычно судят больше по внешнему виду, чем по действительности. У всех людей есть глаза, но лишь немногие обладают даром проницательности.
6. Тот, кто хочет, чтобы ему подчинялись, должен уметь командовать.
7. Мудрость состоит в том, чтобы уметь различать природу неприятностей и выбирать меньшее из зол.
8. Войны не избежать; его можно только отсрочить в пользу вашего врага.
9. Природа создает немногих мужественных мужчин; промышленность и обучение делают многих.