История, типичная для растущего программиста. "Болезнь роста" называется. Создание программ — производственный процесс, зачастую превращаемый программистом в творческий. Это порождает конфликты. Проблемы те же, что были 30 лет назад у тогдашних девелоперов. По опыту общения с программистами мэйнстримов в крупных госконторах знаю, что все примочки, а также "волшебные палочки", многократно ускоряющие разработки, тесты ПО, контрольные примеры и т.д. и т.п. (фактически, инструментарий девелопера), разрабатываются в свободное от работы время. Профессионалам это знакомо. Ну, а производственный процесс — это священная корова и ею рисковать нельзя.
При разработке важно охватить разнообразие входящей информации, классифицировать ее на типы, и эта классификация неизбежно отразится на внутренней структуре ПО. Отсюда обобщение кода и типизация идут на последующих этапах. Об этом многие тут писали.
Крик души авторов де факто посвящен их попытке оптимизации кода параллельно с разработкой, чего делать нельзя. И это опять же болезнь роста девелопера. Надо было идти дальше — писать говнокод, но разбивать его на модули/либы с мыслью последующей замены их на более продвинутые.
Надо было задуматься о ОТДЕЛЬНОЙ разработке новой системы, которую можно было бы по частям использовать в работе над похожими проектами или над этим же, но на последующих этапах. Об этом тоже здесь писали.
В общем этот случай очень напоминает историю "разностной машины" Бэббиджа, которая так и не была построена полностью.
И напоследок пару почти анекдотов о говнокоде. В 90е годы шла дискуссия в компьютерных изданиях о том, на каких языках лучше писать прикладное ПО. Несмотря на приоритет С во множестве мнений, помню автора, который писал, что ПО для решения множества задач (того времени), связанных с базами данных, он многократно разрабатывал на одном из диалектов BASIC и клиента это полностью устраивало.
И еще был свидетелем удивления заказчика, нацеленного на красивую, большую программу с навороченным интерфейсом, когда оказалось, что задача, поставленная им, легко и быстро (за 1-2 вечера за счет времени отдыха, поскольку основную работу никто не отменял) решилась разработкой таблицей Excel с той же функциональностью.
Мораль: 1 — производственный процесс надо уважать, как и лидов и манагеров всех уровней; 2 — ОЧЕНЬ СИЛЬНО ценить полученные возможности по доступу к разнообразию входной информации, чего никто и ни при каких обстоятельствах не будет иметь, находясь ВНЕ организации заказчика (именно этот доступ дает возможность учиться девелоперу); 2 — все примочки делать ТОЛЬКО в личное время; 3 — не афишировать заранее и не манить лидов и менеджеров еще не выращенной морковкой; 4 — тем временем структурировать говнокод под свои будущие магические софтгаджеты и либы; 5 — главное, чтобы говнокод, пусть даже временный, работал НАДЕЖНО — это устроит всех, потому что магическая "кухня" девелопера со всяческими чудесами, на самом деле нужно ТОЛЬКО ему, что ускорить разработку похожих задач; 6 — говнокод не приносит ощущения собственной гениальности, элитарности, но может сильно экономить время, которое можно потратить на: а) творчество; б) на доп. подработку; 7 — описанные хождения авторов по мукам на самом деле относятся к оптимизации, а место оптимизации д.б. не первым; 8 — код, написанный однажды, не должен уничтожаться ни при каких..., а должен тщательно документироваться и складываться в архив (никто не знает, что будет потом — приходилось возвращаться к старым находкам, чтобы ускорить новые разработки); 9 — как многие писали, код должен решать поставленные задачи, но не быть избыточным, и это касается и внутренней структуры кода и его внутренней функциональности. В самом деле лучшее враг хорошего
Опять же ошибка роста. Но общеизвестно, кто именно никогда не ошибается.
Совершенно согласен с Вашим резюме
История, типичная для растущего программиста. "Болезнь роста" называется. Создание программ — производственный процесс, зачастую превращаемый программистом в творческий. Это порождает конфликты. Проблемы те же, что были 30 лет назад у тогдашних девелоперов. По опыту общения с программистами мэйнстримов в крупных госконторах знаю, что все примочки, а также "волшебные палочки", многократно ускоряющие разработки, тесты ПО, контрольные примеры и т.д. и т.п. (фактически, инструментарий девелопера), разрабатываются в свободное от работы время. Профессионалам это знакомо. Ну, а производственный процесс — это священная корова и ею рисковать нельзя.
При разработке важно охватить разнообразие входящей информации, классифицировать ее на типы, и эта классификация неизбежно отразится на внутренней структуре ПО. Отсюда обобщение кода и типизация идут на последующих этапах. Об этом многие тут писали.
Крик души авторов де факто посвящен их попытке оптимизации кода параллельно с разработкой, чего делать нельзя. И это опять же болезнь роста девелопера. Надо было идти дальше — писать говнокод, но разбивать его на модули/либы с мыслью последующей замены их на более продвинутые.
Надо было задуматься о ОТДЕЛЬНОЙ разработке новой системы, которую можно было бы по частям использовать в работе над похожими проектами или над этим же, но на последующих этапах. Об этом тоже здесь писали.
В общем этот случай очень напоминает историю "разностной машины" Бэббиджа, которая так и не была построена полностью.
И напоследок пару почти анекдотов о говнокоде. В 90е годы шла дискуссия в компьютерных изданиях о том, на каких языках лучше писать прикладное ПО. Несмотря на приоритет С во множестве мнений, помню автора, который писал, что ПО для решения множества задач (того времени), связанных с базами данных, он многократно разрабатывал на одном из диалектов BASIC и клиента это полностью устраивало.
И еще был свидетелем удивления заказчика, нацеленного на красивую, большую программу с навороченным интерфейсом, когда оказалось, что задача, поставленная им, легко и быстро (за 1-2 вечера за счет времени отдыха, поскольку основную работу никто не отменял) решилась разработкой таблицей Excel с той же функциональностью.
Мораль: 1 — производственный процесс надо уважать, как и лидов и манагеров всех уровней; 2 — ОЧЕНЬ СИЛЬНО ценить полученные возможности по доступу к разнообразию входной информации, чего никто и ни при каких обстоятельствах не будет иметь, находясь ВНЕ организации заказчика (именно этот доступ дает возможность учиться девелоперу); 2 — все примочки делать ТОЛЬКО в личное время; 3 — не афишировать заранее и не манить лидов и менеджеров еще не выращенной морковкой; 4 — тем временем структурировать говнокод под свои будущие магические софтгаджеты и либы; 5 — главное, чтобы говнокод, пусть даже временный, работал НАДЕЖНО — это устроит всех, потому что магическая "кухня" девелопера со всяческими чудесами, на самом деле нужно ТОЛЬКО ему, что ускорить разработку похожих задач; 6 — говнокод не приносит ощущения собственной гениальности, элитарности, но может сильно экономить время, которое можно потратить на: а) творчество; б) на доп. подработку; 7 — описанные хождения авторов по мукам на самом деле относятся к оптимизации, а место оптимизации д.б. не первым; 8 — код, написанный однажды, не должен уничтожаться ни при каких..., а должен тщательно документироваться и складываться в архив (никто не знает, что будет потом — приходилось возвращаться к старым находкам, чтобы ускорить новые разработки); 9 — как многие писали, код должен решать поставленные задачи, но не быть избыточным, и это касается и внутренней структуры кода и его внутренней функциональности. В самом деле лучшее враг хорошего
Опять же ошибка роста. Но общеизвестно, кто именно никогда не ошибается.