Куди ж податися, у Java чи у .NET?

На днях сталося дві події. Я начитався Парнаса (David Parnas) і знову стикнувся з класичною ситуацією, коли студент стоїть перед вибором куди ж податися? Чи то у Java чи то у .NET, а може у PHP? Цього разу на форумі і студент зовсім не мій. Я знаю скільки на ці пошуки витрачається дорогоцінної молодої енергії, тому вирішив розписати суть проблеми, застосовуючи мої улюблені аналогії. Сподіваюся ця аналогія, хоча трішечки різкувата, але допоможе розібратися.
Для початку декілька загальних слів про те, хто ж такий інженер. Інженер загалом займається тим, що змінює навколишній світ, створюючи і підтримуючи продукти, які до того не існували. Для створення продуктів інженер застосовує наукові знання, математику, практичний досвід (можна ще додати економічні та соціальні аспекти, особливо у програмній інженерії). Саме використанням наукових знань та математики інженер відрізняється від техніка. На відміну від науковця, який добуває знання, інженер творить, проектує і доводить, що те, що він спроектував буде працювати як слід, покращить суспільне життя і буде безпечним у всіх відношеннях. Для роботи інженер може обирати та використовувати різноманітні інструменти.
Приблизно таке міркує собі пересічний студент (це не вигадка, цитата з форуму, що там казати, я зовсім недавно так само розмірковував).

Итак 19 лет, студент 3его курса! По сути дела на данном этапе знаю нормально С\С++ прошло 1.5 года любви с ним с момента написания cout<<"Wake Up, Neo..."; сидеть еще 2 года на учебе понта не вижу... В голове мысль надо работать, делать опыт, делать деньги... на 4ом .NET от А до Я а на 5ом Java и PHP ну это к слову! Итак... Меня терзает мысли о том что быть человеком оркестром не хорошо, и быть про во всем тоже! Так как это не возможно, а лучше выбрать одну ветку это или .NET или Java или PHP или ЯблоДевелопер ! По сути дела больше тянет в .NET так как понравилася C# и испытываю симпатию к продуктам Microsoft (это не сарказм) а также тянет в Яблочную сторону но как бы денег не хватает чтобы купить макбук + девайс на iOS =) Java смотрел по Шилдту тоже неплохо но немного напрягает (я думаю с не привычки) linux-based системы и все такое, я как бы осознаю что Java это чистый Enterprice и ничего более , то есть если бы не было J2EE она бы сдохла давненько или осталась в разделе тупенькие приложение для мобилок на J2ME это сугубо мое мнение оно может быть не верным... PHP тоже неплох, но мну бесит HTML CSS то есть для меня радость занимать себя чисто программированием а не всякими разметками и т.д. Опять же более тянет в .NET или apple ... и если посмотреть на такие сайты как work.ua или trud.ua или rabota.ua (я сам в Днепре) то могу увидеть что больше всего требуется PHP потом Java потом .NET потом Apple ... И когда я на work.ua фильтровал по окладам выше 15к гривасов PHP — 2 Java — 3 .NET — null ! Я подумал странно! Ведь на прошлом опросе зарплат на ДОУ четко было видно рулит .NET и Java и по кол-ву работы и по размеру оклада... Вот я сейчас смотрю на work.uaPHP — 76 вакансий Java — 58 .NET — 16 ! Я как бы в курсе что судить по вакансиям не имеет смысла так как многие вакансии стоят тупо для вида не понятно почему! Но я не знаю откуда мне взять данные о том что же в спросе как говоритЦо! Перечитавшись топиков на форумах я стал выкупать что люди валят с PHP на Java да и многие студенты вроде меня видят свое будущее в Java! Если законы физики никто не отменял можно предположить что Java программистов будет океан а это плохо для джавистов... и тут я все больше плюсую .NET…

А тепер уявімо собі юного радіоінженера, що навчається у супер радіо-академії ШАГ. Подивимося, що ж він собі міркує.

