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

  1. Искусство войны: древние принципы в применении к развитию
  2. Время имеет решающее значение в любой кампании
  3. Глава II, пункт 18
  4. Нет лидерства, нет результатов
  5. Глава VI, пункт 28
  6. Глава XIII, пункт 27
  7. Работа в команде и мотивация
  8. Глава VII, пункт 21
  9. Глава X, пункт 25
  10. Нестандартное мышление
  11. Глава III, пункт 1
  12. Глава VIII, пункт 3
  13. Заключение

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

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

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

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

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

Принципы и учения Сунь Цзы имеют практическое применение в политике, бизнесе, спорте и разработке программного обеспечения.

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

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

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

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

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

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

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

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

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

Разделите ваш план развития на легко достижимые цели и этапы. Это хорошо для морального состояния.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответственность начинается сверху

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

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

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

Глава 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. Природа создает немногих мужественных людей; промышленности и обучения делает много.

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