Что за подстава! Мяса-то и нет! Кожа, а потом сразу скелет в слоях. Я только хотел получить теоретическую подготовку в разделке туш… Эх… Придётся вернуться к привычному Google Body…
Эта статья, если Вы, вдруг, не заметили, учит думать. И это не просто пустая болтовня. Вы думаете, я долго сидел и высасывал из пальца «о чём бы написать»? Нет. Я взял реальный пример из жизни, с которым неоднократно сталкивался. И я рассказал ровно то, что я говорю своей команде, чтобы они поняли всю неприглядность такого подхода.
Более того, чтобы развеять остатки сомнения, Скажу: я — практик и мало верю теориям и шарообразным коням. И этот подход я повсеместно применяю этот подход на практике и воспитал уже ни одного классного специалиста.
Что касается «идеального кода». Вы опять сводите к «коду». Код — это самый нижний уровень, это буквы и строчки. Читая чужой код, можно научиться хорошо копировать. Научиться принимать правильные архитектурные решения, подходящие для Вашей конкретной задачи, глядя на чужой код крайне сложно. И в любом случае для этого надо думать.
Кстати, заметьте: заявления различных людей типа «пишу плохо, но все остальные ещё хуже. И вообще, один умный дядька говорил. что писать плохо — это нормально» — показатель непрофессионализма и отсутствия желания расти.
Ну, я надеюсь, что у таких молодых и горячих голов найдутся здравые и трезвые руководители, которые, собственно, за проект отвечают, и которые смогут донести настоящие ценности. Впрочем, всякое, конечно, бывает в жизни. Бывают, к сожалению, и «самоорганизующиеся» команды. Причём — далеко не самым лучшим образом.
Не, ну уж насчёт испорченных телефонов Вы перегнули :). Если Вы работаете один над каким-то только вам известным проектом — это нормально. Но более-менее серьёзный проект тяжело без ПМа вести. Хороший руководитель проекта — это член команды разработки, а не очередная цепочка в бюрократии.
Получается, что Вы сами взаимодействуете с заказчиком? Т.е. сами себе ПМ? В этом случае я могу только пожелать Вам удачи в поисках заказчиков, которые соглашаются на ваши сроки. Это — главное.
А сроки на разработку той или иной фичи Вы сами указываете? Вы их как-то обосновываете? Почему-то кажется, что в вашем случае это реальная проблема. Я прав?
Может быть, я неправильно выразился. Мелкой и незначительной с точки зрения влияния на продукт, но достаточно объёмной с точки зрения объёма работы. Я ни в коем случае не говорю, что ошибки исправлять вообще не нужно :).
А приоритеты — обязательны. Без них просто нельзя организовать нормальную работу. Собственно, я говорю о том, что иногда приходится жертвовать исправлением мелких недоработок в пользу движения продукта вперёд. У меня создалось впечатление, что мы с Вами как раз говорим об одном и том же. Нет?
Красивый код — это, на мой взгляд, один из основных критериев «живучести» ПО. Действительно, чёткая архитектура и аккуратный код обычно ведут к лёгкому пониманию и критическому увеличению скорости исправления ошибок и добавления новых функций.
Но это говорит не о том, что ошибок нет. Это говорит о том, что большинство ошибок легко исправить.
> Если пользователь сообщил вам об ошибке, вы не будете ее фиксить?
Не всегда, к сожалению. Мир не идеален и очень часто приходится выбирать между исправлением мелкой и незначительной ошибки и добавлением нужной функции, например. IRL очень часто из двух зол приходится выбирать меньшее.
С огромным уважением отношусь к таким исследованиям. Но исключительно с академической точки зрения. Выражения «при стремлении времени разработки к бесконечности число ошибок стремится к нулю» меня как практика ну совершенно не устраивают :).
Разработка ПО для шаттлов — как раз хороший пример ПО, для которого понятие «достаточно хорошее» фактически сливается с понятием «идеальное». Как я уже говорил в тексте, при этом применяются совершенно другие подходы и методики (о чём, собственно, в приведённой статье и написано).
Я бы сказал, что в этом случае, вероятно, хорош код системы. Сама система, к сожалению, при этом может нещадно глючить и пугать пользователей отвратительным юзабилити.
Это точно. Проблема, как всегда, в деталях:
* что такое «хак»?
* как определяется «общая архитектура»?
Ну и этих факторов, конечно же не достаточно. Но, в общем, критерии «достаточно хорошего кода» сильно бы помогли. Впрочем, выработать их — очень непростая задача и зависит от конкретного продукта / проекта.
Конечно не только из одного стремления к красоте. Разумный рефакторинг — это жизненно важный шаг в процессе разработки.
Я говорю именно о «неразумном» шлифовании. Когда код пишется ради кода, а архитектура создаётся ради архитектуры. К сожалению, это встречается сплошь и рядом среди программистов. Особенно — среди хороших программистов с горящими глазами, которые увлечены своим делом.
Более того, чтобы развеять остатки сомнения, Скажу: я — практик и мало верю теориям и шарообразным коням. И этот подход я повсеместно применяю этот подход на практике и воспитал уже ни одного классного специалиста.
Что касается «идеального кода». Вы опять сводите к «коду». Код — это самый нижний уровень, это буквы и строчки. Читая чужой код, можно научиться хорошо копировать. Научиться принимать правильные архитектурные решения, подходящие для Вашей конкретной задачи, глядя на чужой код крайне сложно. И в любом случае для этого надо думать.
Кстати, заметьте: заявления различных людей типа «пишу плохо, но все остальные ещё хуже. И вообще, один умный дядька говорил. что писать плохо — это нормально» — показатель непрофессионализма и отсутствия желания расти.
А приоритеты — обязательны. Без них просто нельзя организовать нормальную работу. Собственно, я говорю о том, что иногда приходится жертвовать исправлением мелких недоработок в пользу движения продукта вперёд. У меня создалось впечатление, что мы с Вами как раз говорим об одном и том же. Нет?
Но это говорит не о том, что ошибок нет. Это говорит о том, что большинство ошибок легко исправить.
> Если пользователь сообщил вам об ошибке, вы не будете ее фиксить?
Не всегда, к сожалению. Мир не идеален и очень часто приходится выбирать между исправлением мелкой и незначительной ошибки и добавлением нужной функции, например. IRL очень часто из двух зол приходится выбирать меньшее.
* что такое «хак»?
* как определяется «общая архитектура»?
Ну и этих факторов, конечно же не достаточно. Но, в общем, критерии «достаточно хорошего кода» сильно бы помогли. Впрочем, выработать их — очень непростая задача и зависит от конкретного продукта / проекта.
Я говорю именно о «неразумном» шлифовании. Когда код пишется ради кода, а архитектура создаётся ради архитектуры. К сожалению, это встречается сплошь и рядом среди программистов. Особенно — среди хороших программистов с горящими глазами, которые увлечены своим делом.