Справжні підводні камені впровадження F # у велику кодову базу та інженерну команду [закрито]

Я CTO програмної фірми з великою існуючою кодовою базою (усі C #) та великою інженерною командою. Я бачу, як певні частини коду було б набагато простіше писати у F #, що призводить до більш швидкого часу розробки, меншої кількості помилок, простіших паралельних реалізацій тощо, в основному загального підвищення продуктивності для моєї команди. Однак я також можу побачити кілька підводних ефектів введення F #, а саме:

1) Усі повинні вивчити F #, і це не так банально, як перехід з, скажімо, Java на C #. Члени команди, які не вивчили F #, не зможуть працювати над F # частинами кодової бази.

2) Наразі придатних програмістів F # на даний момент (грудень 2010 р.) Не існує. Шукайте в різних базах даних резюме інженера-програмного забезпечення для "F #", так як менше 1% резюме містять ключове слово.

3) Підтримка громади на сьогодні (грудень 2010 р.) Є менш доступною. Ви можете google майже будь-яку проблему в C # і знайти когось, хто вже вирішив це, не так, як F #. Підтримка сторонніх інструментів (NUnit, Resharper і т.д.) також є схематичною.

Я усвідомлюю, що це трохи Catch-22, тобто якщо такі люди, як я, не використовують F #, спільнота та інструменти ніколи не реалізуються тощо. Але у мене є компанія, яку потрібно запускати, і я можу бути передовим, але не кровоточивий край.

Якісь інші підводні камені я не розглядаю? Або хтось переймається спростуванням підводних каменів? Я думаю, що це важлива дискусія, і я хотів би почути ваші контр-аргументи на цьому публічному форумі, що може зробити багато для збільшення прийняття F # у галузі.

Пошук резюме для інших функціональних мов, таких як Scheme, Lisp або Haskell. Дуже багато людей навчаються цим у школі та містять їх у своїх резюме; Я впевнений, що багато хто з них не проти вивчити F #. У мене в резюме є схема, хоча я ніколи не користувався нею після школи, і робота, пов’язана з F #, напевно, також приверне мою увагу.

Якісь інші підводні камені я не розглядаю?

На практиці головна помилка, яку я бачу, - це намагання змусити використовувати F # для проблем, коли це неправильний інструмент для роботи.

Або хтось переймається спростуванням підводних каменів?

Вони, очевидно, певною мірою стосуються питань, але я б сумнівався в якій мірі.

Наприклад, ви говорите, що всім доведеться вивчити F #, щоб працювати над F # кодом. Хоча це правда, на практиці це не велика справа. Навчання F # не є більш значущим, ніж навчання WPF, Silverlight або TPL. Я навчаю близько 30 розробників, як користуватися F # для клієнта в Лондоні зараз, і близько десятка працювали повний робочий день над кодом F # лише через кілька тижнів, і вони просто постачали свій перший продукт (вчасно і в бюджеті! ) написано майже повністю у F # через лише кілька місяців. Насправді у них було більше технічних труднощів із Silverlight, ніж F #, і вони виявили, що технічна підтримка Silverlight набагато гірша, ніж для F #.

Ви посилаєтесь на відносно невеликий пул доступних програмістів F #, але, знову ж таки, враховуючи, як легко підібрати F #, я не думаю, що це викликає серйозне занепокоєння. Сумніваюсь, вам потрібно буде найняти багатьох, якщо такі є. У мого клієнта є два хлопці F # для понад 100 програмістів, і наша робота полягає у створенні та нагляді за використанням F #.

Ваше третє і останнє занепокоєння стосується меншої підтримки спільноти, Googling для C # рішень проти F # та підтримки сторонніх інструментів. Знову ж таки, я не вважав це проблематичним на практиці. Я надіслав електронною поштою fsbugs з коментарем щодо одиниць вимірювання у F # та отримав відповідь протягом 24 годин від дослідника, який винайшов його, з детальним поясненням того, чому моє тлумачення було неправильним і чому воно працює так, як це робиться. Я ніколи цього не отримував від Андерса Хейльсберга ;-). Я постійно шукаю рішення в Google і знаходжу їх написаними на C #, VB або навіть IronPython, але за 3 роки використання F # індустрії можу згадати лише один приклад, коли переклад рішення у F # не був тривіальним. Власне кажучи, я нещодавно перетворив зразок C # серіалізатора даних з MSDN в F # і він був на 5 × коротший. Нарешті, ви згадали про підтримку F # в таких інструментах, як NUnit, коли ми Ви користуєтесь NUnit з F # без проблем протягом певного часу. Це інструменти .NET, а не інструменти C #.

Приклад : Мій поточний клієнт не тільки використовує NUnit для тестування одиниць, але й побудував TickSpec у F # на вершині NUnit як технічно чудову альтернативу SpecFlow для BDD. Автор підкреслив, що мені показав, що TickSpec - це крихітна частка розміром SpecFlow і надає більше можливостей. Більше того, кілька розробників, що працюють без попереднього досвіду роботи з F # (і, я вважаю, немає попереднього досвіду функціонального програмування), взяли його та почали використовувати його у непов'язаних проектах без проблем саме тому, що F # + TickSpec полегшує рішення їх проблеми.

FWIW, я дав моєму клієнтові безкоштовну підписку на сайт на наш F # .NET Journal, який добре вийшов з багатьох розробників, які навчаються F #.

HTH!

Як ви визнаєте в першій точці, ваші програмісти, які не знають F #, не можуть працювати в частині F # вашої бази даних. Однак вам не потрібно переписувати всю свою кодову базу в F #, щоб отримати переваги від її використання - просто перепишіть ті частини, де ви побачили б найбільшу користь. Той факт, що F # взаємодіє дійсно добре з C #, повинен зробити відносно легким вирізання певних частин та створення F # збірок з них.