Гаразд, я вже навчився штрикати кнопки на вольтметрі «С++», якого вже 1.5 років кохаю до нестями з того моменту як вперше в нього запхав батарейки. Я не знаю ні теорії електронного обладнання, я не знаю принципів побудови приймачів та передавачів, ні статистичної радіотехніки, ні перетворення Фурьє, ні спектрального аналізу, ні математичного аналізу, ледве можу взяти інтеграл, і щось віддалено чув про закон Ома. Відчуваю себе зле при розмовах про розрахунки електромагнітного поля та рівняння Максвела. Проте ще 2 роки сидіти на навчанні не бачу понту, я ж навчився користуватися цим супер вольтметром! Треба йти заробляти гроші, набувати ще крутішого досвіду штрикання кнопок на вольтметрі, можливо навіть навчусь приєднувати нові детальки до нього! Думаючи про це, я купив собі ще два вольтметра, один «С#» а інший «Java». Трохи навчився й на них штрикати кнопки. Але після цього мене почала доводити до сказу думка, що професійно вміти користуватися усіма цими вольтметрами не є добре та й неможливо, бо вони мають забагато деталей і режимів роботи. Тому треба вивчити один з них у всіх деталях, але який!? Взагалі то мені подобається «С#», він такий ошатний, кнопочки гарно натискаються і напис на ньому аж лисніть: Microsoft! Що за пречудова фірма… Вона ще крім того робить казкові унітази і зубну пасту! Як мені подобається ними користуватись. Тому саме вольтметр «С#» та мотлох, який необхідний щоб він працював я вивчити хотів би від А до Я. І то нічого що читати технічну документацію до нього я не можу англійською, тому купую за скажені гроші привезені з сусідньої держави, як попало перекладені (живу я в колонії, переклад мовою монополії) застарілі книжечки і читаю. Щоправда є ще один вольтметр – «МАК». Тай гарний же! Однак дорогий, купити не можу, тому не вивчатиму. Дивився до «Java». Що сказати – слабенько, слабенько. Не знаю чому, чи нема напису Microsoft, чи кнопок малувато. Ще є непоганий «ПХП», але мене дратують амперметри. Бо мені втішно напругу міряти, а не усілякі там струми! Фі! Знову ж таки тягне до Microsoft чи Яблука, там усе таке гарне та симпатичне, а який професійний маркетинг (ковтає слину і мрійливо посміхається). Полазив по сайтам робіт, а там чомусь більше потрібні такі, що вміють штрикати кнопки на «ПХП»… Дивні речі якійсь кояться. Чорт голову зломить в цих вольтметрах! Їх так багато, там їх використовують, там – ні! От лихо! Аби ж то усі використовували один амперметр! Тоді б я його зубрив би до посиніння, а потім напевно нарубав би грошей величезну купу. А так все це доводить мене до сказу! Та ще й викладачі днями вчать штрикати кнопки на вольтметрах і хоч би хто щось порадив! Вони ж такі досвідчені штрикальники! Полазив по форумах багато студентів типу мене бачать своє майбутнє у вольтметрі «Java». Але згідно з законами фізики, що я їх в школі сумлінно вивчав, якщо багато штрикатимуть кнопки на вольтметрі «Java», то тим, хто їх штрика на «C#» буде краще. От трясця, що ж його робити?!

У чому ж тут мораль? А в тому, що студент-радіоінженер так ніколи не думає, адже це є абсурдним для нього! (я був таким студентом і прекрасно знаю чим їх голови забиті у 19 років). Чому ж інженер-програміст мучиться у таких роздумах? Думаю це окрема тема для палкої дискусії. Тут я лишень хочу дати свої скромні поради, навіяні Парнасом.

Вивчайте англійську мову і читайте оригінальні свіжі статті та книжки з програмної інженерії. Вивчайте наукові основи програмної інженерії, комп’ютерних наук (в меншій мірі, тут без фанатизму, лише речі для побудови програм, типу основи мов програмування, а не завороти штучного інтелекту) та практики, які гарно себе зарекомендували. Вивчайте дискретну математику (заспокойтесь, не усе підряд, а ті розділи, які застосовуються у серйозних програмних проектах, а що саме застосовують і як – це предмет Вашого дослідження). Вчіться якісно будувати програмне забезпечення, аналізувати та тестувати його. Саме БУДУВАТИ, СТВОРЮВАТИ. Оберіть відкритий проект, або почніть самі з друзями. Починайте його робити, застосовуючи те, що чого навчилися! Проблема постане у виборі інструментів (не тільки мови, а й систем командної розробки, збирання, моделювання, тестування, реструктуризації, компілятори та інфраструктурні речі, типу БД чи операційної системи). Спокійно сядьте і напишіть набір критеріїв які важливі з економічної, соціальної, технічної точки зору. Абсолютно чітко і строго. Складіть список кандидатів і на основі критеріїв зробіть висновок. Наприклад, якщо критерій навчитися застосовувати об’єкти – ПХП тут ні до чого. Якщо замикання – Жава ні до чого. Якщо нема наслідуваних систем і однорідна платформа Windows, треба обирати .NET, але якщо потрібна потужнна безкоштовна система реструктуризації коду – VisualStudio не допоможе. Робіть ваші висновки НАУКОВО (не маркетинго, не емоційно, ні товаришозапивно, ні форумно) обґрунтованими.

