1.	Робота з файлами у Python: ім'я файлу, відкриття, запис та закриття файлів, порядкове зчитування, конструкція with open as, позиція курсора у файлі.
Перш, ніж працювати з файлом, його треба відкрити:
>>>f = open('text.txt', 'r')
Важливі 3 аргументи:
1)	ім'я файлу. Шлях до файлу може бути відносним або абсолютним.
2)	режим, в якому ми будемо відкривати файл.
o	'r' – відкриття на читання (є значенням за замовчуванням).
o	'w' – відкриття на запис, вміст файлу видаляється, якщо файлу не існує, створюється новий.
o	'x' – відкриття на запис, якщо файлу не існує, інакше виняток.
o	'a' – відкриття на дозапис, інформація додається в кінець файлу.
o	'b' – відкриття в довічним режимі.
o	't' – відкриття в текстовому режимі (є значенням за замовчуванням).
o	'+' – відкриття на читання і запис
Режими можуть бути об'єднані.
3)	encoding, потрібен тільки в текстовому режимі читання файлу. Цей аргумент задає кодування.
Запис в файл здійснюється за допомогою методу write (повертає число записаних символів):
>>>for index in l:
f.write(index + '\n')
Після закінчення роботи з файлом закриваємо його за допомогою методу close: >>>f.close()

Курсор напрямý повідомляє усім функцям вводу та виводу звідки починати працювати з відкритим файлом. Курсор автоматично переміщається по файлу по мірі його прочитання. Таким чином при використанні функції ‘read’, ми вичитуємо повний вміст файлу, а отже отримуємо наш курсор на останній позиції у файлі – у самому кінці. Саме тому повторний виклик функції read повертає нам порожню стрічку. Функція починає вичитувати з позиції курсора, який на той момент є в кінці файлу, тому і вичитувати вже нічого.
Якщо в конструкції with вказана функція open (), то після виконання інструкцій всередині блоку файлу автоматично закритий. Приклад:
#from __future__ import with_statement # Для Python 2.5
with open("test.txt", "a") as f:
    f.write("Строка\n") # Записываем строку в конец файла
У цьому прикладі файл test.txt відкривається на дозапис в кінці файлу. Після виконання функції open () змінній f буде присвоєна посилання на об'єкт файлу. За допомогою цієї змінної ми можемо працювати з файлом всередині тіла інструкції with. Після виходу з блоку, незалежно від наявності винятку, файл буде закритий.

2.	Життєвий цикл програмного забезпечення.
Життєвий цикл програмного забезпечення — сукупність окремих етапів робіт, що проводяться у заданому порядку протягом періоду часу, який починається з вирішення питання про розроблення програмного забезпечення і закінчується припиненням використання програмного забезпечення. Життєвий цикл програмного забезпечення - період часу, що починається з моменту прийняття рішення про необхідність створення програмного продукту і закінчується в момент його повного вилучення з експлуатації. Цей цикл - процес побудови і розвитку ПЗ.
Життєвий цикл програмного забезпечення супроводжується розробленням, обігом та використанням програмної документації.
Найбільш загальним представленням життєвого циклу ПЗ є модель у вигляді базових етапів - процесів, до яких відносяться:
•	системний аналіз і обгрунтування вимог до ПЗ;
•	попереднє (ескізне) і детальне (технічне) проектування ПЗ;
•	розробка програмних компонент, їх комплексування і відлогодження ПЗ в цілому;
•	випробовування, дослідна експлуатація та тиражування ПЗ;
•	регулярна експлуатація ПЗ, підтримка експлуатації та аналіз результатів;
•	супровід ПЗ, його модифікація і вдосконалення, створення нових версій.

