Easy vs Simple или Подумал, Решил, Записал
21.06.2014
|
Pauel
 |
Регулярно возникают темы про качество кода, потому решил изложить кое что. Часто бывает такая ситуация — архитект-лид на любой вопрос отвечает чтото навроде "Тут всё просто". Другие возможные варианты ответов находятся ниже. Особенно доставляют любители аджыле, оголтелой, тотальной функциональщины и разных баззвордов. "тут всё просто" — и объяснить, что именно просто, никто, как правило, не может. По этой причине в ход идет контр-аргумент в духе "А что непонятно ?".
По моему мнению некачественный код получается по в основном по двум причинам
1. малые сроки-бюджеты и/или жесткое давление менеджмента
2. меняются требования часто и непредсказуемо
3. страх, то есть ответственные лица, лиды-архитекты, не хотят подумать и ищут оправдания
Первое и второе есть всегда, а вот третье это особенность конкретных исполнителей. Список оправданий может занять места с целую библиотеку, поэтому ограничусь своим Топ-10
1. тут всё просто/сложно
2. надо сделать всё сейчас, иначе возможности больше не будет
3. а мы так решили
4. это правильно/неправильно
5. мы потом отрефакторим/переделаем/исправим
6. здесь будет синглтон
7. надо сначала сделать(, а думать будем потом)
8. за полгода нам нужно сто-дести-триста фич сделать
9. пусть будет на всякий случай
10. мы соптимизировали на 200мс, остальные 3 секунды(минуты) надо профайлить
Такое ощущение, что люди почему то считают, будто на самом деле любой ситуации есть основная вилка примерно такая
1. Быстро == как нибудь
2. Хорошо == полгода на любую фичу
На мой взгляд, лучше подходить с точки зрения easy vs simple
1. easy
2. simple
Фокус в том, что easy != simple. В русском языке люди любят заменять эту вилку одним словом "просто".
easy это любой код, который только пришел в голову, т.е. обкладываем костылями по мере необходимости.
Этот вариант в принципе ничего, кроме сложной системы костылей, подпорок и веревочек дать не может. Зато не требует времени на обдумывания. В долгосрочной перспективе это конские издержки вплоть до смерти проекта.
simple требует времени подумать, обсудить. Нужно хотя бы минимально продумать вычислительную модель и как минимум несколько сценариев продумать от UI до DB и обратно. Этот вариант требует времени, но дает результат понятный хотя бы тем, кто в теме. В краткосрочной перспективе этот подход может и не дать результатов. То есть, когда "5 минут на всё", никакого результата не будет, надо брать хоть что нибудь, не задумываясь о корректности, производительности и тд и тд.
Примеры — поиск соответствия в строке это simple, если делается через RegExp, и это easy, если "на коленке". Работа с xml через тот же RegExp это easy, а XmlDoc или XmlSax это simple.
Что не так с easy и почему это "непросто" ?
Человек, который пишет код, всегда погружен в некоторый локальный контекст:
1. что за проблема решается, хотя бы интуитивно представляет эту самую проблему
2. какие есть варианты решения ?
3. какие сопутствующие проблемы имеются ?
4. каким способом решается проблема.
5. опыт, усталость, степень внимания и тд.
У человека, который читает код, такого контекста просто нет а зачастую и быть не может.
1. Одну и ту же проблему люди могут понимать по разному
2. Варианты решения могут быть разными
3. Сведения о сопутствующих проблемах так же разные, а иногда и отсутствуют
4 и 5 эта часть информации вообще недоступна тому кто читает код.
Фактически, получается так, что чтение кода это обратная задача. Как и все обратные задачи она намного сложнее своей прямой задачи. Обратная задача означает, нужно восстановить частично или полностью контекст обозначеный выше.
Метаформа примерно такая — что бы понять код, написаный в стиле easy, надо всего лишь примерить на себя все его знания, опыт, включая опыт из детских травм, сиюминутные порывы и тогда все действительно станет просто. Реальность немного другая — даже свой код в таком стиле, спустя всего две недели становится большой проблемой.
simple подход не требует таких трудозатрат, но требует некоторой грамотности. Например тот, кто никогда не видел Radix LSD, будет до хрипа спорить, что любая сортировка в лучшем случае будет O(N*log(N)) и будет настаивать "здесь уже ничего не соптимизируешь, надо переписывать на С++".
В кратце — времени всегда нет, но лучше смотреть на это с т.з. "много проблем нужно решить в единицу времени". easy vs simple это дилемма и её нужно разрешать в голове. В конце концов, ИТ-специалисты тратят очень много времени на кофе-чай, покурить, посидеть в скайпе или почитать новости.
В большинстве случаев можно и нужно сделать всего две вещи
1. выяснить, какие сроки
2. потратить хотя бы 10% времени исключительно на обдумывание-обсуждение решения.
Например, времени — месяц, работы — вагон. Начать нужно с того, что 2-3 рабочих дня по 8 часов потратить на решение проблемы — подумать и принять решение. Все оставшееся время на реализацию и уточнение. Даже если принято решение идти через easy, будет четко понятно, когда нужно отказаться от этого easy. У адептов аджыле первые два шага, подумать и принять решение, обычно игнорируются.
То есть, максима примерно такая — подумал, принял решение, записал реализацию. Подумал, решил, записал.
P.S. 10% на самом деле условны. Это зависит от многих факторов. Часто бывает так, что решение большой и сложной задачи сводится к смешному количеству кода. Есть только один ответ — опыт.
Продолжение следует. В следующие разы я попробую рассказать про качество, что же это такое и для чего оно нужно и как внешние факторы влияют на это самое качество.
По моему мнению некачественный код получается по в основном по двум причинам
1. малые сроки-бюджеты и/или жесткое давление менеджмента
2. меняются требования часто и непредсказуемо
3. страх, то есть ответственные лица, лиды-архитекты, не хотят подумать и ищут оправдания
Первое и второе есть всегда, а вот третье это особенность конкретных исполнителей. Список оправданий может занять места с целую библиотеку, поэтому ограничусь своим Топ-10
1. тут всё просто/сложно
2. надо сделать всё сейчас, иначе возможности больше не будет
3. а мы так решили
4. это правильно/неправильно
5. мы потом отрефакторим/переделаем/исправим
6. здесь будет синглтон
7. надо сначала сделать(, а думать будем потом)
8. за полгода нам нужно сто-дести-триста фич сделать
9. пусть будет на всякий случай
10. мы соптимизировали на 200мс, остальные 3 секунды(минуты) надо профайлить
Такое ощущение, что люди почему то считают, будто на самом деле любой ситуации есть основная вилка примерно такая
1. Быстро == как нибудь
2. Хорошо == полгода на любую фичу
На мой взгляд, лучше подходить с точки зрения easy vs simple
1. easy
2. simple
Фокус в том, что easy != simple. В русском языке люди любят заменять эту вилку одним словом "просто".
easy это любой код, который только пришел в голову, т.е. обкладываем костылями по мере необходимости.
Этот вариант в принципе ничего, кроме сложной системы костылей, подпорок и веревочек дать не может. Зато не требует времени на обдумывания. В долгосрочной перспективе это конские издержки вплоть до смерти проекта.
simple требует времени подумать, обсудить. Нужно хотя бы минимально продумать вычислительную модель и как минимум несколько сценариев продумать от UI до DB и обратно. Этот вариант требует времени, но дает результат понятный хотя бы тем, кто в теме. В краткосрочной перспективе этот подход может и не дать результатов. То есть, когда "5 минут на всё", никакого результата не будет, надо брать хоть что нибудь, не задумываясь о корректности, производительности и тд и тд.
Примеры — поиск соответствия в строке это simple, если делается через RegExp, и это easy, если "на коленке". Работа с xml через тот же RegExp это easy, а XmlDoc или XmlSax это simple.
Что не так с easy и почему это "непросто" ?
Человек, который пишет код, всегда погружен в некоторый локальный контекст:
1. что за проблема решается, хотя бы интуитивно представляет эту самую проблему
2. какие есть варианты решения ?
3. какие сопутствующие проблемы имеются ?
4. каким способом решается проблема.
5. опыт, усталость, степень внимания и тд.
У человека, который читает код, такого контекста просто нет а зачастую и быть не может.
1. Одну и ту же проблему люди могут понимать по разному
2. Варианты решения могут быть разными
3. Сведения о сопутствующих проблемах так же разные, а иногда и отсутствуют
4 и 5 эта часть информации вообще недоступна тому кто читает код.
Фактически, получается так, что чтение кода это обратная задача. Как и все обратные задачи она намного сложнее своей прямой задачи. Обратная задача означает, нужно восстановить частично или полностью контекст обозначеный выше.
Метаформа примерно такая — что бы понять код, написаный в стиле easy, надо всего лишь примерить на себя все его знания, опыт, включая опыт из детских травм, сиюминутные порывы и тогда все действительно станет просто. Реальность немного другая — даже свой код в таком стиле, спустя всего две недели становится большой проблемой.
simple подход не требует таких трудозатрат, но требует некоторой грамотности. Например тот, кто никогда не видел Radix LSD, будет до хрипа спорить, что любая сортировка в лучшем случае будет O(N*log(N)) и будет настаивать "здесь уже ничего не соптимизируешь, надо переписывать на С++".
В кратце — времени всегда нет, но лучше смотреть на это с т.з. "много проблем нужно решить в единицу времени". easy vs simple это дилемма и её нужно разрешать в голове. В конце концов, ИТ-специалисты тратят очень много времени на кофе-чай, покурить, посидеть в скайпе или почитать новости.
В большинстве случаев можно и нужно сделать всего две вещи
1. выяснить, какие сроки
2. потратить хотя бы 10% времени исключительно на обдумывание-обсуждение решения.
Например, времени — месяц, работы — вагон. Начать нужно с того, что 2-3 рабочих дня по 8 часов потратить на решение проблемы — подумать и принять решение. Все оставшееся время на реализацию и уточнение. Даже если принято решение идти через easy, будет четко понятно, когда нужно отказаться от этого easy. У адептов аджыле первые два шага, подумать и принять решение, обычно игнорируются.
То есть, максима примерно такая — подумал, принял решение, записал реализацию. Подумал, решил, записал.
P.S. 10% на самом деле условны. Это зависит от многих факторов. Часто бывает так, что решение большой и сложной задачи сводится к смешному количеству кода. Есть только один ответ — опыт.
Продолжение следует. В следующие разы я попробую рассказать про качество, что же это такое и для чего оно нужно и как внешние факторы влияют на это самое качество.
| 21.06.2014 0 комментариев |