Конкретний інструмент ви швидко освоюєте, не поспішайте так до них. Наполегливий народ за 3 роки стає лідерами команд. Це не ракетна наука. Зате ті 2 роки навчання, проведені правильно, дадуть вам поштовх і імпульс стати інженерами а не техніками. Це щось типу довгострокових інвестицій. Одразу одні витрати, а далеко пізніше результат. Якщо не інвестуватимете – нічого не отримаєте, і все професійне життя труситиметесь, а що, якщо завтра моя компанія раптом спише той вольтметрик, що я на ньому так звик клацати, що я робитиму?

Канапа і модуляризація

На днях мені привезли нову канапу, однак на тому місці, де її необхідно було поставити, стояла величезна кутова стара канапа. Я був вдома геть один, а місце звільнити треба було. Ось таке собі завдання: винести стару канапу у іншу кімнату. Вона мало того, що важка, що не підняти, так ще й велика, що в одвірок ніяк не протиснеш! Але я із завданням успішно впорався. Стара канапа була МОДУЛЬНОЮ, тому необхідно було лише від'єднати модулі один від одного та винести кожен окремо (навіть по одному підняти і протиснути модуль було неабияк важко, однак можливо). Хоча ця історія банальна, та вона була прекрасним наглядним прикладом застосування принципу "розділяй та володарюй", і його окремого випадку - "модуляризація". Мені дуже подобаються аналогії у процесі пізнання, тому впоравшись із завданням я усвідомив, що це пречудова аналогія модуляризації у програмному забезпеченні та інших продуктах. Хоча інструмент модуляризації не завжди існував, ми часто його сприймаємо як щось невід'ємне, тому неправильно розуміємо його суть, неправильно його застосовуємо. Це особливо стосується студентів. Тож згадаймо канапу наступного разу, коли намагатимемося пояснити студенту/джуніору принцип модульності, або зловимо себе на думці, що завдання під рукою не підйомне та страшенно заплутане (така згадка може привести на канапу і занурити в сон, ну і нехай!).

Чи унікальність компонентів ПЗ є причиною його складності?

Я часто на своїх лекціях розповідаю студентам, що програмне забезпечення є найскладнішим інженерним творінням людини. Я, звісно, досі у цьому переконаний, але після декількох тривалих дискусій зі своїм студентом-дипломником похитнувся мій основний аргумент: у програмного забезпечення усі компоненти унікальні. Я завзято пояснював, що якщо з'являються два однакові шматки коду, то їх виносять у окрему підпрограму, залишаючи тільки виклик на старому місці. У той час електричний ланцюг може складатися з багатьох компонентів, що мають однакову функціональність: транзистори, резистори, конденсатори. Але чи доцільна така аналогія? Мабуть, коли мова заходить про компонент та про екземпляр компонента, це майже у всіх викликає замішання. І тут порівняння підпрограми з транзистором вкрай невдале, тому, що підпрограма є компонентом,  а ось транзистор у мікросхемі є екземпляром компонента. Навряд чи хтось прагнутиме дублювати специфікацію транзистора, яка репрезентує абстрактне поняття компонента-транзистора. В свою чергу підпрограма багато разів ініціюється комп'ютером, який в залежності від виконуваної підпрограми-специфікації "прикидається" різними екземплярами компонентів. Насмілюся  зробити висновок, що самі по собі компоненти унікальні в усіх інженерних галузях. Напевно замість згаданого аргументу слід говорити про те, що компонентів ("класів" компонентів) у програмному забезпеченні набагато більше ніж у інших творіннях людини, плюс до всього, кожен екземпляр компоненту може бути у величезній кількості станів. Можна сказати, що транзистор, у принципі, може знаходитись взагалі у нескінченній кількості станів, проте вони обумовлені законами фізики, а стани програмного забезпечення цілком визначають люди. А це вкрай складно.

Комплекс меншовартості

