По-перше, я усвідомлюю, що це питання може бути дещо довгим і невиразним, і вибачаюся за це. Це, мабуть, основна проблема короткого імені для кожного, хто його "отримав", але, як мені здається, не вистачає цього питання, будь ласка, майте на увазі опис проблеми.
Я займаюся програмуванням таким чи іншим способом ще з 11 років. Це означає, що я здебільшого навчаю себе все з самого початку. Я отримав технічну освіту, але не суворо з комп’ютерних наук (я закінчив ступінь за спеціальністю "Фотонна інженерія"). У нас, звичайно, були курси програмування, але це були в основному для мене речі, і я не навчився багато нового. Я продовжував навчати себе на радість від цього і завжди знав, що буду продовжувати кар’єру в галузі програмування, але всі мої проекти були на той час зовсім маленькими. Я не мав проблем утримувати їх у думці та підтримувати їх.
Тепер я вважаю себе лідером у команді, але не в корпоративному середовищі - працюю в університеті, розробляючи наукове програмне забезпечення (в С ++) для інженерних застосувань. Раптом проект стає (відносно) великим, і я маю проблеми з обгортанням своєї думки навколо нього більшу частину часу. Я втрачаю багато часу і сил на дві речі:
- Коли мені доводиться повертатися до розділу коду, над яким я не працював деякий час, мені важко згадати, як він працював. Я витрачаю багато часу на перегляд файлів заголовків для відповідних класів та читання коментарів, які я розміщував попутно у вихідних файлах. Мені б хотілося, щоб була якась форма «схематичної», яку я міг би легше побачити і відновити картину;
- Коли я ввожу зміни, іноді я усвідомлюю, що те, що я намагаюся зробити, порушить десь інше (або ще гірше, воно з’являється лише під час виконання, як несподіванка). Я повертаюся і починаю робити це по-іншому, лише щоб дізнатися, що я знехтував впливом на якийсь інший компонент. Мені б хотілося, щоб була якась "діаграма архітектури", де я міг би бачити, як все робиться, як те, що я намагаюся зробити, впливатиме на інші компоненти та спосіб детально планувати, перш ніж розпочати впровадження змін.
Більшість людей, з якими я працюю, мають подібні історії, як і мої власні - сильна технічна спрямованість та інколи чудові навички, але ніякого способу організації їх роботи. Однак їхні проекти зазвичай набагато менші, ніж мої, тому вони якось справляються. У будь-якому разі, що для мене це означає, що я самостійно і у мене немає від кого вивчити хороші практики.
Я взяв аспірантуру з управління ІТ, і хоча мені здається, що це цілком задовольняє, він переважно орієнтований на непрограмістів, викладає про методології управління проектами, оцінки бюджету / розкладу, архітектури підприємства тощо - не дизайн програмного забезпечення та планування як таке. Це добре, я намагаюся навчитися також цього. Звичайно, були введені деякі інструменти (на зразок UML) та типи процесів розробки програмного забезпечення (каскад, ітеративний, спритний ...), але, очевидно, не дуже детально, і я важко вирішую, що мені вибрати та використовувати ( і в якій мірі).
Я читав багато запитань та відповідей щодо розробки програмного забезпечення на SO - є багато про те, як це зробити за допомогою того чи іншого конкретного інструменту чи методології, і якби я був впевнений, що документація UML вирішить мої проблеми - я підберу її та почати його використовувати. Але деякі присягаються, інші кажуть, що це марно. Я шукаю відповідь на більш високий рівень абстракції - чи є способи вирішити дві проблеми, які у мене є, і як ви особисто це робите? Що я повинен навчитися робити це, можливо, не прив'язуючись до якогось конкретного інструменту? Час від часу вони виходять із стилю, і я очікую, що їх застосовність змінюється залежно від типу проекту.
Велике спасибі за прочитане, я не зміг сказати, що я маю на увазі коротше (бракує досвіду розробки програмного забезпечення та словника).