Чи є мої негативні стажування представниками реального світу? [зачинено]

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

Як результат, я переживаю дві кращі комп'ютерні спеціальності та математику у великому університеті; Я брав участь у кожному класі і обожнював їх усіх, тому хотів би подумати, що мені не страшно в програмуванні. Я проходив стажування в одній з найбільших програмних компаній, і на півдорозі я був шокований надзвичайно низькою якістю коду. Коментарів не існує, це весь код спагетті, і все, що може бути неправильним, ще гірше. Я зробив багато репетиторських занять / TAing, тому я дуже звик читати поганий код, але основні галузеві продукти, які я бачив, що це козир. Я працюю 10-12 годин на день і ніколи не відчуваю, що я кудись дістаюся, бо це " з нескінченними годинами спроб з'ясувати незадокументований API або визначити поведінку якоїсь іншої частини (повністю недокументованого) продукту. Я поки що щодня залишаю роботу, що ненавидить роботу, і я відчайдушно хочу дізнатися, чи є це те, що зберігається протягом усього мого життя.

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

Вони називають це справжнім світом ™ не просто так.

99% того, що ви зіткнетесь у реальному корпоративному світі, вважатимуться лайнами, і це я поясню. 1%, які не вважаються лайнами, з часом перетворяться на лайно.

# 1 Написати код, №2 ????, # 3 Прибуток!

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

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

Теорія 0 - Практика ∞

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

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

У теорії немає різниці між теорією та практикою. На практиці є. - Йогі Берра

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

Фізика життєвого циклу програмного забезпечення

Також у світі програмного забезпечення існує надзвичайно потужна ентропійна сила. Це чорна діра неминучості, яка засуджує все програмне забезпечення перероджуватися у Велику кульку грязі .

Чим далі ви починаєте від BBM, тим краще, але кожна програмна система з часом потрапить туди, даючи достатньо часу. Наскільки швидко ви наближаєтесь до 100% ентропії, визначається з того, з чого ви починаєте і наскільки швидко ви накопичуєте технічну заборгованість і наскільки високі відсотки до неї.

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

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

Good Enough - достатньо добре

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

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

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

Наскільки я знаю, вони не вчать про BBM, я ніколи не стикався з недавнім випускником CS, який знав, що це таке, тим більше чому це відбувається.

Ось чому Good Enough є Good Enough , нічого більш-менш не є.

Програмне забезпечення Slumlords

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

Жоден власник будівлі, лорд-господар або не збирається витрачати гроші на нерухомість лише через деяку академічну концепцію досконалості, яка не означає значного прибутку над пов'язаними з цим витратами.

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

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

Прогноз

Це було зразком протягом 20+ років, я працював у розробці програмного забезпечення. Це не скоро зміниться. Це не так, як люди хочуть, щоб це було поза якоюсь системою переконань, це реальність зовнішніх сил для бізнесу. Бізнес стимулює прийняття рішень, прибуток - це не зло, вони платять вашу зарплату, короткострокове або довгострокове бачення не має значення, це короткострокова галузь постійних змін за визначенням. Той, хто сперечається з достатньою мірою для отримання прибутку , не розуміє бізнесу.

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

Прогрес і надія

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

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

Але Agile не є панацеєю, вона не збирається змінювати фундаментальні закони фізики, і кодові бази будуть гнити незалежно. Керівництво планує розібратися з гниллю, перш ніж воно повністю вийде з-під руки і не може бути керованим.

Agile, коли це зроблено правильно, допомагає керувати ентропією, сповільнювати її, відстежувати, вимірювати та боротися з нею заплановано. Це не зупинить це!

Рішення про кар’єру

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

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

Ні, це не. Це є репрезентативним для вашого рівня кар'єри та досвіду. Це все є частиною вивчення того, як працюють підприємства з точки зору внутрішнього контролю якості.

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

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

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

Те, що я навчився за багато років програмування, - це різниця між "якістю коду" та "прийнятним кодом". Правда полягає в тому, що або хтось із владою знаходить вихідний код у прийнятному стані, або вважає його неприйнятним, але необхідним. Хоча було б добре, якби ми могли все прибрати в проекти, до яких ми беремо участь. Часто не в інтересах та бюджеті бізнесу виділяти ресурси для виконання цієї роботи. Логічні аргументи можна робити, поки сонце не встане на наступний день, чому це було б добре виправити, але коли керівництво вирішило, що поточний стан є "прийнятним", то зробити це можна мало. Це все безпосередньо пов’язано з тим, хто керує речами. Або вони цінують добру внутрішню якість, або ні. Ви чітко це цінуєте, і тому цей поточний стан вас турбує.

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