3.	Склад команди виконавців проекту: особливості роботи та функціональні обов'язки технічних виконавців та управлінців.
Для того, щоб зробити найпростіше додаток, досить одного-єдиного програміста. Але при зростанні складності і збільшенні термінів розробки комусь доведеться виконувати ті чи інші ролі, навіть якщо вони явно не виділені (у вигляді посад або якось ще).
1)	Команда програмістів
Власне, ті люди, які придумують і реалізовують додаток. вони:
•	придумують архітектуру програми;
•	пишуть код;
•	консультують друге, як писати код;
•	рецензують код іншими;
•	пишуть автоматичні тести (по крайней мере, їх частина - модульні тести);
Без написаного і скомпільованої коду програми не буде. Саме тому зовсім виключити програмістів не можна. Навіть якщо якісь додатки створюються в простому візуально конструкторі, то це теж свого роду програмування.
Саме програмісти часто приймають рішення, як саме буде реалізована і чи інша функціональність в додатку. І якщо функціональність реалізована погано, то значна частина провини може бути покладена на програміста. А може і ні, оскільки фінальне слово в прийняття рішень належить не їм.
2)	Тестувальники
Це ті люди, які перевіряють, чи коректно працює додаток. Причому коректно - не означає зручно для користувача. Тестувальник може написати зауваження до зручності використання, але його першочергове завдання - переконатися в тому, що додаток працює відповідно до вимог.
Тестувати програми можна як вручну, так і за допомогою автотесту (наприклад, програмно натискати кнопки і перевіряти, які екрани відкриваються).
При відсутності в команді розробки тестувальників, їх функції зазвичай передаються програмістам. При цьому вважається, що програміст не може коректно протестувати те, що він розробляв сам, і тому проводиться перехресне тестування. Інший спосіб економії на тестувальниках може полягати в тому, що досвідчений фахівець залучається тільки для написання плану тестування, а реальне – виробляють початківці тестувальники-початківці.
3)	Дизайнер
Це людина, яка визначає, як буде виглядати і поводити себе додаток. Взаємне розташування елементів, схема переміщення по екранах, анімації - все це повинен продумати дизайнер. Якщо додаток великий і складний, то дизайнер може бути і не один.
Дизайнер є не у всіх компаніях, що займаються розробкою ПЗ, тому якщо додаток не обіцяє комерційного успіху, то з'являється спокуса заощадити на залучення професійного дизайнера, передавши його обов'язки програмістам. І може вийти не так вже й погано, якщо програмісти досить досвідчені і поняття «usability» і «user experience» для них - не порожній звук.
Іноді дизайнер спільно з програмістами несе відповідальність за частину помилок в додатку: буває, що реалізувати придуманий дизайн досить складно, а при зростанні складності збільшується і ймовірність здійснення помилок. І, звичайно, всі відгуки «незручний інтерфейс» - це камені в город дизайнера.
4)	Замовник або власник продукту
Це людина, яка визначає весь хід створення і розвитку продукту. Він приймає рішення, що має бути зроблено, оцінює, чи відповідає реалізація концепції продукту чи ні..
Різниця в назвах ролі виникає з типу компанії. У продуктовій компанії (яка розробляє свій внутрішній продукт) призначається власник продукту. При замовній розробці виділяється представник замовника, який буде взаємодіяти з розробниками.
Чи може проект розробки обійтися без цієї людини? Проект - може, а продукт (додаток) – не має. Хтось все одно повинен розуміти, для чого цей додаток розробляється і як він повинен існувати і розвиватися надалі.
5)	Керівник проекту
Людина, яка керує всім цим неподобством всієї цієї командою. Відстежує строки виконання завдань. Оперативно реагує, якщо починаються проблеми з якістю. Мотивує команду працювати більш ефективно. Разом з власником продукту приймає рішення, коли можливі альтернативні варіанти при виборі розвитку продукту в ході розробки. Якщо проект дуже великий і складний, то він може розбиватися на кілька підпроектів, і у них можуть бути свої керівники, а в допомогу керівнику проекту виділяється адміністратор проекту, який займається здебільшого «паперової» роботи.
За статистикою, тільки мала частина проектів з розробки ПЗ завершується в строк з встановленим рівнем якості і в рамках початкового бюджету. Якщо щось пішло не так, саме керівник проекту в кінцевому рахунку приймає відповідальність за те, чим доведеться жертвувати: випустити продукт пізніше, виправляти помилки за допомогою оновлень або вибити побільше грошей (наприклад, щоб віддати частину розробки іншій команді за окремі гроші).
У невеликих проектах з досвідченою командою програмістів і тестувальників можна обійтися і без явно виділеного керівника проекту. Тоді зазвичай його роль виконує провідний програміст - teamlead.

