Я працюю над невеликою командою в середній компанії, більшість з яких не займається розробкою програмного забезпечення. Я найновіший і найменш досвідчений розробник і не мав професійного чи академічного досвіду програмного забезпечення перед початком роботи, але я дуже задоволений тим, наскільки поважаю мій внесок, і я вдячний за те, що на такому ранній стадії моєї кар’єри сприйняли серйозно.
І все-таки я відчуваю, що мені слід більше займатися цією великою кількістю ефірного часу. Як команда, ми, мабуть, маємо проблеми з виконанням справ. Мені б хотілося запропонувати щось покращити ситуацію, і я думаю, що мене слухали б, якщо це була гарна ідея, але я втрачаю те, що запропонувати.
Що я можу визначити як проблеми, це:
- Специфікація завдань, що є у вас, є рідкою. Частково це пояснюється тим, що управління - це вузьке місце, і у нас немає грошей чи людей, щоб взяти на себе зобов’язання розробити детальні вимоги настільки, наскільки ми хотіли б. Це також частково тому, що програмне забезпечення, яке ми розробляємо, є слідчим і точний метод не зрозумілий, поки його не продемонструють та не використають для визначення його ефективності.
- Ведучий Dev дуже любить те, що він називає «прототипуванням» до того, що останнім часом він наполягає на тому, що все є «прототипом», що для решти з нас виглядає як написання поганого коду та надання його моделерам, щоб грати. Не ясно, що він очікує, що у багатьох випадках вийде з цієї вправи. Тоді реальна реалізація страждає через його наполягання на тому, що добра практика вимагає занадто багато часу від складання прототипів. Мені навіть не вдалося розплутати цю скручену логіку, і я не впевнений, що хочу спробувати.
- Очікується, що модельєри розкажуть нам все про бажану методологію докладно, і вона бере на себе абсолютну довіру, що те, з чим вони виходять, теоретично бездоганне. Це навряд чи вірно, але не вживаються заходи для виправлення цієї ситуації. Ніхто з боку моделювання не викликає жодних занепокоєнь структурованим способом, який, ймовірно, буде діяти, і не шукає рекомендацій щодо застосування кращих практик. Нічого не робиться і щодо їх пасивності.
- Я раніше намагався підштовхнути TDD до команди, але мені було важко, оскільки це для мене нове, і хоча ті, хто наглядає за моєю роботою, готові були це терпіти, ентузіазму ніхто не викликав. Я не можу виправдати кількість часу, який я витрачаю на валяння та не доопрацьовуючи функції, тому від цієї ідеї поки що відмовилися. Я стурбований, що його знову не візьмуть, бо ніхто не любить, щоб йому говорили, як робити свою роботу.
- Зараз у нас є сервер безперервної інтеграції, але він використовується в основному лише для запуску багатогодинних тестів регресії. Залишилося відкритим, що він також повинен працювати з блоком повного покриття та інтеграційними тестами, але наразі їх ніхто не пише.
- Кожен раз, коли я піднімаю питання про якість провідного розробника, я отримую відповідь про те, що "Тестова функція A є простою, функція B набагато важливіша для користувача, але занадто складна для тестування, тому ми не повинні тестувати функцію A '. Ще раз я не зробив жодного пробігу, намагаючись розплутати цю логіку.
.... феу. Коли я його так фразую, це виглядає набагато гірше, ніж я думав. Я гадаю, як виявляється, це крик про допомогу.
5
Наскільки хороша компанія у витісненні програмного забезпечення, яке користується клієнтом і подобається? Іншими словами, чи отримує команда хороші результати, незважаючи на те, що ви не вірите, що процес є зоряним?
—
Роберт Харві
@Robert Harvey - Мені важко судити. Продукти надзвичайно ніші, і ми (розробники) отримуємо неоднозначні повідомлення. З одного боку, нові клієнти на проривних ринках виштовхують товар більше, ніж ми спочатку передбачали, і виявляємо помилки як наслідок, чого вони, мабуть, не проти, оскільки ми пояснюємо, чому і швидко їх виправляємо. З іншого боку, деякі великі інституційні замовники з недовірою ставляться і ми починаємо брати участь у неодноразових змінах моделі. Команда програмного забезпечення є однією з небагатьох, хто працює навіть в компанії на даний момент, тому ми виглядаємо добре на даний момент .
—
Том Ш
Я б попросив якомога більше відгуків від клієнтів щодо способів домовитись про основну робочу "модель" і спробувати це трохи затвердити. Клієнтам це дійсно може неприємно змінити модель, але якщо це нове, передове програмне забезпечення, воно йде з територією.
—
Роберт Харві
Хороше питання. Я помітив, що навіть із сприйнятливою аудиторією реальні зміни важкі, якщо ви не побачите, як це працює на практиці. Моя порада спробувати спробувати підходи до підвищення продуктивності спочатку, а потім продемонструйте їх команді. З практикою ви можете отримати швидший розвиток TDD, ніж писати / налагоджувати / повторювати.
—
Майк Б