Як програмісту збільшити швидкість роботи?.

Ти вже пишеш. Пишеш поки ще нескладні програми і досить повільно. Але ти рвешся у бій. Як різко збільшити швидкість? Ось що тебе хвилює.

Ігор Корсар

Із серії "Парадокси програмування"

Ти вже пишеш. Пишеш поки ще нескладні програми і досить повільно.
Але ти рвешся у бій. Як різко збільшити швидкість? Ось що тебе хвилює.
Скажу відразу - різко не вийде. Швидкого нічого не буває.
Але поступово і методично ... Загалом, слухай.

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

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

Другий момент. Що часто нас уповільнює: великі проблеми?
Ні. Над ними ми постійно думаємо, навіть не помічаючи цього. Думаємо будинку, в
транспорті, уві сні. У результаті ми готові їх вирішити і досить оперативно.
Уповільнюють нас дрібниці!

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

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

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

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



Це було раціональніше й швидше.

Третій момент. Обов'язково роби копії своїх недописаних програм.
Втрата вихідних текстів у результаті аварії, зведе всі твої старання
до нуля.

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

Сударь, хочете, щоб швидкість роботи Вашого колективу була приголомшливо
великий? Зрозуміло. Хто ж не хоче.
Тоді зробіть так, щоб усередині відділу панувала відкрита
інформаційне середовище. Щоб люди намагалися ділитися, як своїми успіхами,
так і своїми помилками.
Досягніть, щоб знову надійшов співробітник відповідь на будь-яке питання
отримував з живих уст, а не з нудних книжок.
Як у нас часто буває? Приходить людина на нове місце, задає питання,
а його відсилають до документації. Кому-то ніколи, а хтось просто не хоче,
щоб швидко доросли до його рівня.
Причому, аргументи відсилають звучать настільки переконливо, що навіть можна
повірити.
Ви теж вірите? І не вірите мені? А Ви уявіть таку картину.
Потрапляєте Ви в місто, де говорять іноземною мовою. Вам потрібно жити
в цьому середовищі. Вам потрібно дізнатися про неї багато. Ви намагаєтеся задавати питання.
І замість того, щоб підказати Вам, куди можна піти поїсти, Вас
відсилають до словника.
Подумайте, коли Ви в таких умовах навчитеся говорити? А поїсти, цікаво,
Вам вдасться?
Так що подумайте, пане!
Якщо Ви не створите такй середовища в колективі, програміст все одно
доб'ється своїх висот, але пізніше, а можливо і набагато пізніше. До того ж він
може стати інформаційно замкнутим. А навіщо? Адже він всього добивався
своєю працею, то чому він повинен комусь допомагати?

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

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

Так що оперативна допомога ближньому - взаємовигідна!
Зрозуміли, пане? Ухопив суть, програміст?

От і добре. Спробуйте ...