Цікаво спостерігати за українцями. Переважна більшість із них зневажають/не сприймають/не люблять/байдужі до усього українського: мови, культури, історії, символіки, ба навіть товарів та послуг, що в Україні вироблено. В результаті створювати якісний український продукт нікому. Тай й на виборах народ голосує за антиукраїнські політичні сили. Так і живемо у невизначеності: чи то ми європейська незалежна і успішна країна, чи то російська колонія, частина русского міра, безправна, корумпована, визискувана й злиденна. Просто дивовижно, що люди не усвідомлюють того, що ця країна побудована навколо національної ідеї. Тож зневага до цієї ідеї неминуче веде до краху цієї держави. Більшість щиро дивується, до чого тут мова, аби їсти було що! Та ні, усе складніше, набагато складніше. До прикладу, аби схід гарячкувато не голосував за російську мову, ми б не мали президентом пана Януковича, з усіма наслідками. Схоже, що ця нелюбов та зневага до українського і є проявом того комплексу меншовартості та колоніальної свідомості. Я працюю в університеті, бачу багато молодих людей, навіть юних, і їх уже пронизує цей комплекс. Тож марно сподіватися, що цей комплекс зникне сам собою з часом. Доки є імперіалістична Росія вона буде, спільно з нашими місцевими холуями, перетворювати наш народ і нашу націю у біомасу, її простіше визискувати. Тож, на мою думку, вільну і процвітаючу країну ми зможемо побудувати лише у щоденній боротьбі з комплексом меншовартості.

Чи є майбутнє у керованої моделлю розробки програмного забезпечення

Давненько не писав. Часто виникає бажання щось написати, але потім якось руки не доходять. Аж раптом нещодавно трапилась мені на очі презентація шановного Джона ден Хаана під назвою «Чому у керованої моделлю розробки програмного забезпечення немає майбутнього» (Why there is no future for model driven development).  Оскільки я палкий прихильник розробки програмного забезпечення, керованої моделлю, не можу не відреагувати. Свою думку я йому коротко висловив на сайті, а тепер вирішив трохи детальніше розміркувати.

Почнімо з визначення. Отже розробка програмного забезпечення, керована моделлю (РКМ) – це методологія розробки програмного забезпечення (ПЗ), що спрямована на використання моделей ПЗ як основних продуктів розробки та генерування на їх основі інших робочих продуктів, у тому числі і вихідного коду, наприклад на Java або C++. Як і більшість понять у галузі ПЗ, це поняття запозичене із більш традиційних інженерних дисциплін, хоча там на керованості моделлю так явно не наголошують, оскільки використання моделей є загальноприйнятим. Ніхто навіть і уявити собі не може конструювання такої будівлі як Московський Міст у Києві чи літак «Мрія» без попередньої побудови великої кількості різноманітних спеціалізованих моделей. Моделі допомагають зрозуміти складні завдання та їх потенційні розв’язки через абстракцію. Однак у галузі розробки ПЗ моделювання аж ніяк не набуло широкого впровадження. Не будемо тут намагатися аналізувати причини, це тема окремого посту, а перейдемо відразу до демонстрації того, що РКМ має майбутнє.

Не вдаючись до історії постійного підвищення рівня абстракції мов програмування, відразу перерахуємо фундаментальні принципи програмної інженерії та покажемо як РКМ відповідає цим принципам: строгість та формальність, розділення відповідальності, модульність, абстракція, передбачення змін.   

Строгість та формальність. Розробка програмного забезпечення є творчою діяльністю. У будь якій творчій діяльності є схильність до неточності. Строгість та формальність необхідне доповнення будь-якої інженерної діяльності. Тільки так можливо контролювати вартість та якість продуктів на виході такої діяльності. Моделювання ПЗ, використовуючи формальні мови, зі строго заданими синтаксисом та семантикою безумовно відповідає цьому принципу. Звісно, тут не йдеться про архітектуру, намальовану маркером на дошці, така модель корисна хіба що для обговорення проектних рішень.

Розділення відповідальності. Один з найголовніших принципів інженерії взагалі та інженерії ПЗ зокрема. Розділення відповідальності - це спрощення єдиного монолітного розв’язання завдання шляхом поділу на взаємодіючі розв’язання під-завдань. Моделювання різних аспектів ПЗ, таких як бізнес-логіка або архітектура, за допомогою різних, предметно-орієнтованих мов програмування (DSLs) є реалізацією цього принципу. Особливу вагу для бізнесу мають предметно-орієнтовані мови, призначені для опису конкретної галузі в якій працюватиме застосування. Наприклад, мови для опису управляння страховими полісами, бізнес процесів, алгоритмів розрахунку статистики успішності студентів і т.д. Програму, написану такою мовою зможе читати бізнес експерт, а програму мовою Java – ні.

