Як стати "швидшим" ​​програмістом?

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

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

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

Будь-який відгук дуже вдячний, дякую,

Вимкніть комп’ютер. Візьміть олівець і трохи паперу. Накресліть свій дизайн. Перегляньте це з однолітками. Потім напишіть код.

Деякі ідеї ...

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

Ваше бажання бути "швидшим" ​​програмістом саме по собі похвально. Однак не доставити вчасно не означає, що ви повільні, це означає, що проект був запланований погано. Бути «швидшим» програмістом не допоможе; це просто означає, що ти швидше пройдеш цей термін.

Ви (та ваша команда) ви робите одну з наступних помилок (або всіх):

• недооцінка роботи, яку потрібно виконати;
• відсутня велика вимога або фрагмент архітектури під час планування;
• плутати кошториси роботи з календарними кошторисами та не враховувати такі речі, як зустрічі / телефон / інші накладні витрати;

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

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

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

"Хтось має поради чи поради щодо того, що вони роблять, щоб збільшити швидкість їх випуску без шкоди для її якості?"

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

Найважливіший спосіб прискорити свій розвиток - це спростити те, що ви робите, щоб це було максимально просто.

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

Я чув, як багато людей розповідають, що "очікує" клієнт. Це погана політика.

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

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

Але часто підвищення швидкості означає жертву якості.

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

Не ускладнювати.

Якщо ви використовуєте TDD, слід дотримуватися " червоного, зеленого, рефактора ":

1. Напишіть невдалий тест ( червоний ). (Часто для функціональності ваш код ще не має.)
2. Зробіть жахливі кодування злочинів, щоб пройти тести ( зелений ). Жорсткий код при необхідності.
3. Рефактор , ймовірно, на короткий час порушив тести, але в цілому покращив дизайн.

Завантажте на комп'ютер локально всю документацію щодо мов / бібліотек, а потім відключіть мережевий кабель / вимкніть Wi-Fi .

Тут не намагаються бути смішними. Це мені справді допомагає!

Зверніть увагу, коли ви занадто довго читали переповнення стека. Виправдання "Компіляція" працює лише так довго. :)

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

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

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

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

Навчіться набирати сенсорний текст якомога швидше .

Я роблю це завтра .

Отримати речі теж надзвичайно корисно.

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

Практика і наполеглива праця.

Вам потрібно вкласти час та зусилля. Коли ви станете більш комфортними та впевненими у будь-яких інструментах, якими слід користуватися, швидкості та креативності.

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

Дізнайтеся про Зону, дізнайтеся, як ввійти в неї, і навчіться розпізнавати, коли ви не в ній.

Після того, як я "в зоні", я надзвичайно продуктивний, і код просто витікає з мене, часто я можу отримати кодування на 2 або 3 дні, зроблене за 1 день. Але мені здається, що часто важко дістатися до цього місця, мені здається, що я зволікаю, відволікаючись на інші речі (наприклад, Stack Overflow).

Цитата з того, що-трюки-роби-ти-користуєшся, щоб дістати себе в зоні

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

Emacs

Перш ніж почати розробку:

• Вийдіть із своєї поштової скриньки
• Вимкніть будь-які клієнти чату
• Ввічливо попросіть однолітків дати вам час на концентрацію
• Звичайно, перестаньте користуватися Інтернетом

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

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

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

Ви повільніше, ніж ваші колеги, чи ваші оцінки більш завищені?

Щоб швидше виробляти програмне забезпечення, я знайшов найкраще - це якнайкраще вивчити свій API виконання. Не набирайте логіку списку, коли буде виконано розширення LINQ; не створюйте купу слухачів подій, коли прив'язка працюватиме тощо.

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

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

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

Можна сказати дві речі, але я ще не бачив серед відповідей, які підвищують продуктивність:

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

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

Пару ідей приходить вам на думку:

1. Отримайте інші думки щодо ваших оцінок. Чи існують інші розробники, у яких ви можете запитати щось на кшталт "Ей, чи вважаєте ви, що ви можете виконати подібну функцію в цей час?" Ідея полягає в тому, що внесок інших людей може допомогти з точністю в деяких випадках, оскільки хтось може відзначити купу речей, які ви пропустили під час оцінки.

