Это принципы, тупица!

Как написать код без ошибок, часть II

Как я сказал в части I, нам нужно создать прочный фундамент, на котором можно строить цифровые вещи. И этот фундамент состоит из… принципов!
Мы скоро поймем, почему принципы так важны.

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

К сожалению, я медленно учусь ...

Но вы просто констатируете очевидное!

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

Если бы это было так очевидно, мы бы делали это постоянно, верно?

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

Так что пора проявить принципиальность!

Лучшие практики - отстой, принципы правила!

Лучшие практики, практические советы о том, как лучше всего заниматься, что не нравится? Больше, чем вы думаете.

Рекомендации хороши, но имеют свои ограничения. Чтобы обобщить:

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

Принципы, с другой стороны

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

Пропуская на этот раз Оксфорд, вот мое личное определение принципа:

Принцип - это правило, которое заставляет нас думать самостоятельно.

За каждым передовым опытом любой ценности стоит принцип. Определите его, проверьте и, если он устоит, наденьте его и распространите. Рост стоимости огромен!

И для ясности: «Лучшие практики - отстой, принципы - правило!» это тоже принцип, не позволяйте мете сбивать вас с толку!

Побег из ада зависимости

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

Не думаю, что с этим кто-то не согласен. Тем не менее, живем ли мы этим? Удаляем ли мы все зависимости, которые можем?

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

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

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

Я понимаю, есть причины, и некоторые из них действительно хороши. Но если мы хотим избавиться от ошибок в коде, мы должны судить о них по-другому. Это зависимости, и с ними следует обращаться соответственно. Уничтожить !! 😜

В части III я касаюсь поверхности Dependency Hell!

Хватит изобретать колесо!

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

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

Предположим, вы задокументировали решение, тогда кто-то другой сможет понять, что вы сделали, и извлечь из этого урок. Чего они, вероятно, не понимают, так это ПОЧЕМУ вы решили это таким образом, и они не видят всех способов, которыми вы пытались решить эту проблему до того, как выбрали этот путь. ЭТО было бы очень ценно, согласны?

Если кто-нибудь действительно это прочитает…

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

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

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

Знай, куда идешь!

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

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

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

В этом контексте есть два совершенно разных способа выставить себя дураками.

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

Итак, YAGNI - отличный принцип. Вам это не понадобится. Не реализуйте функциональность, пока она вам действительно не понадобится.

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

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

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

Я опишу итеративный процесс, который действительно работает в части V.

Если что-то кажется сложным…

Если вы читали любую из моих статей о творчестве, я повторяю снова и снова одно:

Если что-то кажется сложным, то, вероятно, мы делаем это неправильно.

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

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

«Достаточно хорошо» недостаточно.

Цифровую задачу можно решить миллионами способов. Часть из них - нормальные, то есть они работают, а часть этой части можно считать «хорошей».

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

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

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

Какашки и прочее будут подробно описаны в части VI!

Продолжение следует…

… И есть что еще сказать. Не пропустите, будет весело! Убедитесь, что вы подписаны на меня здесь, на Medium или на любом из каналов ниже, чтобы получать уведомление, когда они будут опубликованы.

Далее идет Часть III: Побег из ада зависимости!

До скорого!

Прежде чем ты уйдешь

Хлопните 👏 👏 👏 5, 15, 50 раз, если вам понравилось то, что вы прочитали!
Комментарий 💬 Я хотел бы услышать, что вы думаете!
Подпишитесь на меня Йохан Белин здесь на Medium или
Подпишитесь на нашу рассылку , нажав здесь