| Ограничение программиста теоретиками (09.09.2022). |
|
| 2022 - Сентябрь | |||
| 09.09.2022 17:20 | |||
Удалось попасть на курсы «Практики разработки ПО». Предполагая обучение технической составляющей при практической разработке ПО - столкнулся с теоретической частью до его разработки: бизнес-процессами. Выяснилось, что программиста теперь атакуют не только тестировщики. В начале курсов это не было заметно. Изучались бизнес-процессы со стороны обоснования разработки ПО, организации работы подразделений различных размеров, составления блок-схем алгоритмов и взаимодействия сотрудников друг с другом внутри ПО. Когда пошло обучение разработке состава еще несуществующей БД SQL - создалась иллюзия, что началась реальная разработка ПО непосредственно программистом. Но когда начали изучаться описания классов и их зависимостей, пришло осознание: это не разработка ПО - это влезание теоретиков в практический процесс разработки ПО программистов. Весь этот курс - это бизнес-процессы без практического программирования, несмотря на наличие слова «практики разработки» в названии курса. То есть, и блок-схема алгоритмов, и классы, и инфраструктура - это наиподробнейшее ТЗ для программиста, составляемое теоретиками. В итоге, программисту на стол должны положить многостраничное ТЗ, в котором четко прописано множество процессов. Блок-схему алгоритмов работы ПО можно еще принять (есть пространство для технических маневров при решении реально возникающих проблем). Но когда тебе диктуют не просто состав базы SQL, а число классов во всем ПО - и только с такими свойствами и методами, только с такими названиями и взаимосвязями, private-public-protected - это надевание наручников на руки программиста. Такая реализация разработки ПО подходит для индусов - но не для творческого населения. Невозможно сделать шаг влево или вправо. Все сущности формализованы, четко обозначены и подписаны руководителями разных подразделений. Создается иллюзия облегчения работы программиста (не нужно изготавливать блок-схему алгоритмов). Но на деле - это лишение программиста его творческой сущности и превращение его в кодера. Реализуя чужие хотелки, проникшие в его зону власти и лишившие возможности маневров, - трудоемкость практического создания ПО будет повышена (не говоря уже о дискомфорте при такой работе). Еще и зарплату уменьшат с демагогической формулировкой «за тебя половину работ другие сделали». И, на примере блок-схемы алгоритмов: она перемещается из практической части (написанной по реальному коду) в теоретические хотелки (а хотелки всегда отличаются от реальности). И даже если разработчику разрешат делать шаги влево-вправо - ему придется каждый свой чих согласовывать с кучей подразделений, в т.ч. нетехнических, - т.к. это есть несоответствие ТЗ. И будет происходить то же самое, что со службой безопасности: копается в чужом грязном белье и сует свой нос, куда не надо. И, естественно: изданные ими бредовые приказы с ограничениями - разработчиками ПО уже давно не выполняются. И вполне вероятно: когда теоретик придет к программисту и спросит, какого хрена в этом классе на одно свойство больше, - он будет просто послан. |
|||
| Обновлено ( 09.09.2022 17:36 ) |