2. Відточіть свою майстерність оцінювання - починайте відстежувати, як ви ставитеся до кошторису і чому ви не працюєте: чи інші робочі позиції спричиняють невиконання строків? Ви постійно недооцінюєте, наскільки щось складне? Ви даєте цілу шкалу часу, коли це не практично, наприклад, те, що запитується, є достатньо розпливчастим, що просто отримання прототипу триватиме тижнів, а потім слід повторно оцінити, що ще потрібно зробити? Це може допомогти найбільшою мірою створити цю навичку, так що якщо ви скажете, що щось займе x годин, ви можете бути впевнені в цьому, тому що ви робили це знову і знову і знову. Альтернативний спосіб констатувати це просто практика, практика, практика.

Зрозуміло, ви, напевно, вже вважали це, але я просто вважав, що варто заявити про це тим, хто там, хто, можливо, не вважав ці ідеї.

1. Знайте технологію всередині та зовні.
2. стій! Подумайте! Ідіть!
3. Архітектор для будь-якого, що може виникнути, але реалізуйте лише те, що насправді просять.
4. KISS - Нехай це буде просто
5. Якщо вона стає занадто складною, напевно, вона недостатньо продумана. (Поверніться до 2 та 4)
6. Не зациклюйтесь на 5. Часто виходить починати з нуля (Поверніться до 2 та 4)
7. Поверніться до 1.

Я думаю, що тут ключовим словом є "своєчасність". Вони не сказали, що ти занадто повільний, а не вчасно.

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

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

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

Будьте стабільними, залишайтеся стабільними.

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

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

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

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

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

Невеликі, поступові зміни в системі, яка є стабільно стабільною FTW. Ідіть повільно, щоб швидко йти.

Для мене отримання високої продуктивності - це чітке уявлення про те, чого ви намагаєтесь досягти, і як ви туди потрапите.

Насправді всі відповіді були сказані на смерть у численних місцях тут і деінде. Або, принаймні, я чув це до смерті. Вивчіть свій IDE, навчіться вводити швидше, використовувати фреймворки, використовувати генерацію коду тощо, тощо. Так, звичайно, ці речі допоможуть, і я сумніваюся, що є багато програмістів, які є майстрами всіх. Але, будучи типом програміста, який задає ці запитання та відвідує сайти, такі як Stack Overflow, ви вже знали про ці речі . Ви просто хотіли, щоб сюди вони повторилися, чи ви просто хотіли трохи вийти?

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

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

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

То що ми можемо з цим зробити? Ми не можемо просто переконати своїх начальників у тому, що нам потрібно подвоїти чи потроїти інвестиції у кожен із наших проектів. Я кажу веду за прикладом. Створіть справді чудовий фрагмент програмного забезпечення як побічний проект. Покладіть на це свій час і не йдіть на компроміси. Весь час звертайте увагу на те, як ви прогресуєте. Зверніть увагу на зовні незв'язані завдання, яким вам довелося вкласти несподіване кількість часу, і подивіться, чи можете ви це виправдати. Порівняйте це з усіма іншими проектами, над якими працювали. Будьте жорстоко чеснимиз собою та всіма аспектами цього аналізу. Чи можна зайвими речами, які ви зробили зі своїм якісним програмним забезпеченням, нехтувати в «реальних» проектах на роботі? Але, можливо, ваша спроба зазнала невдачі. Що було причиною? Вам нудно і просто поспішили, щоб виконати основні риси? Я ще повинен щось подібне зробити сам, тому я закінчую цю думку з деяким сумнівом - але я маю намір реально піти. Я буду тримати вас у курсі :).

Нарешті, я вважаю, що більшість (якщо не всі) оцінки ефективності є вивернутими та надзвичайно маніпулятивними. Ви не можете забезпечити якість та швидкість роботи дроселів на 100%. Ваш начальник повинен забивати вас проти стандарту, встановленого організацією. Стандарт організації на компроміс між якістю та швидкістю. Давайте уявимо, що OrangeSoft Inc. очікує 33% якості та 66% швидкості. Тож якщо ви пишете код, який містить, можливо, третину одиниць тестів, як це слід, але доповнюючи його швидкістю та скороченим терміном доставки, ви повинні набрати майже 100% за ваш огляд! (Це досить грубі аналогії, але ви розумієте). Але натомість, що трапляється, це те, що Боб пише код надзвичайно швидко, але це, як відомо, баггі. Тож на огляді його виконання він набере 3/5 за якість та 5/5 за швидкість. Керол, з іншого боку, пише код набагато повільніше, але видає значно менше помилок. Вона набирає 5/5 за якість, але 3/5 за швидкість. Так чи інакше, Боб і Керол приєднаються до підвищення. Чи можливо будь-якому працівникові отримати ідеальний бал? Це справедливо?

Я використовую методику еволюційного прототипування

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