Бізнес або не хвилює цей додатковий час, або вважає це прийнятним.

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

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

Дозвольте дати вам поради. Хороші розробники знають, коли звернутися за допомогою до своїх наступних товаришів по команді. Не думаю, що відповіді завжди в коді. Я заощадив собі години, просто задавши людям кілька питань. Здається, вам потрібна допомога, яка швидко приходить.

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

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

Ви дуже добре робили в школі, але зараз у вас є стажування, і ви не так добре. Здається, ви вже в реальному світі. Це частина життя. Питання в тому, що ти збираєшся з цим робити? Що мій друг, це єдине, що має значення. Ми не можемо сказати вам, що робити. Ви повинні скласти власну думку.

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

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

Код, який ви бачите, часто проходив через нескінченні ітерації різних програмістів з різними підходами та стандартами та різними умовами іменування тощо тощо.

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

Одне, напевно, термін "хороший код" є занадто суб'єктивним, щоб бути корисним. Звичайно, це не суб'єктивно, ви можете перелічити конкретні причини / предмети. Однак інші люди перелічують різні пункти та пріоритети, деякі навіть не технічні, які вони вважають важливими, і тому це суб'єктивно.

Як і Дрекка, це починає звучати гнітюче, тому дозвольте спробувати перетворити трохи позитивніше, адже це, безумовно, вірно:

• Існують організації, найчастіше - це найбільші технічні компоненти, які роблять правильні речі.
• Нова компанія ... і код ... прибиральник він має тенденцію бути. спагеті росте завдяки часу та людям.
• Деякі люди роблять TDD і BDD, інші - ні. Асортимент величезний.
• Приблизно через 10 років зараз вся технологічна база змінюється, тому тим, хто залишається в галузі, може бути не так вже й важко, як і новачкам.

Нарешті, як зазначає Ентоні Блейк, завжди є 3 фактори - час, вартість та якість.
Мені подобається споріднений вираз: "вибрати 2" !

З цього приводу існує багато думок, тому що досвід кожного різний.

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

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

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

Справжньою хитрістю в поводженні з поганим кодом є з'ясування того, що врятувати, а що ні. Це випливає з досвіду та досліджень.

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

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

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

Тут є декілька чудових відповідей, але дозвольте додати трохи;

Ласкаво просимо в реальний світ - на жаль, це дуже часто.

Дивіться схему нижче;

За допомогою корпоративного програмного забезпечення ви можете вибрати лише 2 або вищезгадані, і ви повинні пожертвувати одним.

Як ви, здається, виявили, більшість корпоративного світу йдуть зі швидкістю та ціною.

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

Щоб підбити підсумки, помітьте знаки казки;

• Хто керує компанією? Це єдиний менеджер, маркетингова команда (якщо так, тримайтеся подалі), команда розробників тощо. Цей кут означає, що ви можете отримати більше чи менше важелів для проектів, часу, витраченого на проекти тощо.
• Чи є технічна оцінка? Подивіться, як керівництво, керівник та члени команди ставляться один до одного. Я був в інтерв'ю, де менеджери робили всілякі рухи брів, як тільки технічна ведуча почала виступати. Після цього та навчання, вони не використовували управління джерелами - ви не змогли показати мені двері досить швидко.
• Ділова мета? Чи живе компанія щодня, як у щоденних фінансових цілях, чи має довгостроковий план, до якого ви входите. Розробка програмного забезпечення, як правило, проводиться протягом кількох місяців, тому наявність компанії з шизофренічним характером зазвичай призводить до безладного програмного забезпечення.
• Сильно копайтеся - коли задаєте технічні запитання і дивіться, чи люди переміщаються. Контроль над джерелами, контроль над документами, процес випуску, звіти про помилки, стиль управління, T&C тощо

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

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

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

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

Я вчора думав про цей один проект. Для мене це була така очевидна мрія, що я відкинув справді мінімально функціональний шматок лайна у двері. Я розглядав це як марну часу та ресурсів.

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

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