4.	Технічне завдання: означення, функції, необхідні складові ТЗ для виконавця та замовника
Технічне завдання (ТЗ) — це затверджений документ, на основі якого виконується розробка проекту. У ньому максимально точно і детально описані вимоги до компонентів та характеристик майбутнього веб-продукту.
На основі ТЗ здійснюється наступний крок — оцінка проекту, тобто його рівня складності і відповідно розрахунок термінів роботи і вартості. На цьому неоднозначному і спірному етапі команда розробників стикається з багатьма труднощами максимально точної оцінки. Неможливо з впевненістю на 100% передбачити затрати часу та коштів. Однак, чим детальніше буде розписане ТЗ із самого початку з мінімальними подальшими доробками, тим точнішими будуть прогнози. Чим чіткіше ви опишете кінцевий результат, тим простіше буде до нього наблизитись.
Технічне завдання дозволяє (як сполучна ланка між замовником і виконавцем):
     Обом сторонам:
•	представити готовий проект до початку роботи;
•	виконати попунктно перевірку готового продукту;
•	зменшити кількість помилок, пов'язаних зі зміною вимог внаслідок їхньої неповноти або хибності.
     Замовнику:
•	усвідомити, що саме йому потрібно, чітко це сформулювати;
•	вимагати від виконавця відповідності продукту всім обумовленим та затвердженим пунктам ТЗ.
     Виконавцю:
•	зрозуміти суть поставленого завдання;
•	планувати виконання проекту в деталях і працювати за наміченим планом;
•	відмовитися від виконання робіт, не зазначених у ТЗ.
Технічне завдання на розробку програм складається, перш за все, для тих людей, які будуть здійснювати цю саму розробку. Відповідно, воно повинно бути зрозуміло тій людині, яка нічого не знає про клієнта, і вже тим більше, про його завдання і проблеми.
У загальному вигляді, технічне завдання переслідує декілька цілей:
•	організація;
•	інформація;
•	комунікація;
•	юрисдикція.
Організацію повинно бути спрямовано на сам процес, інакше кажучи, упорядкувати творчість і творення розроблюваної програми або програмного комплексу. Структура технічного завдання на розробку програм повинна бути чіткою і в той же час лаконічною. Оскільки читати 120-150, а то й більше, сторінок непридатного технічного тексту, творча особистість програміста просто не зможе. А значить, стислість - сестра таланту.
Інформаційна складова ТЗ повинна бути повною, але стислою. І знову ж таки просте правило, "необхідно і достатньо". Його, як водиться, потрібно дотримуватися завжди і скрізь, але при складанні технічного завдання з розробки програми, це правило стає номер один. Грамотне технічне завдання - перший і останній документ, який розповість про всі бажання замовника у зручній для розуміння програміста формі.
З комунікаціями дещо складніше. Чому? Та тому що комунікації, та ще й у процесі дещо творчому, завжди складні. Особливо, якщо спілкуватися різними мовами. А мов тут може бути декілька, більш точно - за кількістю учасників проекту під кодовою назвою "розробка програми". Простіше кажучи: Клієнт, він же Замовник, Менеджер проекту, Виконавці проекту: програміст(и), інші можливі учасники, які мають рацію, як зробити, як зробити краще, і чим все має закінчитися.
Природно, створюючи спільний проект, ці учасники змушені шукати мову, доступну для загального розуміння кожним. Такою мовою і покликане стати технічне завдання на розробку програми. В ідеалі, головне - встановити канал зв'язку між першою і третьою ланкою, і чим менше перешкод при цьому буде вносити друга і четверта ланки, тим якіснішим буде результат, а розробка програми принесе бажаний результат при мінімальних нервовтратах.
Завдяки технічним завданням, можна судити про відповідність результату розробки програм і заданих початкових умов. Треба сказати, що короткочасністю пам'яті страждають як Замовники проекту, так і Виконавці. Перші забувають про обумовлену вартість, кількість правок, можливість впровадження та налагодження, а інші - в принципі про те, що і коли вони повинні були зробити. Щоб звести амнезію та її наслідки до мінімуму, необхідно знову ж таки, чітке і конкретне ТЗ на розробку програми.

