Привет, здесь…

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

Итак, приступим к пункту! Вы слышали об этих условиях до …

K-I-S-S,

Y-A-G-N-I,

D-R-Y?

Ну а если нет! Вы попали в правильное место! Я собираюсь научить вас некоторым из наиболее важных принципов для разработчиков с некоторыми интересные примеры!

Это необходимые принципы, которые мы должны знать, чтобы не только стать хорошими разработчики, но эффективно, отличные!

Начнем с…

K-I-S-S

Акроним от слова KISS - держите это простым глупым…

Когда я впервые услышал этот термин, я подумал про себя … Что это означает ?

Почему мы должны держать вещи глупыми? Это немного странное слово для употребления.

Придумайте крутой пример…

Что, если мы построим алгоритм машинного обучения для решения головоломку?

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

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

Чем меньше проблема, тем легче ее решить верно?

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

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

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

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

Следующий…

Y-A-G-N-I

Аббревиатура YAGNI означает, что вам не это нужно…

Давайте воспользуемся тем же примером…

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

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

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

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

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

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

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

ЯГНИ, тебе это не понадобится!

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

И наконец…

D-R-Y

Сокращение от слова DRY - не повторяться…

Надеюсь, вы все еще там?

Мы почти на финишной линии, поверьте мне ...

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

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

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

Если вы понимаете, что делаете, ваш код станет более чистым, потому что тогда вы начнете замечать способы улучшать каждый раз. Это связано с принципом Y-A-G-N-I, согласно которому ...

Вам не нужно повторяться, потому что вам это не понадобится!

Давайте посмотрим на этот очень простой пример, который я создал ниже в коде Visual Studio…

Итак, у нас есть две функции, которые выражают двух людей и некоторые детали о них. У нас также есть условное утверждение, показывающее, кто может быть старше и регистрирует сообщение в консоли. Можете ли вы найти какие-либо проблемы с кодом, которые могут нарушают принцип СУХОЙ?

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

«Алиса старше Тео»

мы могли бы заменить его на…

"Alice.name" и "theo.name"

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

(Примечание: я также добавил тернарный оператор для оператора if. Обычно он используется, когда у вас есть небольшой условный оператор. Например, он только указывает, старше ли Алиса, чем Тео, и наоборот. Это отличный инструмент, и мне нравится его использовать, потому что он делает все намного чище).

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

Вы можете пропустить это, если уже знаете, как это делается!

Итак, вы сравниваете два возраста с помощью ‘› ’оператора. Например, вам не нужно писать оператор if, потому что синтаксис автоматически знает, что вы являются письмом условием.

Итак, «alice.age› theo.age »эквивалент выражению« если возраст Алисы больше возраста Тео ».

Тогда "?" Означает, другими словами, сделай следующее! В этом случае затем регистрируется «Алиса старше Тео».

ТАК, как видите, я использовал тернарный оператор, который полезен потому что написано в одну строчку. Просто и легко. Мне потребовалось время, чтобы привыкнуть к нему, но после нескольких пробежек я не могу перестать его использовать! Обязательно проверьте это! Если вы хотите писать более быстрый код!

OK,

Наконец-то мы подошли к концу…

Большое спасибо за чтение,

И я надеюсь, что это было полезно…

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

Если вы еще этого не сделали, проверьте другие мои истории…

Удачного отличного дня!

О, и подписывайтесь на меня в Twitter @ lailacodes!

Рекомендуемые книги для чтения с чистым кодом:

Чистый код Роберта Сесила Мартина

Спасибо,

Лейла