" title="Написать письмо">Написать письмо

Статистика

Пользователи : 1
Статьи : 1630
Просмотры материалов : 6195026
 
Ограничение программиста теоретиками (09.09.2022). Печать E-mail
2022 - Сентябрь
09.09.2022 17:20
Save & Share
Ранее был опыт изучения профессии тестировщика - спустя десяток лет парадигма тестирования изменилась. Теперь тестировщики тестируют не только созданный, но и еще не созданный продукт - то есть, атакуют разработчика уже с двух сторон: до практической разработки и после. Выяснилось, что кроличья нора стала гораздо глубже.

Удалось попасть на курсы «Практики разработки ПО». Предполагая обучение технической составляющей при практической разработке ПО - столкнулся с теоретической частью до его разработки: бизнес-процессами. Выяснилось, что программиста теперь атакуют не только тестировщики.

В начале курсов это не было заметно. Изучались бизнес-процессы со стороны обоснования разработки ПО, организации работы подразделений различных размеров, составления блок-схем алгоритмов и взаимодействия сотрудников друг с другом внутри ПО. Когда пошло обучение разработке состава еще несуществующей БД SQL - создалась иллюзия, что началась реальная разработка ПО непосредственно программистом. Но когда начали изучаться описания классов и их зависимостей, пришло осознание: это не разработка ПО - это влезание теоретиков в практический процесс разработки ПО программистов.

Весь этот курс - это бизнес-процессы без практического программирования, несмотря на наличие слова «практики разработки» в названии курса. То есть, и блок-схема алгоритмов, и классы, и инфраструктура - это наиподробнейшее ТЗ для программиста, составляемое теоретиками.

В итоге, программисту на стол должны положить многостраничное ТЗ, в котором четко прописано множество процессов. Блок-схему алгоритмов работы ПО можно еще принять (есть пространство для технических маневров при решении реально возникающих проблем). Но когда тебе диктуют не просто состав базы SQL, а число классов во всем ПО - и только с такими свойствами и методами, только с такими названиями и взаимосвязями, private-public-protected - это надевание наручников на руки программиста. Такая реализация разработки ПО подходит для индусов - но не для творческого населения.

Невозможно сделать шаг влево или вправо. Все сущности формализованы, четко обозначены и подписаны руководителями разных подразделений. Создается иллюзия облегчения работы программиста (не нужно изготавливать блок-схему алгоритмов). Но на деле - это лишение программиста его творческой сущности и превращение его в кодера. Реализуя чужие хотелки, проникшие в его зону власти и лишившие возможности маневров, - трудоемкость практического создания ПО будет повышена (не говоря уже о дискомфорте при такой работе). Еще и зарплату уменьшат с демагогической формулировкой «за тебя половину работ другие сделали».

И, на примере блок-схемы алгоритмов: она перемещается из практической части (написанной по реальному коду) в теоретические хотелки (а хотелки всегда отличаются от реальности). И даже если разработчику разрешат делать шаги влево-вправо - ему придется каждый свой чих согласовывать с кучей подразделений, в т.ч. нетехнических, - т.к. это есть несоответствие ТЗ.

И будет происходить то же самое, что со службой безопасности: копается в чужом грязном белье и сует свой нос, куда не надо. И, естественно: изданные ими бредовые приказы с ограничениями - разработчиками ПО уже давно не выполняются. И вполне вероятно: когда теоретик придет к программисту и спросит, какого хрена в этом классе на одно свойство больше, - он будет просто послан.
Обновлено ( 09.09.2022 17:36 )
 
 

Последние новости


©2008-2022. All Rights Reserved. Разработчик - " title="Сергей Белов">Сергей Белов. Материалы сайта предоставляются по принципу "как есть". Автор не несет никакой ответственности и не гарантирует отсутствие неправильных сведений и ошибок. Вся ответственность за использование материалов лежит полностью на читателях. Размещение материалов данного сайта на иных сайтах запрещено без указания активной ссылки на данный сайт-первоисточник (ГК РФ: ст.1259 п.1 + ст.1274 п.1-3).

Много статей не имеет срока устаревания. Есть смысл смотреть и 2011, и даже 2008 год. Политика сайта: написать статью, а потом обновлять ее много лет.
Открыта карта ВТБ для материальной поддержки сайта: 5368 2902 0040 0838.

Рекламодателям! Перестаньте спамить мне на почту с предложениями о размещении рекламы на этом сайте. Я никогда спамером/рекламщиком не был и не буду!
Top.Mail.Ru