Архіви категорій: Dev

Скільки беклогів у вашому проекті?

В реальності може існувати декілька видів беклогу – паралельно жити своїм життям:

  • Беклог власника продукту – з чим прийшов до команди як замовник, на підставі чого планує product roadmap.
  • Беклог команди – що команда пропрацювала та що використовує при оперативному керування.
  • Беклог сподівань та очевидних речей – беклог замовника, я це не пишу, бо це і так очевидно (надалі перелік який змінюється час від часу)
  • Приватний таск-ліст розробника – окрема табличка з тасками яка може перетворитись в … Таємний беклог розробника – там з’являється технічний борг, ідеї щодо того що він хоче покращити або чим погратись з боку технологій. Кількість таких власних беклогів залежить від вподобань розробників та їх власного та незалежного бачення як правильно.
  • Беклог у коді – примітки щодо недороблених речей, відсутності обробки виключень, технічний борг, потенційні баги.
  • Беклог тестувальника – тест кейси та все що дізнався QA переглядаючи угоду, аналітичні документи, архітектури, всі інші вимоги тощо.

Наявність, кількість, ізольованість та різноманітність наведених вище беклогів у рамках проекту – це фундація конфліктів, низької ефективності, непередбачуваності та високого рівня незадоволеності всіх stakeholders проекту.

Вподобайка для low code / no code

Магічний вплив простих речей на замовника від https://www.facebook.com/Moshkovsky.art/

Рекламне гасло лідерів low-code / no-code: громадянин-бізнесмен може зробити свою програму. Чи це правда? Так. Це те що бажає бізнес? Мабуть, ні. Чому?

Читати далі

Улюблені фічі

З початком проєкт після першого Project Kick-off починається велика політична гра власних інтересів членів команди щодо фіч рішення. Чи буде це зроблено навмисно? Мабуть, ні. Але чому так станеться? Тому що навіть розробники – люди (чи не всі?).

Читати далі

YAGNI, нафіг

YAGNI — You ain’t gonna need it – вам це не потрібно. Все, що не передбачено технічним завданням проекту, не повинно бути в програмі. Або перестань вигадувати додаткові лісопеди та складнощі, не пиши чого-сь щоб-було тому що якщо-шо.

Читати далі

А якщо …

А якщо користувач буде працювати на телефоні без зв’язку – то давайте докрутимо підтримку offline? Або якщо користувач забажає змінити колір обов’язкових полів не формі, або якщо мусить … Надалі миттєво пропозиція цікавого технологічного рішення яке зробить добре уявному користувача у ситуації якщо що. А чи все добре коли ми частіше та частіше починаємо робити вправи “а якщо”?

Читати далі

Timeless Laws of Software Development

Завжди круто почути історії досвідченого розробника, переглянути історію проблем та пошук рішень. Книгу “Timeless Laws of Software Developmen” написав досвідчений розробник – Jerry Fitzpatrick.

Читати далі

Розуміння в цілому

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

” – А! Це ж питання до бізнес-аналітиків – нащо інженерам знати це? Нехай BA ібуцця з бізнесом, не заважайте інженерам! ” – отаке можна почути від пересічного софтбудівника.

Отаке … але ніт.

Читати далі

Багофікусники на проді

Оце так дивний лук від Moshkovsky_art

То така хуйня трапляється майже з кожним розробником. Але що робити щоб такого не було? Ну взагалі то так … Аде ж крім того, щоб було взагалі все класно – це ще налаштувати базовий CICD. І це на якась там фігня або цацки девопсів – це загальна культура для інженерів та … менеджерів.

PS Якщо ви таке робите або ваш колега – то це гарна нагода подарувати йому кружку.

Прості речі

Успішна розробка залежить від багатьох факторів. Є кілька важливих факторів: перше це якість людей. Друге це – планування. Третє – робіть прості речі. При цьому баланс якості та стійкість коду, модульність. І все це в умовах спокою та відповідальності. Все просто 🙂

Читати далі

Захоплення

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

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

Читати далі

Радість розробника ?

  • ❤️ Радість створення – ми створюємо, воно працює. Звісно тут десь є магія і навіть творець не зовсім розуміє як воно насправді працює. Але ось воно, кнопочки-контрольчики-API-логи!
  • ? Радість пошуку рішень та подолання challenges – ми обожнюємо розв’язувати складні проблеми та робимо відповідно до вимог. Трошечки епічного героїзму та батлів з створеними власноруч орками.
  • ? Радість подолання складності – ми розбираємо складні речі по кубикам та збираємо кубики в гнучкі системи. А що до того яки виконати магічні паси CICD або щось таке клацнути на панелі керування космічною станцією Visual Studio – і ось з’явилась ПРОГРАМА!
  • ?Радість абстракцій – ми отримуємо право назвати нове, надати йому атрибути та функції. Ми бачимо як наше маля росте з перших строку коду до самостійного складного класу або навіть бібліотеки.
  • ? Радість нових знань – ми постійно вчимося – новим технологіям, мовам програмування, розв’язання типових проблем.

Інженерна небезпека

Майстерність зроби складний піпець з дуже простої задачі

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

Читати далі

Велике рефакторництво

Якщо ви натхненно робили говнокод – прийде час для купи яскравих спринтів з назвою “Велике рефакторництво“. Але гарне питання – чи варто було робити ту купу гавнокоду?

Автор котика – Вася Ложкін

Нащо тестувати?

Ну що там робити – build-deploy-go-live! Нащо витрачати час на тестування! Чи тестувати?

Мабуть, краще тестувати – робити ці срані Unit Tests, влаштовувати дику паніку якщо на вашому проєкту відсутній QA інженер.

Велика дяка Monkey User (https://www.facebook.com/ismonkeyuser)

Життєвий цикл

Рано чи пізно, так чи інакще ця манюня стане отим страшенним гімном.

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

Велика дяка Monkey User (https://www.facebook.com/ismonkeyuser)