Много лет назад я написал сообщение в блоге, в котором объяснял, что не так с компьютерами, и, по сути, говорил, что проблема заключается в сложности. Несколько лет спустя я опубликовал Code Simplicity, которая, по сути, была тезисом, описывающим, как и почему простота является самым важным качеством программного обеспечения.

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

Я думал, возможно, наивно, что это просто известный факт — что, когда я сказал “простота”, все просто поняли, что я имел в виду. В какой-то степени, честно говоря, это было правдой. Когда вы произносите слово “простота”, люди, по крайней мере, получают некоторое представление. Но я заметил, что люди будут применять его по-разному, некоторые из них совсем не то, что я предполагал. Я бы видел, как люди указывают на функцию или файл и говорят: “Смотрите, теперь в нем меньше строк кода, поэтому он проще!” Или скажите: “Смотрите, эта система использует такой-то шаблон проектирования, поэтому теперь она проще!” Или, что еще хуже, “Эта система теперь полностью универсальна и повторяет все то, что "все знают", что вы должны делать с программным обеспечением, так что это просто, не так ли?”

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

Для программного обеспечения “простой” означает легкий для чтения, понимания и правильного изменения.

В этом определении есть несколько важных моментов.

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

Это сразу говорит вам о том, что вы никогда не напишете компьютерную программу, которая волшебным образом выполнит все упрощения программного обеспечения. Инструменты абсолютно помогают людям в их стремлении упростить и сделать код понятным. Но они не могут выполнять всю работу. Если кто-то хочет взять на себя задачу по упрощению программного обеспечения в своей компании, будьте очень скептичны, если их единственным решением является инструментальное решение. Если они говорят: “Мы хотим поощрять эту лучшую практику, улучшая инструментарий”, отлично! Это человеческий фактор. В практику вовлечены люди. Но никогда не упускайте из виду тот факт, что упрощение программного обеспечениявсегда предполагает, что люди действуют причинно, чтобы развить эту простоту (обычно путем удаления или изменения чего-то, что трудно понять, во что-то более понятное).

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

Одна из вещей, о которых это говорит нам, заключается в том, что простота имеет тенденцию приходить, когда человек тратит некоторое время на то, чтобы уделять внимание простоте кода. Это звучит очевидно, но если вы понаблюдаете за поведением многих команд разработчиков программного обеспечения, вы обнаружите, что они не оперируют этим фактом. В частности, это означает, что какой-то человек, ответственный за фрагмент кода (не ответственный в смысле “виноват в этом”, но ответственный в смысле “владеет им и активно работает над ним”), практически необходим для разработки simplicity. И это проявляется в физической вселенной. Вы можете видеть, что чтение, понимание и модификация неподдерживаемого, никому не известного кода почти всегда становится все более и более трудным с течением времени. Я говорю “почти всегда” только потому, что я не рассматривал каждый отдельный фрагмент кода в мире, и потому, что для того, чтобы это было полностью правдой, вам пришлось бы рассматривать его в течение бесконечного времени (то есть, он имеет тенденцию становиться все более и более сложным, чем дольше он не поддерживается, поэтому иногда его приходится очень долго не поддерживать, прежде чем вы действительно столкнетесь с этим). Но это было верно в любой ситуации, которую я когда–либо видел - я не знаю ни одного контрпримера, где фрагмент кода становился проще, чем дольше он не поддерживался. Когда вы позволяете программному обеспечению быть недоступным, вы позволяете ему со временем усложняться для чтения, понимания и обслуживания.

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

Если вы не думаете, что это правда, спросите разработчика, почему он совершил взлом, в следующий раз, когда увидите взлом. Они либо скажут вам, что не понимают, что делают (еще одна основная причина сложности), либо скажут вам что-то вроде: “Ну, эта другая библиотека очень сложна в использовании и работает неправильно, поэтому мне пришлось сделать это таким образом”. Но подумайте об этом. Разработчик часто говорит: “Я не хотел тратить время на исправление этой другой библиотеки”. Вау, скажете вы, это довольно жестко! Исправление этой другой библиотеки могло бы потребовать много работы! Верно, но было ли у них на самом деле время, чтобы это сделать? Возможно, они так и сделали. Можно также сказать: “Я не чувствовал ответственности за эту библиотеку”, и именно здесь вы снова видите ответственность, связанную с причинами сложности.Может быть, это было “вне их контроля”, как это было в другой компании или что-то в этом роде. Хорошо, это все еще декларация уровня ответственности, которую они готовы взять на себя. Я не говорю, что решение там было плохим, просто вы должны признать, что вы принимаете сознательное решение о том, насколько ответственным быть (вы могли бы связаться с другой компанией, сообщить им об этом, поработать с ними, чтобы исправить это и т. Д.) и что вы намеренно решаете сделать сложность вместо того, чтобы тратить время на разработку простоты.

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

Определение простоты