Жизнь по понятиям или принципы в программировании

Короче, в программировании тоже есть свои принципы, чтобы клёвые программисты могли жить по ИТшным понятиям. Сегодня я решил пройтись по-понятиям и разобраться с ними. 

Очень часто я буду объяснять своими словами, которые могут отличаться от тех, которые используют другие программисты или авторы книг. Воспринимайте эту работу как мое личное мнение и как моя личная попытка интерпретации принципов. Здесь НЕ будет официальных определений. 

Make it work

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

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

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

KISS - keep it simple stupid

Мне нравится, что принцип «делай проще тупица» говорит нам делать проще, но при этом состоит из четырёх букв и слов, а ведь можно было сделать проще и сказать KIS и просто Keep it Simple и смысл не поменяется. 

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

You Aren’t Gonna Need It

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

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

Если что-то не нужно сейчас, то не делаем. Это утверждение пересекается с определением KISS, но иногда я вижу, что его относят и к YAGNI. 

Don’t repeat yourself 

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

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

Standing On The Shoulder of Giants

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

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

Да, мы должны следовать стандартам, использовать лучшие практики, паттерны программирование, лучшие и современные инструменты, но если нам нужно просто написать статичный одностраничник, то делать это на платформе .NET может оказаться слишком дорогим и глупым выбором. Обратите внимание, я сказал, что «может оказаться». В программировании все очень тонко и даже одностраничник может быть очень сложным SPA приложением. 

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

Boy Scout Rule

Правило бойскаута по мнению Дяди Боба гласит, что мы должны оставлять после себя код чище, чем он был до нас. Это практически постоянный рефакторинг - улучшать код, чтобы он не превращался в кашу. 

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

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

Заключение

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

Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание