Еще один паттерн… Часть 2. Погружение в проблему

Уиллард Гиббс: «Математик может говорить все, что взбредет ему в голову, но физик обязан сохранять хотя бы крупицу здравого смысла»

Вавилов: «…физик обязан быть философом»

Э. Резерфорд: «Наука — это физика; все остальное — собирание марок»

Мы упоминали о том, что программисты часто не заботятся о том, КТО и КАК будет использовать их творение. Их волнуют другие аспекты… А именно в этом — корень зла.

Так сложилось, что программирование причисляется кем-то невидимым к математике. Уверен, если бы физики обратили свои взоры на проблемы в программировании, результат был бы весьма предсказуем. То ли программисты плохо знают физику, то ли процесс программирования изменяет сознание, понять трудно. Причем здесь физика, зачем физика? Да очень просто. Физике присущи логика и здравый смысл. А какой смысл в фразе Dev Lead проекта: «Эта фича не вписывается в архитектуру…»?

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

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

 

 

Закат эпохи Microsoft

Ах, как искренне жаль, что .NET уходит из моей жизни. Не навсегда, не насовсем, но уходит… Это лирическое повествование, ни в коей мере не претендующее на логичность и полноту околонаучного исследования,  посвящено эмоциям, которые, вероятно, в той или иной мере переживал последние годы программист этой платформы. В этой статье попытаюсь вспомнить наиболее знаковые события и обстоятельства, которые имели место быть начиная с появления каркаса того, что стало звучать как .NET платформа для разработчиков. До появления .NET огромную долю прикладных программ на рынке ПО, составляли программы, написанные на Visual Basic. Программисты Visual Basic составляли целую армию. Наверное, потому, что писать программы с помощью такого высокоуровневого средства было по настоящему легко. С каким благоговением они искали книги Эпплмана (Dan Appleman) по использованию функций Win32 API в своих программах…
Сейчас смешно вспоминать, но над ними часто посмеивались программисты из мира С. Основным и единственным критерием, по которому VB причислялся ими к недоязыкам, был тот, что VB работал с «железом» не напрямую, а через вызов интерпретирующих библиотек, написанных, как водится на С/C++. С появлением .NET эти разговоры быстро прекратились (стали не модными), поскольку сам .NET, выстроенный с учетом опыта JAVA, оказался исполняющей средой для программ, написанных на C# и VB.NET.
 
Многочисленным поклонникам VB рекомендовали в спешном порядке переходить на VB.NET. И все бы ничего, как вдруг оказалось, что вновь опубликованные на MSDN, «горячие», так сказать, примеры, касаются только C#. Нет, конечно, со временем появились и книги. Вот одна из лучших по Windows Forms Charles Petzold. Но книга, по моему мнению, для неспешного чтения, скорее отдыха, чем для работы. Для рабочего процесса она часто не подходит. Ну, бывает, забыли. Ан нет, прошло пару лет, пришла технология WPF, а актуальных примеров для VB так и не появлялось. Так был нанесен удар по сообществу Visual Basic программистов. Кто то перешел на C#, кто-то еще куда… Оба языка прекрасны своей объектной моделью — среда исполнения то одна. Все отличие сводится к тому, что VB.NET более многословен. Это — не недостаток, это — особенность, способствующая более быстрому пониманию.
С появлением .NET многим казалось, что появится множество языков, которые удовлетворят все запросы и вкусы. Не будем перечислять «сгоревших» на этом пути. Трудно сказать, почему этого не произошло. В одном лишь убежден точно — ответ надо искать в Microsoft.
Продолжение следует…

Еще один паттерн… Часть 1. Введение

patternПосвящается людям! Не кодирующим ботам…

Сколько времени  и сил было истрачено сообществом программистов на бесплодные словесные баталии о паттернах проектирования. Причем разговоры эти ведутся не между адептеми веры и отступниками, а, в основном, между самими приверженцами так называемых гибких архитектур. Модно — не модно, так правильно, а так — нет, это не каноническое понимание… Вот темы бесконечных разговоров. Человек, как сказали бы в старину, логический, просто сошел бы с ума, читая комментарии на хабрахабре. Человеку вновь прибывающему в стан программистов никто толком и не пояснит простых истин. Он оказывается в положении беспомощного бессловесного созерцателя, которому время от времени намекают: Помалкивай мол, дурачок, не до тебя. А между тем, дурачок этот часто владеет в совершенстве дифференциальным и интегральным исчислением, что в 1000 раз ценнее в самом программировании, чем выученные наизусть ответы на «Самые актуальные вопросы интервью 2015 года по C#». Здравый ум состоит в умении из небольшого числа исходных положений выстраивать не спеша сложные конструкции и делать выводы. С этой точки зрения, в современном программировании здравого ума почти не осталось. Его заменили фреймворки и чужие мнения. А уж вопросам на собеседованиях надо отдельную статью посвятить.

А истины эти на ладони… Самое главное в профессиональной деятельности любого человека — востребованность результатов его труда. Подавляющее большинство программистов этого давно уже не в состоянии понять. Они настолько зависимы от чужого мнения очередного Збышека (Джона, Ивана), который де общался с самими…, и написал такое…, и работал в…, что даже при умении делать простые логические выводы и проявляя склонность к обобщениям в старших классах средней школы, теперь он живет в постоянном ужасе от того, что его де код увидят и непременно предадут анафеме — будут смеяться и троллить, выражаясь сленгом.  Речь идет, конечно, о прикладном программировании, то есть предназначенном для решения задач в прикладных областях: финансах, экономике, машиностроении, медицине и так далее. Это буквально означает следующее. Если человеку из предметной области понятно то, что у Вас расположено на экране, а функционал программы позволяет получить необходимый именно ему результат — дело в шляпе. Если нет — программист слаб. Вот и весь критерий. Давайте посмотрим на современный софт. По пальцам рук можно сосчитать такие программы.

Если эти строки читает пытливый ум, разочаровавшийся в своей (естественнонаучной, инженерной-технической) деятельности, и возмечтавший сменить профессию, то добавим. Современное прикладное программирование напоминает Fashion industry со всеми своими причудами, причинами и следствиями. И два слова о том, как написать хорошую программу с технической точки зрения науки о программировании (если таковая вообще существует), ту, о которой говорилось выше. Прямых критериев правильного кодирования не существует, есть только косвенные. Мировой опыт (не достижения единиц) выдвигает 3 критерия или признака успеха:

  • Вы должны читать работающий свой и чужой код как художественную книгу, не задумываясь более 1-2 мин. Это — не послание Сенеки Луцилию.
  • Вы должны изменить вид и функционал программы по первому требованию пользователя (Заказчика), при том единственном условии, что последний пребывает в трезвом уме и здравом рассудке.
  • Вы должны разбираться в предметной области программы не хуже пользователя (Заказчика).

Достижение первого «Должны» систематизировано в книгах Мартина Фаулера, второго — в книге «Банды четырех» (и локальных адаптациях), достижение третьего полностью перекладывается на Ваши плечи. Но трех указанных пунктов мало, есть еще один, ненаучный и самый нелогичный, четвертый — нужен консультант по Fashion Industry, который укажет что сейчас модно, как носят, как подают, какой формы кнопки в моде и какие языковые конструкции (C#, Java, Object Pascal, VB.NET, …) прямо указывают на королевскую кровь, какого инструментария Вас лишат завтра и в какую сторону движется поставщик библиотеки. Мир изменился… Человек по Fashion Industry определяет большую долю успеха Вашего творения, его мнения нельзя не учитывать. Представьте, Вы просыпаетесь и Вам сообщают: «Больше этой библиотеки нет, теперь все будет иначе…»  Узнаете, на кого намекаю?

Будем полагать Введение почти законченным. Остается лишь обозначить проблему, которую предстоит решить в последующих повествованиях. Трудно придумать что-то, по настоящему действенное, в борьбе со сложностью кроме дискретизации этой самой сложности. В основе Unit tests лежит именно эта идея, как и в книгах по рефакторингу. Забегая вперед, скажу, что для меня лично, тесты не только и не столько средство контроля работы элементарных кусочков кода, хотя в этом их бесспорное достоинство и прямое предназначение. Возможность покрыть, как говорят, тестами значительную часть приложения — свидетельство правильного, хорошо структурированного и достаточно абстрагированного кода. Возможно, и не достаточное условие, но уж совершенно точно — необходимое. Значительное множество прикладных приложений — это UI ориентированные клиенты.  Многолетние исследования в архитектуре программного обеспечения связаны с решением, по сути, всего одной проблемы — отделением логики от отображения. Результатом этих исследований являются три близких подхода: MVC, MVP и MVVM, связанные с трехкомпонентной организацией программы. Логическую часть содержит в себе модель (Model), видимую или коммуникативную — представление (View) и  третью — посредническую часть составляет контроллер (Controller, Presenter, ViewModel).  Все подходы очень похожи, за исключением особенностей последнего, который проистекает из предыдущих двух в свете открывшихся возможностей связывания данных в WPF.

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