Цей лист отримають не усі, а лише ті, кому можливо це буде цікаво та корисно з точки зору професійної діяльності. Здається, що моя мова стає все більш канцелярською та неприродною :) Це був ліричний відступ.
Вже минуло майже 4-ри місяці, як я працюю на компанію Capula, тому можна підводити деякі проміжні підсумки. Загалом, ситуація нічим не краща, ніж у звичайній українській компанії середньої руки - 40-50 чоловік безпосередньо технічного персоналу.
В тексті згадуються декілька проектів, в яких я брав участь в Україні: Ексім в Прікомі та Протоколи в Афортіо.
Негативи:
1. Не має нормального environment'а. Тобто bug-tracker написаний самотужки, ціла низка Excel'ьних файлів з результатами тестування і т. п. неподобства.
2. Постійні проблеми з контролем версій, релізами, патчами. Існує лише дві людини, які знають або приймаю рішення що, коли і в який бранч попаде. Якщо раптом їх не має в офісі, настає легкий ступор в роботі:) До того ж, БД частину лише нещодавно перевели на CVS. Не уявляю як вони до цього працювали?! Щоб вам було легше оцінити маштаб трагедії, наведу декілька параметрів системи: кількість таблиць - 1073, спільки ж PL/SQL пекеджів :) Ніхто вже достеменно не знає, що й для чого використовується.. Це до речі, ще не найстрашніша сутиація. Мій друг, теж Java програміст, намагається пролобіювати впровадження Subversion, а то вони мержать бранчі вручну. Чим займається його компанія не скажу, щоб не псувати вам позитивне уявлення про розвинутий "ке-пі-та-лізм", як казав А.Шварцеафро-американець.
3. Загальна проблема з формалізацією процедур. Як фіксити баги, еплаїти пачі, називати бранчі та теги і т.д. Тобто п. 2 в квадраті. Правда є внутрішня WiKi, але там далеко не вся інформація. До того ж ніхто окремо нею не займається. От як у тебе є бажання і час туди щось написати, то пиши. Але ж загально відомо, що програмісти - то ще ті ледарі! :)
4. Власне проект, в якому я працюю - це веб фронт-енд для старої та велекої системи, написаної на Oracle Forms. Тобто половина бізнес логіки "зашита" в PL/SQL код. Це звичайно ж сподобалось б Юрчику Когуну, але якщо взяти до уваги пп. 2-3, і той факт, що над PL/SQL кодом в нашому проекті працює лише півтора чоловіка на 5 Java програмістів, то ситуація зовсім невтішна. Навіть не враховуючи явні недоліки та обмеження такої архітектури.
5. Тестування.. Продукт вже проданий 5-м клієнтам, у яких стоять різні версії, і в кожного з них є свої фіча-ріквести. Пп. 2-3 ускладнються підтримкою, баг-фіксом та тествуванням різних версій. Unit тестування відсутнє як явище.
Позитиви:
1. Оскільки продукт є чимось середнім між замовним та "з коробки" (out-of-the-box), у кожного клієнта паралельно підняті дві хардварні платформи - testing та live. На кожній платформі інстальовано по дві копії системи: QA та Training на testing, QA та Live на live. Перед тим як потрапити на live, нова версія тестується клієнтом на testing платформі.
2. Дедлайни не такі страшні, як були колись з Ексімом або Протоколами, тому що реліз спочатку іде на тестову платформу.
3. Щотижня наш мнеджер - Стів (100% інгліш)- проводить тім мітінг. Збираються усі і почерзі розказують, чим вони зараз займяються. Це дуже позитивна штука. Мені, наприклад, вона допомогла запам'ятати імена тих, з ким працюю :) Ну і звичайно бути в курсі "куди йдемо, за що боремося".
4. Тестування.. Власне є тестування самими девелоперами, тестерами та безпосередньо самим клієнтом. HEAD та інші основні бранчі перезбираються кожної ночі (nightly build), тому дозволяється комітити лише працюючий код. Це звичайно впливає на якість кінцевого продукту. Але є одне "але". Час, який може пройти від розробки до отримання
помилки від клієнта, може сягати кількох тижнів або навіть місяців. Тому, щоб виправити такий баг іноді потрібно витрати стільки ж часу як і на сам девелопмент. До того ж це дратує... інколи :) Але не будемо про погане. Як на мене, то процедура тестування, яка була на Протоколах ближче до кінця проекту - це отпимальний варіант.
5. Усі задачі девелопери отримують у вигляді специфікацій, в якій зокрема прописаний аксептен тест на той чи інший функціонал. Спецификації перед початком розроки узгоджуються з та підписуються клієнтом. Тобто ситуації коли, "ми мохіти це, це і от те, а ви зробили лише це і це" тут майже не проходять. Будь-які зміни до специфікації – це нова специфікація з усіма випливаючими наслідками :)
Кілька слів про структуру компанії. Наш офіс - не головний, тут лише девелопери та тестери, які займаються проектами для Healthcare. Начальство далеко - це 6-ий плюс :) Головний у нас Стів, крім нього ще є тім лідери, по одному на проект, тобто аж два.
Як довго я хочу тут працювати, ще не вирішив. Принаймні до літа, якщо не виженуть :)
Вибачайте, на цей раз без фоток, хоча ви можете глянути як офіс виглядає зовні тут. Але обов'язково сфотографую офіс та колег.
Вже минуло майже 4-ри місяці, як я працюю на компанію Capula, тому можна підводити деякі проміжні підсумки. Загалом, ситуація нічим не краща, ніж у звичайній українській компанії середньої руки - 40-50 чоловік безпосередньо технічного персоналу.
В тексті згадуються декілька проектів, в яких я брав участь в Україні: Ексім в Прікомі та Протоколи в Афортіо.
Негативи:
1. Не має нормального environment'а. Тобто bug-tracker написаний самотужки, ціла низка Excel'ьних файлів з результатами тестування і т. п. неподобства.
2. Постійні проблеми з контролем версій, релізами, патчами. Існує лише дві людини, які знають або приймаю рішення що, коли і в який бранч попаде. Якщо раптом їх не має в офісі, настає легкий ступор в роботі:) До того ж, БД частину лише нещодавно перевели на CVS. Не уявляю як вони до цього працювали?! Щоб вам було легше оцінити маштаб трагедії, наведу декілька параметрів системи: кількість таблиць - 1073, спільки ж PL/SQL пекеджів :) Ніхто вже достеменно не знає, що й для чого використовується.. Це до речі, ще не найстрашніша сутиація. Мій друг, теж Java програміст, намагається пролобіювати впровадження Subversion, а то вони мержать бранчі вручну. Чим займається його компанія не скажу, щоб не псувати вам позитивне уявлення про розвинутий "ке-пі-та-лізм", як казав А.Шварцеафро-американець.
3. Загальна проблема з формалізацією процедур. Як фіксити баги, еплаїти пачі, називати бранчі та теги і т.д. Тобто п. 2 в квадраті. Правда є внутрішня WiKi, але там далеко не вся інформація. До того ж ніхто окремо нею не займається. От як у тебе є бажання і час туди щось написати, то пиши. Але ж загально відомо, що програмісти - то ще ті ледарі! :)
4. Власне проект, в якому я працюю - це веб фронт-енд для старої та велекої системи, написаної на Oracle Forms. Тобто половина бізнес логіки "зашита" в PL/SQL код. Це звичайно ж сподобалось б Юрчику Когуну, але якщо взяти до уваги пп. 2-3, і той факт, що над PL/SQL кодом в нашому проекті працює лише півтора чоловіка на 5 Java програмістів, то ситуація зовсім невтішна. Навіть не враховуючи явні недоліки та обмеження такої архітектури.
5. Тестування.. Продукт вже проданий 5-м клієнтам, у яких стоять різні версії, і в кожного з них є свої фіча-ріквести. Пп. 2-3 ускладнються підтримкою, баг-фіксом та тествуванням різних версій. Unit тестування відсутнє як явище.
Позитиви:
1. Оскільки продукт є чимось середнім між замовним та "з коробки" (out-of-the-box), у кожного клієнта паралельно підняті дві хардварні платформи - testing та live. На кожній платформі інстальовано по дві копії системи: QA та Training на testing, QA та Live на live. Перед тим як потрапити на live, нова версія тестується клієнтом на testing платформі.
2. Дедлайни не такі страшні, як були колись з Ексімом або Протоколами, тому що реліз спочатку іде на тестову платформу.
3. Щотижня наш мнеджер - Стів (100% інгліш)- проводить тім мітінг. Збираються усі і почерзі розказують, чим вони зараз займяються. Це дуже позитивна штука. Мені, наприклад, вона допомогла запам'ятати імена тих, з ким працюю :) Ну і звичайно бути в курсі "куди йдемо, за що боремося".
4. Тестування.. Власне є тестування самими девелоперами, тестерами та безпосередньо самим клієнтом. HEAD та інші основні бранчі перезбираються кожної ночі (nightly build), тому дозволяється комітити лише працюючий код. Це звичайно впливає на якість кінцевого продукту. Але є одне "але". Час, який може пройти від розробки до отримання
помилки від клієнта, може сягати кількох тижнів або навіть місяців. Тому, щоб виправити такий баг іноді потрібно витрати стільки ж часу як і на сам девелопмент. До того ж це дратує... інколи :) Але не будемо про погане. Як на мене, то процедура тестування, яка була на Протоколах ближче до кінця проекту - це отпимальний варіант.
5. Усі задачі девелопери отримують у вигляді специфікацій, в якій зокрема прописаний аксептен тест на той чи інший функціонал. Спецификації перед початком розроки узгоджуються з та підписуються клієнтом. Тобто ситуації коли, "ми мохіти це, це і от те, а ви зробили лише це і це" тут майже не проходять. Будь-які зміни до специфікації – це нова специфікація з усіма випливаючими наслідками :)
Кілька слів про структуру компанії. Наш офіс - не головний, тут лише девелопери та тестери, які займаються проектами для Healthcare. Начальство далеко - це 6-ий плюс :) Головний у нас Стів, крім нього ще є тім лідери, по одному на проект, тобто аж два.
Як довго я хочу тут працювати, ще не вирішив. Принаймні до літа, якщо не виженуть :)
Вибачайте, на цей раз без фоток, хоча ви можете глянути як офіс виглядає зовні тут. Але обов'язково сфотографую офіс та колег.
Comments