Це підводить нас до моєї остаточної точки. Навіть якщо ви робите щось чудодійне, той факт, що він працює так добре, означає, що НІКОЛИЙ не буде з ним хоча б трохи знайомий, і коли це зламається (як правило, тому, що вони зробили щось дурне), то вони будуть проклинати ваше ім'я гірше, ніж вони коли-небудь проклинати того ідіота, який написав те, що ламається кожного третього вівторка.

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

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

Я не працюю 30+ років у цій галузі, але я побачив достатньо, щоб сказати кілька речей. Проект має майже все життя, як людський. Початковий проект може не відповідати поточним потребам, наприклад, одного проекту після 20 років розробки. Це було сказано за той час, що багато людей змінили код, зіпсований з ним, і додали речі, які спочатку не мали бути можливими.

Не дуже важко уявити потворний код на застарілих проектах або на досить старих проектах. Ми не можемо очікувати, що всі повністю зрозуміють початкові проекти. Це сумно, але так воно і є.

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

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

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

Якщо ви закінчите рефакторинг проекту, ви можете стати людиною, на яку вказували погані варіанти дизайну! І тоді ви можете зрозуміти, чому рефакторинг трапляється не так часто. Будемо сподіватися, що якщо всій команді доведеться рефактор, то ніхто не звернеться до неї. Вони просто звільнять усіх =)

Я б спробував підсумувати відповідь на це питання простою цитатою:

All code turns to crap given enough time and hands.

Решта - це лише історії ...

Якість коду в основному залежить від двох факторів.

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

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

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

Ласкаво просимо до коду з бюджетом! Існує велика різниця, коли розвиток підштовхується управлінням, щоб зробити це занадто рано, без планування та з вирізанням кутів. У мене був подібний досвід справжнього світового шоку, коли я першу роботу з програмування закінчив у коледжі. Жодної документації! З часом я навчився багато часу, написання та оновлення офіційної документації - це лише марна трата часу. На щастя для мене, це була приголомшлива команда. Очолив його хлопець, який знав, що робить, а інші члени команди дійсно піклувалися про те, щоб правильно писати код. Відтоді мій досвід був подібний до вашого. Дуже багато жахливого коду, багато поганого коду, багато незрозумілих "розробників". Для кожного хорошого розробника, здається, є 100 поганих.

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

Я пройшов стажування в одній з найбільших програмних компаній

Не всі компанії однакові. У більшості компаній ви знайдете шалених команд і баз кодів програмного забезпечення. Але ви також можете знайти чудові команди та чудові кодові бази.

Я думаю, хлопці в Solaris зробили дуже хороший і чесний опис того, який тип баз коду ви знайдете у великих компаніях: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

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

Ні, я кодую більше 15 років і все ще люблю це.

Це не означає, що все було ідеально. Я бачив деякі жахливі бази коду, а також деякі чудові. Хитрість полягає в тому, щоб знайти потрібне місце для вас.

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

Удачі!

Я бачив подібні речі, як і ти. У мене є два досвід випадків, коли це відбувається.

1. Коли розробка занадто орієнтована на проект. Єдине, що важливо - це надати функціональність вчасно, а потім вийти. Наступну зміну здійснить хтось інший, інша команда / керівник проекту з новим бюджетом.
2. Коли частину програмного забезпечення підтримує лише кілька людей протягом тривалого часу, розробники, як правило, лінуються, оскільки вони так чи інакше знають свою програму. Академічні принципи далеко.

Це сумно, але саме так в деяких місцях.

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

Це буде коротка відповідь.

Освіта дуже корисна для того, щоб почувати себе кваліфікованим та ідеалістичним. Це гарна річ, і ви повинні намагатися триматися за ідеалізм.

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

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

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

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

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

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

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

І звичайно, працюючи з більш популярними корпоративними інструментами, ви збираєтеся виявити, що середній рівень талантів буде досить крихким. Якщо ваші основні навички - це комбінація Java та C #, розширіть свій кругозір. Ви можете знайти щасливішу нішу на написанні середнього рівня Erlang або Python або: o JavaScript.

І не дозволяйте нікому розповідати вам щось інше. У вас може не бути вибору в питанні, як діяти, але лайний код! @ # $ Ing дорогий.

Ваше питання було зосереджено на стажуванні. У мене ніколи не було програмування, але я стажувався на радіостанції, не дуже застосовної тут.

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

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

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

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

Удачі.