Якби ваші інженери працювали над традиційним трирівневим додатком, ви, ймовірно, не наполягали б на тому, що всі вони потребують глибокого знання SQL, HTML, Javascript, CSS тощо. Натомість ви, природно, працювали б у деяких фахівців в різних частинах програми. Тому я не думаю, що додавання нової мови для однієї частини вашої програми має бути занадто великим перешкодою. Крім того, ви можете використовувати стандарти кодування та інші практики, щоб спробувати переконатися, що ваш F # код читається навіть інженерами без глибокого фону F #.

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

Єдині підводні камені, які я особисто зазнав:

1. Труднощі при налагодженні. Слідом за потоком виконання програми на основі виразів у відладчику, призначеному для мов на основі висловлювань, може бути складно.

2. Розчарування інтелігенції. Автозавершення перестає працювати саме тоді, коли вам це потрібно. Microsoft повинна працювати над тим, щоб зробити аналізатор тла більш стійким до відмов.

3. Синтаксис, що чутливий до відступу, ускладнює копіювання, вставлення або переформатування коду.

4. Відсутність рефакторингу.

5. Деякі з існуючих зручних розширень VS для F # (складання коду, фарбування глибини) трохи повільні, що робить досвід введення тексту трохи засмучуючим.

На мою думку, жодне з цих питань не є зупинками шоу, і я можу поки що жити з ними. Інструменти легше вдосконалити та виправити, ніж мови.

Ваші побоювання, що найняти нових програмістів, здатних писати у F #, буде складно, є досить поширеними, але, на мою думку, невиправданими. Якби ви писали інструкції з кодування, чи порадили б ви заборонити чи заборонити будь-яку з наведених нижче функцій у C #:, yield returnLINQ для об’єктів, лямбда, майбутні async?

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

Якщо ваша команда досить розумна, щоб зрозуміти поняття, які стоять за характеристиками, про які я згадував, у них є все, що потрібно, щоб вони були відмінними програмістами в F #. Те ж саме стосується майбутніх рекрутів: чи найнять ви того, хто не має можливості чи не бажає використовувати функції, запроваджені після C # 1.0?

Я обдумував цю точну ситуацію.

Це те, що я планую для своєї команди:

• Змішайте C # з F #, це можна зробити, використовуючи C # для більшості кодових баз. Там, де потрібна важка обробка даних , запишіть відповідні функції у F # і помістіть її всередині dll або посилайте на неї. Приклад тут

• Повільно переорієнтовуйте існуючу базу кодів вищевказаним способом.

• Не весь код повинен бути функціональним.

• Попросіть свою команду вивчити основи Haskell, LISP у вихідні дні .

• Запропонуйте їм вивчити F #, намагаючись розгадати загадки проекту Euler (це мені дуже допомогло, коли я вивчав F #). Знову ж таки, це слід щось сказати протягом кінця тижня або під час робочого часу, якщо ви хочете відкласти день для "тренувань".

1) Вивчення функціональної мови підвищить загальну здатність когось як програміста, однак це стосується лише тих, хто хоче вчитися та вдосконалюватись. Не кожен програміст хоче стати кращим, а також не хочуть змін у своєму робочому середовищі (знайте вашу команду.)

2) Я не можу з цим посперечатися. Вам доведеться заплатити за 6-місячну криву навчання будь-якої нової мови, однак уже знаючі .net бібліотеки усувають зайві роки, необхідні для вивчення нових бібліотек.

3) Підтримка спільноти, хоча менша за C #, має досить багато висококваліфікованих активних розробників F #, які публікують в Інтернеті. Не забувайте, що підтримка більшості мов - це підтримка бібліотеки, і існує велика підтримка .NET.

Горила на тисячу фунтів тут - це управління ризиками. "Я можу бути ріжучим краєм, але не кровоточити". Я б заперечував, що F # не є кровоточивим краєм. Він був випущений разом з VS2010 і безпосередньо підтримується Microsoft. Кровотеча є "бета" і відмова від Microsoft говорить про те, що ні за що не нести відповідальність.

Як практичного питання, підтримки IntelliSense досить бракує - до того, що підвищення продуктивності виводу типу перевершується менш складним автозаповненням, доступним у C #.

Повідомлення про помилки, спричинені помилковими висновками типу, також потребують більш тривалого виправлення для початківців (а часто для проміжних користувачів, як я), просто тому, що ви менш схильні надавати анотації типу, ніж на такій мові, як C #.

OOP також не вистачає дивовижних способів у F #; наприклад, немає підтримки для вкладених типів / класів. Ви повинні бути обережними при перенесенні коду, оскільки на C # ви можете зробити деякі речі, які ви не можете зробити в F #, на жаль.

І останнє, але не менш важливе, і розмір, і якість спільноти F # начебто невтішні. Багато інформації про F # в Інтернеті є або для старих версій, або просто не дуже гарні - або неідіоматичні, низька продуктивність, або неправильна помилка. Тоді є люди, які стягують величезні гроші за інформаційні бюлетені, які в основному є лише існуючими інформаційними даними.

Я сам використовую C # для робочих проектів і F # для власних речей. Наскільки я люблю F #, на жаль, трохи важко передбачити, як / коли речі можуть розвалитися.

Основна проблема - це завжди ремонтопридатність.

Я хотів би зашифрувати схему, але, можливо, наступний супровідник захотів би полювати на мене і катувати мене.

Я б сказав, що перше, що вам потрібно зробити, - це запитати членів вашої команди, як вони почуваються щодо введення F #. Якщо їм ідея подобається, то все піде набагато гладше, якщо вони цього не роблять.