5.	Типи тестування: за знанням системи, за ступенем автоматизації, за часом проведення тестування, за ступенем підготовленості до тестування.
За знанням системи:
•	тестування чорного ящика (black box);
•	тестування білого ящика (white box);
•	тестування сірого ящика (gray box).
За ступенем автоматизації:
	ручне тестування (manual testing);
	автоматизоване тестування (automated testing);
	напівавтоматизоване тестування (semiautomated testing).
За часом проведення тестування:
	Альфа-тестування (alpha testing):
	тестування нової функціональності (new feature testing);
	регресійне тестування (regression testing);
	тестування при здачі (acceptance testing);
	Бета-тестування (beta testing).
За ступенем підготовленості до тестування:
	тестування за документацією (formal testing);
	Ad Hoc Testing (інтуїтивне) тестування (ad hoc testing).

6.	Культура коду. Оптимізація коду. Рефакторінг
Культура коду
Код гарної програми повинен бути на стільки простим, на скільки це можливо. Простий код простіший у читанні, а значить у підтримці. Простий код зазвичай коротше і зрозуміліше, а значить, містить менше помилок.
Виникає неминуче питання - як зробити таким чином, щоб програмний код був зрозумілим, не створював складнощів при подальшому супроводі й взагалі не являв собою нерозбірливу плутанину?
I.	Будьте розсудливі - пишіть коментарі
Коментуйте свій програмний код. Обов'язково. Коментарі не тільки економлять час, вони самі потребують часу. Коментарі вимагають часу на прочитання, крім того, вони збільшують фактичні розміри програми на екрані монітора, в результаті чого перед вашими очима може одночасно перебувати менший обсяг діючого програмного коду.
II.	Не давайте змінним імена, здатні ввести в оману.
Кінцева мета проста: написати програмний код таким чином, щоб стороння людина, не маюча уявлення про те, що цей код робить, могла зрозуміти його якомога швидше. При цьому необхідно дотримуватися золотої середини. Давайте своїм об'єктам імена, досить довгі й наочні для розуміння їх сенсу, однак не настільки довгі й громіздкі, щоб це ускладнювало читання програмного коду.
III.	Перевіряйте свою програму на наявність помилок.
Якщо ваша програма досить велика, в ній напевно буде безліч функцій і процедур. Як би це не здавалося клопітно, кожну функцію/процедуру необхідно перевіряти на наявність помилок. Напишіть свій код так, щоб він перевіряв процедуру/функцію на наявність ворожих даних і захищався від них. Переваги такого підходу не вичерпуються захистом програми від збоїв. Хороші механізми перевірки на наявність помилок також прискорюють налагодження.
IV.	"Передчасна оптимізація - корінь усіх негараздів".
Оптимізація - ворог ясності. Однак, слід відзначити, що у деяких випадках оптимізація необхідна. Проте, майже ніколи не відомо заздалегідь, що саме необхідно оптимізувати, до тих пір, поки ви не протестуєте реально функціонуючий код за допомогою інструменту під назвою Профайлер (це програма, яка спостерігає за вашою програмою і оцінює час, що витрачається на виконання окремих викликів).

