Предлагаю перейти на сторону зла, на темную сторону программирования. Ситхи сильнее джедаев. И печенек хватит на всех. Предупреждаю, прежде чем начнете читать далее. Характер при переходе на темную сторону портится.
Прошу под кат
Перевернутая шкала ценностей
Есть легенда, что каждый раз, когда программист пишет плохой код – Бог убивает котенка. Пора признаться, что все мы – убийцы котят. У некоторых руки по локоть в крови. Первый шаг в сторону силы – признать в себе это. Любой код – это привнесение во Вселенную хаоса. Любой символ – рост энтропии. Если мы признаем это, то спадет маска умиления и радости от кодирования. Всё, что мы делаем – плохо. И с этим нельзя ничего поделать. Можно только пытаться делать это в меньших количествах.
Мы как самураи. Мы обучены убивать. Но смысл – не убивать. Или убивать как можно меньше. Лучший бой – не начавшийся бой. Лучший код – не написанный код. Любой код – зло.
Перевернутая шкала ценностей – это оценки в отрицательной части – плохо, хуже, еще хуже. Не бывает хорошо, лучше. Ситхи верят, что джедаи заблуждаются в плане: бывает хороший код, бывает лучше. Не бывает. Отрицательная шкала – это кругом только зло. И ситхи вынуждены выбирать меньшее зло. Джедаи выбирают наибольшее добро. Т.е. если они видят два решения, то они видят позитивные качества и на основании своих предпочтений выбирают то, что лучше.
Отрицательная шкала дает больше градаций для действий. Ситх не страдает умилением от кода. Джедай часто «зависает» от умиления и радости познания нового. Он видит много путей решения задачи и каждый из них «имеет право на существование и плюсы». Джедай болеет проблемой выбора. Всё такое вкусное для него. Это стоит жизни новым котятам. Джедай, например, может увлечься чем-то хорошим и интересным и впилить ненужный фреймворк в проект. Просто потому что это классно и ново для него. Если джедай видит несколько хороших решений, то выбор часто становится волей случая.
Ситх не страдает проблемой выбора. Он не медлит в выборе. Для него очевидно, что всё плохо, поэтому менее плохо то, что позволяет сократить деятельность.
Есть побочный эффект от такого подхода – окончательно портится характер. Ситх любой код называет говнокодом. Что может разрушить отношения в коллективе джедаев. Джедай думает примерно так: «Каждый подход и инструмент имеет свои плюсы и минусы и ситх почему-то категоричен, называя их применения говнокодом». Про минусы джедай лукавит, т.к. никогда на них не концентрируется, видя во всем только плюсы. Ситх же всё называет говнокодом, шкала такая. В зависимости от задачи, он пытается его уменьшить, а не любоваться еще одним способом решить задачу. Для ситха любое решение плохое. Но некоторые еще хуже.
Выражать мысль заказчика
Вершиной сокращения деятельности является прямое выражение мысли. Причем, мысли из предметной области. В связи с этим, язык программирования рассматривают как язык общения. Это язык, на котором выражают мысли. Популярность ООП связана как раз с этим: наши естественные языки требуют подлежащего и сказуемого. Подлежащие – это объекты, сказуемые – методы. Это не мир состоит из объектов, это восприятие и естественный язык такой. Иногда получаются казусы, вроде «ветер дует», «свет светит». Бред. Здесь нет объекта и его действия. Такой же бред иногда встречается в энтерпрайзе. Но так уже повелось, поэтому ООП часто является естественной формой выражения мыслей, перевода с языка заказчика.
Это не реклама ООП. Более жесткие способы описаний (см. Жесткость) приветствуются.
Язык программирования – это не конструктор для программ. Так же как в естественном языке есть грамматика – знание грамматики не говорит о том, что вы можете выражать мысли, ясно, точно, лаконично. Если вы до сих пор увлекаетесь паттернами, оптимизациями, разными возможностями – вы еще новичок. Умение выразить мысль – вот что главное. А не сколько раз в предложении встретилась буква «М».
Не стоит восторгаться возможностями, которые предоставляются с языком, вроде работы с многопоточностью и тому подобное. Всё это относится не к задачам, не к мыслям заказчика. Нас интересует только то, насколько он позволяет лаконично и ясно выразить мысль заказчика.
Если заказчик просит нас перевести на язык программирования «собачка перешла дорогу», то точно так и надо поступить. Не коровка, не кошечка. Многие программисты настолько увлечены процессом, что пишут: «Белая болонка в позолоченном ошейнике пересекла дорогу на углу возле дерева, перед которым только что справила нужду». Создают не только породу и ошейник. А строят еще и миску для нее и хозяйку. Всю инфраструктуру города. Потому что воспринимают язык, как конструктор. Зачем? Да чтобы вдруг заказчик захочет собачку покормить потом, выразит такое требование – миска уже была, город был.
Надо признать, что иногда языки программирования требуют создать некоторую инфраструктуру. Но тогда надо минимизировать эту деятельность, потому что кпд программиста будет вычисляться формулой:
(Полезная работа) / (Затраченная работа)
И не надо себя обманывать, что какой-то WCF канал входит в полезную работу, а заказчик о нем мечтает, просто не знает о нем.
Убить в себе гуманитария
Как-то в частной беседе, знакомая, психолог, нарисовала большую галку:
И спрашивает:
— Что ты видишь на листке?
— Галку – ответил я, не понимая, к чему этот вопрос.
— Ничего из тебя не выйдет. Ты не креативная личность, не способен на творчество. Это простой тест на креативность. И чем более творческая личность, тем причудливее видит формы. Некоторые сердечка, облака, некоторые даже лошадей.
Потом со вздохом добавляет:
— Но математики почему-то видят почти всегда галку… Редко – знак бесконечности.
Я:
— Они видят галку, потому что это похоже на галку.
Тогда у меня и сложилось мнение, чем отличается аналитический ум, точные науки, от гуманитарных наук и искусства. Человек взаимодействует с внешним миром и создает артефакты. Разница только в том, откуда идет поток информации при создании артефакта – от себя или от мира. В точных науках занимаются познанием мира и стараются от себя делать поменьше предположений. Смешно было бы услышать при решении задачи по физике несуразицу со словами «Я так вижу».
Креативные же личности запросто так говорят. И креативят в коде. Каждый раз, когда я слышу от программистов «у нас творческая профессия», «могут быть все правы, у каждого свое мнение», «существует масса способов решить» — то вспоминаю лошадей вместо галки. Каждый раз, обычно, при тех словах, программисты уже что-то задумали – какую-то гибкость (про которую позже).
В точных науках способов решить правильно задачу бывает несколько. Но решить неправильно – бесконечное число способов. Правильные решения обычно основаны на механических правилах.
У нас, у программистов, источник внешней информации – заказчик. Существует не такое большое число способов как можно точнее перевести его требования. При этом каждый язык программирования предлагает свой естественный способ.
Что еще отличает людей с точным складом ума – это то, что язык используется для выражения каких-то внешних по отношению к языку мыслей.
Детская загадка:
Что находится посредине Земли?
Ответ: буква «М».
Это пример, когда путают объект с частью языка – словом.
Люди с точным складом ума оперируют объектами, а не словами или конструкциями языка. И наоборот, люди с ГСМ бывает находят красоту в звуках, в комбинациях слов, скрытый смысл в корнях слов и тому подобное.
Ситхам надо убить в себе гуманитария. Мы не творческие люди, мы инженеры. Да, сейчас это не модно.
Оперировать смыслом в коде – это выражать мысли заказчика. Но джедаи настолько увлекаются языком, его свойствами и конструкциями, что переходят все грани в своем творчестве. Это нелепо выглядит со стороны, так же как кони в галке.
Жесткость
Программы должны быть жесткими, а не гибкими. Узнали в себе джедая? У ситхов перевернутая шкала.
В университетах и в книгах учат, что плохой код — это негибкий код, хардкод. Это всемирный заговор и обман. Всё ровно наоборот. Программа должна удовлетворять требования заказчика. Причем на данный момент. И точка. Причем удовлетворять самым жестким способом, самым ограниченным. Ограничения для программы – это как рельсы для поезда. Программа должна выполнять свое предназначение и не отклоняться ни на сантиметр. В связи с этим верный союзник – статическая типизация. Программист специально создает типы, которые не могут программе позволить вообще оказаться в запрещенных местах и это проверяет компилятор до запуска.
Гибкость программы вообще не является приоритетом. Как можно, чтобы программа была и гибкой и одновременно жесткой? Фокус в том, что не учат, забывают, что единственно важная вещь для программы – быть правильной. То, что из-за хардкода будут проблемы в будущем у программиста, если требования поменяются – это ли должно волновать заказчика? Это индейская проблема. Но настолько все сконцентрировались на гибкости и паттернах, что жесткость начала порицаться. Когда как только она и обеспечивает правильность работы программы. Конечно, плохой хардкод будет приносить проблемы, что идет в разрез с ситховской минимизацией деятельности. Но в вершине нашего мировоззрения стоит краткость и ясность изложения мыслей в программе. А значит, программу легко переписывать, менять код. Гибкость если и есть, то она «вынужденная». В оценку эффективности разработки надо включать не только сам язык, но и IDE. Можно не закладывать гибкость из страха изменений. Не в блокноте работаем.
Умерщвление программы и баги
Ситхи любят баги. Их ждут, их уважают. Как только встречается баг, ситх бросает всё и уделяет внимание только ему. У багов такая природа: пока не выяснили причину, не известна важность и урон бага. Если в программе проявился баг – программа теряет доверие. Лучше ей не работать. Не работающая программа в общем случае приоритетнее, чем работающая кое как. Продолжающая работать программа просто ест ресурсы, а не производит полезного действия. По крайней мере, не доказано, что она делает что-то полезное. Мало того, работающая программа часто скрывает баг. Которого так ждут ситхи.
Так как ситхи ждут баг, то приоритет в том, чтобы баг был очень заметен. Чем настойчивее он себя проявляет, тем лучше. А чем не лучший способ захватить внимание, как упасть программе? Я видел пару раз приложения, где ошибки складываются в лог. И как можно догадаться, лог этот не читают длительные сроки.
Более худший вариант – не падать всей программе, всему процессу, а перехватить в вершине стека исключение и передать поддержке. Такие варианты являются приемлемыми для многих решений, где выполняются независимые операции. Например, часто при работе с базой данных. Каждая операция сравнительно независимая и программа продолжает работать, если не выполнила или не может выполнить какую-то одну. Но в общем случае, делать такие предположения нельзя.
Я (как ситх) не призываю писать ПО, которое падает при каждом вздохе полностью. Тут, надо выбирать меньшее зло и брать на себя ответственность, что опаснее простой, когда упало всё и ошибка исправляется, или продолжение работы, когда падает только какая-то одна операция. Часто приемлемее второе решение.
Самый худший вариант, это когда программист считает, что программа должна выживать, включая каждый локальный кусок. Каждый метод пишется так, как будто бы он находится на поле боя в окружении одних врагов, не имея союзников. И он пытается решить возложенную на него задачу, если не может, то найти обходной путь, если не может, то выжить просто так. Это ацкий говнокод. Даже поиск обходного пути. Если нечто случилось такое, что методу приходится обходить, то значит либо баг во внешнем коде, а метод покрывает его деятельность, либо программист что-то не знает о внешнем по отношению к методу коде. Что чревато. Писать методом «наугад», признак не то, что новичка, а нулевичка.
Заключение
Думаю, достаточно хотя бы этих пунктов на сегодня. Это не претендует ни на манифест, ни на полный обзор, как оценивать код и разрабатывать. Но общее положение – перевернутая шкала, дает некоторые преимущества.
Надеюсь, день стал нескучным.
Автор: m36
