Логика программиста глазами программиста

   Здравствуйте, уважаемые читатели моего блога. В этой статье постараюсь выразить субъективною точку зрения про принципы работы логики ПО (программного обеспечения) на объектно-ориентированных языках высокого уровня. Буду благодарен за комментарии к статье и Ваше виденье этого процесса. Также постараюсь объяснить разницу между администраторами, которые помогают пользователю настроить что-то в системе, и разработчиками ПО. Употребление терминологии по разработке ПО необходимо для того, чтобы соответствовать заголовку статьи, но использовать ее постараюсь по минимуму. Мне очень нравятся две цитаты с того времени, как я стал заниматься программированием: “Всё гениальное просто” и  “Если вы не можете объяснить что-то шестилетнему ребенку, значит, вы сами этого не понимаете” (А.Эйнштейн). Поэтому буду стараться, чтобы все было предельно просто и понятно. 

  Пожалуй, сразу отвечу на вопрос, чем логика программистов отличается  от логики обычных пользователей, - людей, которые сидят по другую сторону монитора и пользуются творениями рук программистов. Ответ очевиден: ничем. Она только немного специфическая в зависимости от того, насколько человек увлечен разработкой ПО. О логике программистов ходят легенды. Мне очень понравилась история об аналитическом мышлении программистов. "На работу к нам приехал программер из фирмы, которая пишет для нас софт. Хороший парень, с чувством юмора. Мы собрались идти на обед. Не помню как, но слово за слово и я выдвигаю ему такую фразу:  "А вот американские ученые провели в свое время такой эксперимент: поделили подопытных крыс на две группы и стали их по-разному кормить. Первую группу ни в чем не ограничивали, а вторую кормили пайком ровно в два раза меньшим, чем первую. В итоге вторая группа крыс прожила в два раза дольше. Вот... Программист посмотрел на меня и сказал без тени улыбки: Да, но сожрали-то они в конечном итоге столько же...”  Вероятно, туман завесы над логикой этой категории специалистов начинает развеиваться перед Вами.

     Постараюсь объяснить на простых примерах, что такое программирование, т.к. в случае использования сложной терминологии при обозначении этого понятия простые читатели будут недовольны. Да и надо же разработчику тренировать умение общаться по-человечески, не употребляя технических терминов. Итак, представьте, что Вы проснулись утром и Вам нужно одеться. Так вот : процесс одевания можно описать сравнить с разработкой ПО. По такому принципу пишут свой код разработчики функционального программирования, которые создают код с помощью функций. Многие могут возразить: какая же здесь может быть аналогия. А теперь представьте ситуацию, когда Вы одели брюки вместо рубашки, а свитер - вместо штанов. Не очень удобно, ведь правда?  У программистов такая же ситуация: если они неверно напишут код или перепутают логику, то у них выйдет то же самое, что вышло у Вас, когда вы оделись наоборот, только в цифровом варианте. Есть особый тип разработчиков, которые пишут на языке разработки Ассемблер. Для понимания представьте себе предыдущую картину, когда Вам нужно одеться, но вместо одежды на Вашем журнальном столике лежат ткань, игла и нитки, и Вам предстоит сначала сшить свою одежду, чтобы затем ее одеть. У этих ребят действительно талант, их упорству можно только позавидовать.

   Теперь, когда Вы знаете отличие разработчиков, пишущих программы на ассемблере (assembler) от тех, которые пишут с помощью функций, пришло время описать немного и работу разработчиков объектно-ориентированного программирования (далее ООП). Этих ребят тоже можно разделить на два типа: на тех, которые пытаются все делать, как описанные выше разработчики функционального программирования, и тех, которые пытаются мыслить объектами. Объекты - то, что Вы видите вокруг себя: дерево, машина, трасса, светофор, здание, человек - являются также объектами для разработчика. В разработке для этого есть много принципов, схем и комбинаций. Например, в ООП существует направление  проблемно-ориентированное проектирование (DDD) (англ. Domain-driven design) . Это набор принципов и схем, помогающих разработчикам создавать изящные системы объектов. Проще говоря, это процесс создания разработчиком аналогичных объектов реального мира в программные объекты с целью упростить нашу жизнь. Это могут быть сложные банковские системы, системы учета, графические редакторы и т.д. Возможно, из приведенного выше описания не все поняли, что такое объекты и как ими оперировать разработчику. Да и зачем они ему вообще.  Рассмотрим другой пример, с которым можно столкнуться каждый день. Допустим, Вам нужно добраться с точки А в точку B. За точку А для простоты возьмем место Вашего жительства, а за точку B  - место Вашей работы. 

Для тех, кто живет в больших мегаполисах, такой способ добраться из дому на работу вполне может подойти. Например, я могу доехать на работу как минимум пятью способами и маршрутами.  Как в такой задаче найти минимальное время и самый удобный маршрут? Для этого нужно поехать каждым маршрутом, сравнить цену, длительность поездки и выбрать оптимальный. Но что, если задача усложняется? Например, нам нужно поехать машиной из одного города в другой за сотни тысячи километров. Способ самостоятельной проверки не подходит. Для этого существуют люди, которые придумывают способы решения таких задач, а разработчики делают так, чтобы пользователь просто указал точку А и точку B и получил выстроенный нужный маршрут. В последнем приложении я описал роботу GPS навигатора J. Есть целый раздел дискретной математики, который изучает графы (граф - это совокупность непустого множества вершин и наборов пар вершин; в нашем примере вершины - это остановки транспорта, а также начальный и конечный пункты назначения, а связи или дуги графа - это дорога, которой можно добраться к точке назначения).

    Выше я описал одну из задач, которая стоит перед каждым программистом: уметь описывать объекты. Перед ними стоит еще одна большая задача: декомпозиция объектов. Это, по сути, разбор большого объекта на более мелкие объекты. Представьте себе, что Вы программист и видите перед собой автомобиль. Ваша задача - написать цифровой вариант автомобиля с помощью объектов.
 Попробуем схематически в общих чертах объяснить, как работает декомпозиция на примере. Разобьём объект "автомобиль" на три главных части, которые далее можем делить на более мелкие объекты. Их на самом деле намного больше, но чтобы понять суть, этого будет вполне достаточно.

Умение правильно компоновать объекты и их правильная декомпозиция - это основа работы успешного программиста. А умение проектировать на основе этих объектов целые системы - это поистине гениально. Разработку программного обеспечения можно сравнить со строительством огромного здания. Каждый разработчик пишет свой модуль, свой «кирпичик» этого здания. Задача архитектора ПО - это спроектировать это здание. Увидеть и описать его так, чтобы другие разработчики по этому описанию смогли построить то, что представил архитектор. Есть очень интересное сравнение работы разработчиков ПО: “Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию – Второй закон Вейнберга.” Пожалуй, на этой оптимистичной ноте я закончу статью. Добро пожаловать в мир цифровых объектов и мир разработки программных продуктов.