varan
Б̈́̈̽ͮͣ̈Л̩̲̮̻̤̹͓ДͦЖ̯̙̭̥̑͆А͇̠̱͓͇̾ͨД͙͈̰̳͈͛ͅ
Где грань между гибкостью кода и скоростью разработки?
(Это только мысли, и не в коем случае не пропаганда чего либо или против чего либо)
Всегда ли надо делать из говнокода конфетку? Рефакторинг, TDD, паттерны-антипаттерны, красивая документация, Q&A etc
Возьмем, к примеру, перманентный рефакторинг: как только появляется плохой запах кода, переделываем, чтобы не воняло. Вроде бы всё круто, код получается отличный, но не страдает ли от этого бизнес?
Грубо говоря, на рефакторинг тратится время, которое можно было бы использовать на новый функционал.
Т.е. рефакторинг всего = деньги тратятся на з/пл и не зарабатываются на новом функционале. Двойной удар, так сказать.
Общее мнение, насколько я понимаю, что, мол, если не допускать говнокод, то в будущем время на доработку нового функционала уменьшится, чем гибче тем лучше, чем меньше зависимостей тем лучше.
Но:
1) Время на доработку в будущем может стоить дешевле времени на доработку сейчас. Я имею в виду, можно сейчас заработать деньги, нанять на эти деньги программистов, и тогда в будущем больше программистов будет трудится над говнокодом
И им вдесятером будет легче разгребать старинный говнокод, чем в одиночку править суперкод. К тому же первичные говнокодеры бизнесу обойдутся дешевле.
2) Для многих стартапов жизненно важно выйти на рынок как можно быстрее любой ценой, пока конкуренты тормозят.
2) Х.з. что там будет, в этом будущем, может полная отмена проекта? Отмена половины фич проекта? Нашествие инопланетян?
3) Мы не знаем, какая именно гибкость кода понадобится в будущем, а какая пролежит без дела. Т.е. "гибкость всего" гарантированно содержит лишние действия. Например, мы пишем прослойку к БД, чтобы поддерживать несколько СУБД, а это оказалось не актуально для рынка продукта. Или модуль к чему либо написан один раз, хорошо работает, и его год никто не трогал, хотя он гибкий-перегибкий.
Те же самые рассуждения про TDD. Я уж не говорю про любителей складывать 2 и 2, используя 10 паттернов для крутости.
Эти рассуждения разумеется не применимы к фреймворкам, там все должно быть идеально, ибо это их суть. Также они наверно не применимы к разработкам программ для какого-нибудь лунохода, где каждая ошибка может стоить слишком дорого.
В общем, вот мои мысли, возможно я не прав:
1) Надо рассматривать каждый конкретный проект отдельно, а не применять все известные технологии, просто потому, что умеешь.
2) Для многих проектов нужно быстро, топорно и с некоторыми ошибками сделать первую версию, не заморачиваясь, а уже потом спокойно рефакторить, абстрагировать, добавлять юнит-тесты, документацию и проч.
Microsoft раз за разом выпускает винды с багами, а уже потом шлифует напильником. Не ждет конкурентов.
3) Возможен и другой подход: рефакторить но не всё. Т.е. если для примера рассматривать какую-нибудь говноцмс, то в ней можно идеально проработать интерфейс модулей и интерфейс ядра. А вот на реализацию конкретных модулей можно потратить меньше времени. А уж какие-то части модулей можно писать хоть как.
4) Есть еще и такой аспект, как мотивация. Мне, например, противно дорабатывать говнокод. Такие вещи тоже надо как-то учитывать... Даже если всё, что я написал выше, близко к истине, то налицо конфликт между интересами программера и бизнеса.
В общем, что думаете? Может, у меня сегодня воспаление мозга?
Кстати, прошу быть позитивными и не флудить
(Это только мысли, и не в коем случае не пропаганда чего либо или против чего либо)
Всегда ли надо делать из говнокода конфетку? Рефакторинг, TDD, паттерны-антипаттерны, красивая документация, Q&A etc
Возьмем, к примеру, перманентный рефакторинг: как только появляется плохой запах кода, переделываем, чтобы не воняло. Вроде бы всё круто, код получается отличный, но не страдает ли от этого бизнес?
Грубо говоря, на рефакторинг тратится время, которое можно было бы использовать на новый функционал.
Т.е. рефакторинг всего = деньги тратятся на з/пл и не зарабатываются на новом функционале. Двойной удар, так сказать.
Общее мнение, насколько я понимаю, что, мол, если не допускать говнокод, то в будущем время на доработку нового функционала уменьшится, чем гибче тем лучше, чем меньше зависимостей тем лучше.
Но:
1) Время на доработку в будущем может стоить дешевле времени на доработку сейчас. Я имею в виду, можно сейчас заработать деньги, нанять на эти деньги программистов, и тогда в будущем больше программистов будет трудится над говнокодом
И им вдесятером будет легче разгребать старинный говнокод, чем в одиночку править суперкод. К тому же первичные говнокодеры бизнесу обойдутся дешевле.2) Для многих стартапов жизненно важно выйти на рынок как можно быстрее любой ценой, пока конкуренты тормозят.
2) Х.з. что там будет, в этом будущем, может полная отмена проекта? Отмена половины фич проекта? Нашествие инопланетян?
3) Мы не знаем, какая именно гибкость кода понадобится в будущем, а какая пролежит без дела. Т.е. "гибкость всего" гарантированно содержит лишние действия. Например, мы пишем прослойку к БД, чтобы поддерживать несколько СУБД, а это оказалось не актуально для рынка продукта. Или модуль к чему либо написан один раз, хорошо работает, и его год никто не трогал, хотя он гибкий-перегибкий.
Те же самые рассуждения про TDD. Я уж не говорю про любителей складывать 2 и 2, используя 10 паттернов для крутости.
Эти рассуждения разумеется не применимы к фреймворкам, там все должно быть идеально, ибо это их суть. Также они наверно не применимы к разработкам программ для какого-нибудь лунохода, где каждая ошибка может стоить слишком дорого.
В общем, вот мои мысли, возможно я не прав:
1) Надо рассматривать каждый конкретный проект отдельно, а не применять все известные технологии, просто потому, что умеешь.
2) Для многих проектов нужно быстро, топорно и с некоторыми ошибками сделать первую версию, не заморачиваясь, а уже потом спокойно рефакторить, абстрагировать, добавлять юнит-тесты, документацию и проч.
Microsoft раз за разом выпускает винды с багами, а уже потом шлифует напильником. Не ждет конкурентов.
3) Возможен и другой подход: рефакторить но не всё. Т.е. если для примера рассматривать какую-нибудь говноцмс, то в ней можно идеально проработать интерфейс модулей и интерфейс ядра. А вот на реализацию конкретных модулей можно потратить меньше времени. А уж какие-то части модулей можно писать хоть как.
4) Есть еще и такой аспект, как мотивация. Мне, например, противно дорабатывать говнокод. Такие вещи тоже надо как-то учитывать... Даже если всё, что я написал выше, близко к истине, то налицо конфликт между интересами программера и бизнеса.
В общем, что думаете? Может, у меня сегодня воспаление мозга?
Кстати, прошу быть позитивными и не флудить
рефакторинг, юниттесты, время на доработки оптимизацию ? хорошее место работы у вас 