Напишіть ясну і працюючу програму. Згодом у вас буде достатньо часу, щоб спаплюжити її за допомогою оптимізації. Однак не робіть цього до тих пір, поки не будете абсолютно впевнені, що робите правильно.
V.	Не мудрувати.
Прагніть до простоти і ясності - це збереже вам масу часу і позбавить від непотрібних страждань. Ще раз повторимо, що код гарної програми повинен бути на стільки простим, на скільки це можливо.
VI.	На що ще слід звертати увагу.
1)	Довжина рядка не повинна перевищувати 80 символів. Зазвичай доводиться переносити або виклики функцій з великою кількістю аргументів, або які-небудь складні умови в конструкціях типу if. Але переносити треба обов'язково, так, щоб весь код було видно без прокручування екрану по горизонталі.
2)	Використовуйте табуляцію замість пробілів. Бажано користуватися саме табом, замість пробілів. Це і швидше, і зручніше для редагування, коли потрібно, наприклад, зрушити код вліво.
3)	Слідкуйте за правильною кількістю відступів усередині всіх конструкцій. Кількість табуляцій перед кодом повинно відповідати його вкладеності.
4)	Функція повинна вміщуватися на екран. Це, звичайно, в ідеалі, але дуже бажано. Якщо розмір функції складає більше двох екранів - це явна ознака того, що її має сенс розділити на кілька частин.
5)	Використовуйте «говорячі» назви функцій та змінних. Відмовтеся від неоднозначних і безглуздих назв змінних, краще введіть довгу назву, зате відразу буде ясно, що відбувається. При певному розмірі програми використання "не говорячих" функцій і змінних взагалі унеможливить будь-яку подальшу розробку.
6)	Не використовуйте нумерацію для функцій, які вирішують схожі завдання. Буває, що функції виконують одне і те ж, але різними способами.
7)	Не намагайтеся штучно обмежити довжину імені функції. Згідно з дослідженнями оптимальна довжина змінної - це 9-15 символів. Функція несе ще велике смислове навантаження, відповідно і довжина у неї може бути ще більшою. Важливо мати "говорячі" назви функцій.
8)	Не використовуйте як імена функцій російські слова, написані транслітом. Назви з використанням англійських слів будуть нормально сприйняті будь-яким програмістом, на відміну від використання русіш неймінг.
9)	Використовуйте опис значення, що повертається для іменування функції. Якщо функція щось повертає, це повинно бути зрозуміло з назви.
Оптимізація коду.
Оптимізація коду – різні методи перетворення коду заради поліпшення його характеристик і підвищення ефективності. Серед цілей оптимізації можна вказати зменшення обсягу коду, обсягу використовуваної програмою оперативної пам'яті, прискорення роботи програми, зменшення кількості операцій введення виведення.
Головне з вимог, які звичайно пред'являються до методу оптимізації – оптимізована програма повинна мати той же результат і побічні ефекти на тому ж наборі вхідних даних, що і неоптимізована програма.
Існують такі поняття як високорівнева і низькорівнева оптимізація.
o	Високорівневі оптимізації в більшості проводяться програмістом, який, оперуючи абстрактними сутностями і уявляючи собі загальну модель вирішення задачі, може оптимізувати дизайн системи. Оптимізації на рівні елементарних структурних блоків вихідного коду теж зазвичай відносять до високого рівня; деякі виділяють їх в окремий рівень.
o	Низькорівнева оптимізація проводиться на етапі перетворення вихідного коду в набір машинних команд, і найчастіше саме цей етап піддається автоматизації. Втім, програмісти на асемблері вважають, що ніяка машина не перевершить в цьому хорошого програміста.
Рефакторинг.
Рефакторинг – це процес зміни коду без зміни функціональності. Тобто з точки зору користувача програма не змінюється. Але з точки зору програміста вона змінюється, при чому у бік покращення, якщо рефакторинг проводиться грамотно.
Рефакторинг полягає в чищенні програмного коду від «латочок» і зміни архітектури з метою зробити її більш зрозумілою, гнучкою. Подібну чистку необхідно проводити регулярно. Це зробить код більш простим, надійним, гнучким.
Код який кілька разів переписувався або змінювався швидкоруч, так само може вимагати рефакторингу. Відразу написати ідеальний код – це дуже складне завдання. Код повинен еволюціонувати, і в цьому вам допоможе рефакторинг.
Рефакторинг необхідний, якщо:
	Має місце складність модифікації. Підтримка вимагає все більше і більше ресурсів.
	Має місце складність читання. Є коментарі типу: "Як це працює - не зрозуміло. Не чіпай!".
     Перш ніж приступити до рефакторингу підготуйте засіб підтвердження коректності коду.