Чи шкодить використання нових методик продуктивності? [зачинено]

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

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

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

Отже, є така напруга: "зроби це правильно" проти "зробити роботу гідно ".

Це щось трапляється з багатьма розробниками? Це відома конкретна проблема? (Зрештою, це реальна проблема?) Чи це насправді пов'язане зі збільшенням рівня досвіду?

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

Часто ризикувати спробувати нові речі. Іноді ми потрапляємо в біду, тому що прагнемо робити дві речі:

1. Переоцініть, наскільки корисна прикольна / нова / примхлива річ. Ми бачимо класний приклад, якийсь код, викинутий в Інтернеті. Дуже класно, ми думаємо. Дуже круто! У XI можна виконати завдання Y в десять разів швидше. Його явно перевершує. Ми ще не бачимо всіх "невідомих невідомих". Нас не зіткнулися з проблемами, про які пропускають продавці нової речі. Ми не маємо достатньо досвіду в новій справі, щоб побачити міни, що чекають на дорозі.

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

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

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

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

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

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

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

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

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

Ось деякі деталі:

1. Існують терміни : програміст повинен заздалегідь мати всі необхідні подробиці інструментів, які він використовує. Читати якийсь веб-сайт, знаходити якусь цікаву річ, а потім використовувати її у виробничих умовах - це велика ні-ні. Ви просто не маєте достатнього досвіду роботи з інструментом, і що ще важливіше, у вас просто немає необхідного часу, щоб почати вивчати щось нове. Якщо ви хочете отримати якісь нові цікаві речі, вивчіть це за півроку чи року, перш ніж використовувати.
2. Переконайтесь, що ви це правильно знаєте, перш ніж використовувати його : Деякі приємний новий інструмент може бути цікавим у використанні, але гуглінг за рішеннями, а потім їх використання без належного вивчення може бути дуже поганим. Вам просто не вистачає досвіду з цим. Якщо вам потрібно було погуглювати його, щоб розібратися, це означає, що ви просто не знаєте його досить добре, щоб виправити це, коли він зламає половину системи.
3. Використання найновіших матеріалів не робить це належним чином : нові речі не є перевіреними технологіями. Наступного року технології, ймовірно, повністю зникли, ви єдиний у світі вже використовуєте її. Всі інші помітили, що це просто не працює. Потрібна копітка робота, щоб уникнути новітньої срібної кулі, але вона того варта.
4. Зосередьтеся на методах, які є вашими основними знаннями : кожен програміст знає лише невелику частину всіх знань з програмування, наявних у світі. Частина, де програмісту досить зручно користуватися ним, ще менше. Частина, яка насправді працює, ще менша. Використовуйте лише ті знання, які ви правильно засвоїли, і ви знаєте, що це працює. Це робить вас швидшим програмістом і призводить до кращого коду.
5. Не налаштовуйте його нескінченно : Ідеальний код - це добра ціль, але це не означає, що ви спочатку напишіть якесь лайно, а потім нескінченно налаштувати його, щоб зробити його поступово кращим. Напишіть це ідеально з першого разу, використовуючи всі хороші знання, які ви маєте. Довіряй собі. Не довіряйте світові. Ніхто інший не знає точно таких же речей, що і ви. Їх думка не має значення. Ви програміст, вам потрібно змусити його працювати. Світ не може зробити це за вас. Як тільки це буде зроблено, зупиніться. Не чіпайте його, поки хтось не скаржиться на це.
6. Приділіть час для вивчення нових речей : Кожному потрібно постійно вчитися новому. Від цього залежить наше майбутнє. Просто відмовтеся від його використання! Вивчайте нові речі, але не використовуйте їх, поки ви не переконаєтесь, що це насправді працює. Ви отримаєте шанс скористатися ним наступного року, як тільки це буде перевірено технологією. Або ви просто забули це, як і всі - залишається лише гарний матеріал ...
7. Не втрачайте хороших речей : Після того, як ви успішно побудували великі системи і вирішили всі проблеми в них, і засвоїли деякі приємні методи, найгірше, що ви можете зробити, - це просто скинути ці знання і піти на щось нове. Ви вже знаєте, як це працює, які проблеми є і як їх вирішити. Викинути його - це лише марна трата часу.
8. Будьте в курсі нових технологій : одна з нових систем буде успішною. У ньому є щось принципово краще, ніж будь-що інше на ринку. Ви просто не знаєте, яка з них - срібна куля. Якщо ви не зможете його знайти вчасно, ваші знання будуть застарілими. Світ може змусити вас втратити всі хороші речі, видаливши доступ до старих систем.

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

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

Так, нові речі шкодять продуктивності

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

Ні, нові методи можуть підвищити продуктивність

Будь-яка нова техніка, яка дозволяє простіше висловити рішення, підвищить вашу продуктивність. Це може бути таким же простим, як перехід від великих if-elseifумов до відправної таблиці.

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

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

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

Не забувайте також, що часто зробити це гідно виконано з наявними інструментами - це краще рішення, ніж введення нових речей. Щоразу, коли ви додаєте нові, ви збільшуєте необхідну поверхню обслуговування, що, в свою чергу, сповільнює всіх інших (і може зробіть свій код досить безладним - я думаю про шари «нового» технології, які з часом перейшли у спадщину, але все ще в нашому коді роблять речі жахливими. Озираючись назад, було б краще просто використати старі способи С замість того, щоб додавати все це COM і все те, що VB, і все це. NET, а тепер і лопата HTML в нього)