(Translations) Запитайте себе "А що б зробив користувач?"

Переклад статті з книги 97 Things Every Programmer Should Know про те, як мислить юзер і як його краще зрозуміти. Більше стосується програмування, та думаю і тестерам може бути цікаво. Буду вдячний за будь-які зауваження щодо помилок чи неточностей. Також вдячний друзям за допомогу. Ну що ж, поїхали!

В оригіналі статтю можна прочитати тут.

Запитайте себе "А що б зробив користувач?"

Giles Colborne

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

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

Найкращий спосіб дізнатися, як думає користувач, -- це спостерігати за ним. Попросіть його виконати якесь завдання, використовуючи програмне забезпечення, схоже на те, що ви розробляєте. Переконайтесь, що завдання цілком реальне: "Знайти суму колонки чисел" -- нормально; "Підрахувати витрати за останній місяць" -- взагалі чудово. Уникайте занадто конкретизованих завдань, на зразок "Виберіть комірки таблиці і введіть формулу сумування під ними" -- занадто багато підказок в одному реченні. Дозвольте користувачу розповісти про його успіхи. Не перебивайте. Не намагайтесь допомогти. Постійно запитуйте себе "Чому він робить саме так?".

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

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

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

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

(Translations) Beauty Is in Simplicity - Jørn Ølmheim

Оригінал статті можна прочитати тут.

Beauty Is in Simplicity - Jørn Ølmheim

Краса у простоті

Jørn Ølmheim

Є відома цитата Платона, яку, на мою думку, варто знати і пам’ятати усім розробникам програмного забезпечення.

У характері, в манерах, в стилі, у всьому цьому найпрекрасніше - простота.

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

Ось кілька властивостей, які ми прагнемо надати коду:

• Легкість читання
• Легкість підтримки
• Швидкість розробки
• Невловиме поняття краси

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

Що таке гарний код? Це дуже суб’єктивне питання. Сприйняття краси, як і будь-чого іншого, залежить від нас самих. Люди з художньою освітою сприймають красу не так, як люди з технічною освітою (чи, принаймні, мають інший підхід до краси). Знавці мистецтв при оцінці краси програм порівнюють їх з творами мистецтва, натомість науковці згадують симетрію і золотий переріз та намагаються звести все до формул. Наскільки я знаю, більшість аргументів обох сторін ґрунтується на простоті.

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

Ви вже повернулись? Чудово. На чому ми зупинилися? Ага... Я помітив, що код, який я вважаю красивим, має декілька спільних ознак. Головною з них є простота. Я вважаю, що незалежно від того, наскільки складна програма чи система в цілому, окремі частини повинні бути простими: прості об’єкти з простими обов’язками, які містять так само прості, сфокусовані методи з описовими назвами. Дехто вважає, що короткі методи на 5-10 рядків коду -- це занадто, і цього важко досягнути на деяких мовах, але я вважаю, що все одно така стислість є бажаною метою.

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

Краса народжується і відкривається у простоті.

(Translations) The Guru Myth - Міф про гуру

Ryan Brush

Оригінал можна прочитати тут.

Кожен, хто займався розробкою достатньо довго, чув питання на зразок такого:

В мене вилітає виключення XYZ. Ти часом не знаєш, в чому справа?

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

Таких запитань слід очікувати від людей, не знайомих з програмним забезпеченням: для них системи видаються мало не магією. Що мене турбує -- це такі випадки у спільноті програмного забезпечення. Подібні питання постають при проектуванні програм, наприклад: “Я пишу керування запасами(inventory management).Чи варто використовувати оптимістичне блокування(optimistic blocking)?” Парадоксально, але той, хто задає питання, часто може дати кращу відповідь, ніж той, кого запитують. Той, хто питає, скоріше за все, знає контекст і вимоги, а також може прочитати про переваги і недоліки різних стратегій. Втім, вони очікують від вас розумної відповіді без контексту. Вони очікують чаклунства.

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

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

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

(Tranlations) Постійно вчитись - Клінт Шанк

Стаття з книги 97 Things Every Programmer Should Know. Величезне спасибі друзям за допомогу з перекладами. Буду вдячний за будь-які зауваження щодо помилок чи неточностей. Ну що ж, поїхали!

В оригіналі статтю можна прочитати тут.

Clint Shank

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

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

Ось список способів, як продовжувати навчатися. Багато з них доступні безкоштовно в інтернеті:

• Читайте книги, журнали, блоґи, Твіттер та веб-сайти. Якщо ви бажаєте заглибитись у вивчення предмету, подумайте про приєднання до розсилок новин. 
• Якщо ви справді хочете розібратись в технології, приступайте до діла -- пишіть код. 
• Завжди намагайтеся працювати з наставником, бо якщо ви найкращий у колективі, це може ускладнити Вашу освіту. Хоча від кожного можна чогось навчитися, набагато більше можна почерпнути від того, хто розумніший чи досвідченіший за Вас. Якщо ж ви не можете знайти вчителя, переходьте до наступних пунктів. 
• Використовуйте віртуальних учителів. Знайдіть в інтернеті авторів і розробників, які Вам справді до вподоби, і читайте все, що вони пишуть. Підпишіться на їхні блоґи. 
• Вивчайте фреймворки та бібліотеки, які ви використовуєте. Якщо ви знаєте, як що-небудь працює, то можете краще його використовувати. Якщо вони мають відкритий код, то Вам дуже пощастило. За допомогою дебаґґера покроково проходьте код і спостерігайте, що відбувається під капотом. Ви побачите код, який писали і перевіряли дуже розумні люди. 
• Кожного разу, коли ви зробили помилку, виправили баґ, або зіткнулися з проблемою, постарайтесь розібратися, що сталось насправді. Скоріше за все, ще хтось зіткнувся з подібною проблемою і опублікував її в інтернеті. Google -- Ваш друг:) 
• Прекрасний спосіб щось вивчити -- вчити це або говорити про це. Коли люди збираються Вас слухати, і задавати Вам запитання, у Вас буде чудова мотивація вчитись. Спробуйте lunch’n’learn на роботі, приєднайтесь до групи користувачів, або відвідайте якусь місцеву конференцію. 
• Приєднайтеся до навчальної групи, або створіть нову (як-то спілка вивчення "узорів"-паттернів), або приєднайтеся до місцевої групи користувачів мови, технології чи дисципліни, яка Вас цікавить. 
• Відвідуйте конференції. Якщо ж не маєте змоги -- багато конференцій транслюються онлайн безплатно. 
• Далеко їхати? Слухайте подкасти. 
• Користувалися статичним аналізом кодової бази? Бачили попередження свого середовища розробки (IDE)? Дізнайтеся, що вони повідомляють і чому. 
• Послухайте пораду Pragmatic Programmers та вивчайте нову мову програмування кожного року. Принаймні вивчіть нову технологію чи інструмент. Це дасть Вам нові ідеї, які ви зможете використати у технології, з якою працюєте зараз. 
• Не все, що ви вивчаєте, повинно буди пов’язане з технологією. Вивчайте свою галузь роботи, щоб краще розуміти вимоги і допомагати в розв’язанні бізнес-проблем. Вчіться бути продуктивнішими і краще працювати -- це також дуже хороший варіант. 
• Поверніться до школи.  (?)

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

Технологія змінюється швидко. Не відставайте.