Модульність. Цей принцип є окремим випадком попереднього. Суть його полягає у розбитті системи на простіші частини, що називаються модулями, компонентами, сервісами і т.д. Перераховані назви є, безумовно, абстракціями, створеними для реалізації принципу модульності. Однак ми не обмежені лише цими абстракціями у побудові ПЗ! Ми можемо послуговуватися, формально визначивши, такими абстракціями як компонент, процес, замикання, виключення, повідомлення, синхронізація, з’єднувач, двигун, крило літака, контролер, гамбургер, страховий поліс, множина яких обмежена лише нашою фантазією! Усі вони є частинками певного застосування, а моделювання ПЗ з їх використанням є реалізацією принципу модульності.

Абстракція. Принцип не потребує коментування. Відзначимо, що усе ПЗ є абстракцією. Абстракція дозволяє нам створювати складні системи. Абстракція подарувала нам поняття класу, об’єкту, події, функції, бібліотеки, тощо. Розробка ПЗ є складною. ПЗ є найскладнішим продуктом, що створює людина. Якщо задатися запитанням: а скільки інженерів-механіків я знаю? А скільки інженерів програмістів? Думаю, останніх у декілька разів більше. Гадаю, саме робота на надто низькому рівні абстракції змушує компанії наймати усе більше інженерів з ПЗ та виставляти захмарні ціни за розроблення та супроводження ПЗ. РКМ дає можливість підвищувати рівень абстракції та створювати нові абстракції, що краще відповідають потребам зацікавлених у розробці сторін.

Передбачення змін наголошує на тому, що необхідно передбачати та створювати зручні умови для внесення змін у ПЗ. Як правило, реалізацію цього принципу забезпечують модульність та розділення відповідальності. Якщо різні аспекти системи модельовані окремо, то можна легко змінювати окремо від інших аспектів бізнес-логіку, архітектуру, базову абстрактну машину (мови програмування, операційні системи, проміжне ПЗ, бази даних, тощо). Тобто РКМ надає інструменти для ефективної реалізації принципу передбачення змін.

Звісно, РКМ не є срібною кулею, гадаю такої кулі не буде винайдено. Однак, на мою думку, це закономірний рух уперед і дозрівання розробки програмного забезпечення до інженерної дисципліни. Автор коментованої доповіді відзначив, що моделювання має стосуватися не лише конструювання ПЗ, а й інших фаз розробки, особливо збору вимог, та розгортання. З цим важко не погодитися, тому правильніший термін був би не розробка, керована моделлю, а інженерія ПЗ, керована моделлю. Аби така інженерія стала реальністю, необхідно ще дуже багато наукових досліджень та практичної роботи.

Отже, чи є майбутнє у інженерії ПЗ, керованої моделлю? Судячи з усього так, інакше немає майбутнього у ПЗ як такого.

Як стати успішним архітектором програмного забезпечення

Молоді спеціалісти, в тому числі і я, часто захоплюються різними титулами, хочуть ці титули мати. Титул, чи посада "Архітектор ПЗ" є особливо омріяною. Хоча я не думаю, що архітектором буди краще чи престижніше, ніж кодувальником чи тестувальником, все ж архітектура є для мене найцікавішою галуззю знань в програмній інженерії. Однак чи ж інженерією є розроблення програмного забезпечення? Кількість дискусій на дану тему зростає, що змушує задуматися. Погляньте лише на розмах маніфесту програмних ремісників. І якщо інженерія програмного забезпечення не інженерія, то архітектуру освоїти з книжок або в університеті неможливо... З цього приводу хочу навести уривок з інтерв'ю Франка Бушмана (програмного інженера з Siemens) для Software Engineering Radio (епізод 54).

Міхаель: Як людина може стати успішним архітектором?

Франк: Тут я процитую свого наставника: нехай працюють над складними проблемами. Не починайте навчати програмній інженерії, або програмній архітектурі використовуючи маленькі приклади (завдання). Студент або початківець може вирішити їх за допомогою будь-якої технології, а тому не побачить їх переваг та недоліків. Але якщо студент працює над складними проблемами, які важко розв'язати, він в результаті може усвідомити переваги та внесок різних технологій. А ще практика, практика, практика, практика... Я розглядаю інженерію програмного забезпечення не як інженерну дисципліну, і навіть не як мистецтво, а як ремесло. А ремісник потребує практичного досвіду (очевидно, що передається від майстра до учня, який спостерігає за тим, як працює майстер та допомагає йому) та дискусій з іншими ремісниками.

Однак хіба усі сучасні 100% інженерні дисципліни (наприклад, електрика, механіка) відразу були інженеріями? Хоча практика, практика, практика - це, безперечно, дуже важливо,  стати успішним архітектором без серйозної теоретичної підготовки, на мій погляд, дуже складно, адже накопичених важливих знань з архітектури програмного забезпечення сьогодні дуже і дуже багато.