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

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

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

Вот он, в порядке важности:

  1. Тестовое покрытие, тестовое покрытие и еще раз тестовое покрытие. Из всех вещей, которые помогут доставить хорошее программное обеспечение, тестовое покрытие является наиболее важным. На самом деле, я готов предположить, что простое сосредоточение внимания на одной вещи превыше всего остального даст довольно потрясающий результат. Таким образом, вы можете нанять почти любого, кто может писать код и общаться с другими людьми, если вы убедитесь, что они напишут тесты для всего, конечная работа будет достаточно хорошей, а во многих случаях намного лучше, чем то, что написано каким-то «ниндзя». хакер/гений» (люди, которые идентифицируют себя как таковые, скорее всего, переоценят свои навыки и в результате взорвут проект или компанию). Вывод: Стремление к 100% охвату тестами даст вам 90% преимуществ, которые вы ищете.
  2. Модульность. Это уже намного сложнее, потому что может втянуть вас в квазирелигиозные дискуссии о том, что это значит. Кроме того, вы не можете измерить это, как тестовое покрытие. Однако, чтобы получить эти последние 10% преимуществ от качества вашего кода, вам в основном придется подумать о том, чтобы сделать вашу работу «модульной». Для меня это в основном означает, что каждая отдельная единица кода читается как короткий кусок английского языка, описывающий какое-то действие и возвращающий результат. Он читается как английский, потому что на самом деле использует другие хорошо названные единицы кода, поэтому вы мало что делаете, кроме как используете эти другие модули. Он должен быть достаточно коротким, чтобы вам не приходилось много помнить, читая его. Как короткая статья, где вам не нужно помнить, что было написано вверху, когда вы читаете внизу.

Две вещи, которые я добавлю здесь, на самом деле больше касаются командной работы:

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

Вот и все! Ради интереса, вот список вещей, о которых вы можете забыть (на самом деле этот список можно сделать очень длинным, так как бесполезных вещей в изобилии): алгоритмы CS, детали реализации структур данных, эффективность big-O, оптимизации «что, если», метапрограммирование и другие расширенные функции языка (все, что трудно запомнить, связанное с наследованием или типами), любые предопределенные программные головоломки, требующие много размышлений (да, программирование — это не решение головоломок, извините за это, решение проблем, придуманных другими для точной цели проверки ваших «навыков кодирования» не поможет вам в программировании в реальном мире, точно так же, как шахматисты не лучше среднего в реальной стратегии).