Бути суворим чи прагматичним?

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

Але головне питання: як далеко ви можете пройти, не закінчившись у психіатричній лікарні?

Я подаю заявку на нову роботу. Вчора я був з можливим майбутнім роботодавцем, який хотів перевірити свої можливості програмування. Однією з вправ було: поясніть, що робить цей код. Я переглянув якийсь код програми (winforms на vb.net), який вони розробляють (це адміністративна програма для лікарні). Це дало мені можливість реально побачити, як вони підходять до речей, і це було дуже невтішно.

Деякі приклади:

• Я десь побачив: зателефонуйте [тут вставте ім'я підпрограми] -> мене вразило: чи це щось із VB6?
• У них є окремий рівень даних, використовуючи ado.net, але один метод, який мені довелося вивчити, повертає набір даних до викликового рівня. Отож, окремий рівень даних чи ні, додаток прив’язаний до ado.net (що також ніколи не може бути проблемою, якщо вони ніколи не переходять на інший підхід до доступу до даних).
• Цей набір даних читається як є, тому це все ще є орієнтованим на дані підхід (звичайно, можна стверджувати, скільки логіки / поведінки ви можете вкласти в класи типу "Пацієнт" або "LabAnalysisRequest".
• Я також вважаю, що бачив побудову запиту sql шляхом об'єднання рядків.
• Вони використовують збережені процедури (що, на мій погляд, означає: розсіювання логіки)
• немає згадок про погляди / контролери: це все керує формою
• Найпотворніше, що я бачив:

      Якщо TestEnvironment.IsTesting, то
         someVar = [якесь жорстке кодове значення]
      ще
         someVar = [якесь динамічно отримане значення]
      закінчується, якщо
      [залишок функції тут]
  

Все настільки відрізняється від того, що я дізнався в школі: (стійкість агностика) доменний шар, стійкість шару, презентаційний шар, тестування блоку, ...

Тому я перефразовую своє запитання: наскільки фундаментальним чи догматичним він повинен бути? Якою мірою програміст повинен дотримуватися своїх принципів або просто написати код, який виконує завдання?

Я знаю, що не відповідає безпосередньо на ваше запитання, але я все ще вважаю, що це варто більше, ніж коментар:

Коли ви проводите співбесіду на роботі, ви опитуєте їх стільки, скільки вони опитують вас . Порушуйте звичку бачити інтерв'ю як те, на що ви повзаєте на животі, благаючи, щоб вони щось вам запропонували. Вони перевіряють вас, але ви також їх замовляєте. Якщо вони вам не подобаються, вони не наймуть вас. Якщо вони вам не подобаються, не працюйте там.

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

FWIW, я до цих пір (> 10 років у галузі) ніколи не працював у великій компанії з багатьма розробниками (~ 30 розробників було найбільше, десяток - норма), тому що настільки більше шансів, що ти щось зміниш у маленькому компанія. Поки я заробляю достатньо грошей, щоб не голодувати дітьми, я не хотів би бути маленьким зубчастим колесом у великій компанії, де все, що мені потрібно зробити, це синхронізуватися з рештою передач.
Я відхилив пропозиції щодо роботи, побачивши тести, які вони хотіли, щоб я пройшов. Я розробник C ++, і там багато тестів на C ++, які настільки погані, що змушує твої нігті згортатися від огиди, і я не хочу витрачати свій час на боротьбу з вітряками, бо найняли дебілів, які не можуть написати чистий код.
Я також залишив роботу через кілька місяців, тому що їх філософія програмування (короткострокові цілі, неважливо, наступного року) не відповідала моїм здібностям (довгострокова стабільність коду), незважаючи на те, що в інтерв'ю вони сказали різні.

Ніколи не пишіть код, який просто виконує цю роботу. Однак будьте однаково охочі вивчити ваше вчення. Тільки те, що ви дізналися це в школі, не означає, що це сучасне мислення або навіть дійсне мислення. Життєвий цикл розробки програмного забезпечення стає застарілим завдяки програмуванню, що має більш реагувати на діловий світ. Іноді незграбно пов’язані програмні рішення незграбно пов’язані через те, що деталі замінювали у встановлений час.

Ось перелік складених мною питань, які визначатимуть, наскільки добре ви вписуєтесь у спосіб кодування компанії.

1. Скільки вони цінують час відведення рефактора та оновлення своєї бази кодів. Те, як вони бачать оновлення кодової бази, буде головним визначальним фактором того, наскільки добре ви вписуєтесь.
2. Як часто вони купують сторонніх, а не кодують власні.
3. Що вони думають про програмне забезпечення з відкритим кодом. Чи розуміють вони, що вони мають гнучкість у зміні коду. Вони розглядають це так само, як і купівлю третьої сторони.
4. Ви будете працювати над певним шаром абстракції. Чи визначає для вас команда, з якою ви взаємодієте? Який шар / команда / сторона інтерфейсу має більше сили у прийнятті рішень.
5. Скільки спостереження слухають програмісти під час прийняття рішень. Коли програміст кидає червоний прапор, припиняє нагляд і переглядає їх рішення.
6. Чи вважаєте ви керівників досвідченими програмістами? Як вони бачать свій досвід? Чи справедливий їхній досвід? Чи дозволяють застарілий досвід впливати на прийняття рішень?
7. Наскільки липкою є база коду?
8. Як часто вони оновлюють свої засоби програмування (IDE тощо)

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

Догма неминуче порушиться (ми просто не встигнемо оновити X). Однак пріоритети визначатимуть наскільки ви стикаєтесь із їх стилем та прийняттям рішень.

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

Їх самооцінка була помилковою - вони робили дещо незграбний С. Це все ще було дуже функціонально розроблено в природі, і мені довелося піти собі книгу С, щоб навчити себе printf і getf та інші механізми С, яких я ніколи не вивчав. Той факт, що ніхто з команди навіть не зрозумів, наскільки C, як і їх код, вказує на те, наскільки цей знак "C ++" впав. Моєю метою в той час було займатися розробкою ОО, тому це було доброго відсторонення.

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

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

наскільки фундаментальним чи догматичним він повинен бути? Якою мірою програміст повинен дотримуватися своїх принципів або просто написати код, який виконує завдання?

Найголовніше, що тут потрібно пам’ятати, - яке ваше призначення ?

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

Хороший код - це інструмент, який слід застосовувати там, де він дає хорошу рентабельність інвестицій.

Деякі приклади:

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

Підсумок, вам потрібно мати принципи, але ви також повинні бути досить гнучкими, щоб порушувати ці принципи, коли вони приносять більше шкоди, ніж цінності.

Я працював у роздрібній торгівлі електронною комерцією кілька років. Коли я почав там, код для їх внутрішніх додатків був написаний у VB для MS Access, і це було найменше жахливо. У мене була команда з 3 розробників, і протягом наступних кількох років ми замінили це правильними програмами VB.Net.

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

А потім я почав працювати зі своїми хлопцями. Трохи навчання в OOD, в розробці баз даних, в MVC та C #. І з роками все покращувалося. Коли я пішов через 4 роки, база коду все ще була не великою, але це було в 100 разів краще, ніж коли я починав.

Ситуація, подібна до тієї, яку ви описуєте, часто є наслідком того, що потрібно мати справу з наявними ресурсами. Ми не живемо в ідеальному світі. У той же час це чудова можливість насправді змінити значення.

BTW: деякі з цих додатків досі використовуються, практично не змінюючись порівняно з 3 роками тому, і вони все ще заробляють гроші.

Я думаю, що дотримуватися ваших принципів дуже важливо. Ви завжди повинні прагнути створити найкращий можливий код у межах заданих обмежень. Однак якщо ви додасте "ніколи не потрібно читати чи змінювати поганий код" до свого списку принципів, у вас виникнуть багато труднощів у пошуку роботи. Пам'ятайте, що 50% програмістів закінчили нижню половину свого класу. Навіть у команді, яка займається однією людиною, "сьогодні ви" краще кваліфіковані для вирішення проблеми, ніж "ви минулого місяця". Можливість працювати з неідеальним кодом - це лише частина роботи.

Багато роботодавців це визнають, тому код, який вони дають вам прочитати, може бути представником найгіршого коду в їхній кодовій базі, а не найкращим. Якщо це не зрозуміло з контексту, вам слід запитати. У одного колеги, з яким я іноді беруть інтерв'ю, є сторінка коду, яку він навмисно написав погано, щоб використати його як інтерв'ю.

У 99% відсотків випадків ви повинні дотримуватися «догми», як ви її називаєте. Догму складають досвідчені люди протягом багатьох років практики, і те, що здавалося б прагматичним в певний момент, насправді часто не так. Зазвичай це більш актуально, ніж той факт, що ви недостатньо хороші, щоб правильно вирішити цю проблему.

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

Будьте суворі, коли це має значення. Фігурний стиль (або інші умови кодування)? Це не має значення. Використовуйте той, який використовує магазин. Порушення інкапсуляції (або інші основні принципи програмування) без поважних причин? Не так банально.

Stack Exchange використовує таблиці для компонування (як і багато інших основних веб-сайтів, які заробляють гроші ). Це змушує дим виходити з вух пуристів? Звичайно, це так. Але прагматизм кожного разу виграє чистоту. Доставка товару виграє над досягненням його ідеального щоразу.

Весь доменний шар, шар стійкості, презентаційний шар, тестування блоку все ще відносно новий, з історичної точки зору. Існує багато програмного забезпечення, яке все ще використовує модель «Клієнт / Сервер», і воно не буде змінено на найновіший архітектурний стиль лише тому, що воно «краще».