← All posts tagged программирование

mismatch
программирование What We Actually Know About Software Development, and Why We Believe It's True — видео актуальное и по сей день, в котором Greg Wilson рассказывает интересные факты о разработке ПО.
1. Грэг, ссылаясь на работу “Anchoring and Adjustment in Software Estimation”, говорит, что программисты дают ту оценку, которую вы ожидаете от них услышать, независимо от опыта разработки и знания предметной области. При этом не исследовано уменьшается ли итоговая погрешность оценки при разбиении задач на более мелкие.
2. Производительность программиста зависит от длины текста кода, решающего поставленную проблему
3. Большинство ошибок вносится еще до стадии кодирования, а стоимость исправления увеличивается тем больше, чем дольше ошибка остается необнаруженной. Адепты гибкой разработки оптимистически полагают, что стоимость исправления ошибок может быть уменьшена за счет коротких итераций (но это не доказано)
4. Зависимость сложности решения от сложности решаемой проблемы — нелинейная(при этом сложность решения растет быстрее).
5. Промахи в оценке и нестабильные требования — наибольшие проблемы в разработке ПО
6. Если вам предстоит изменить 20-25% компонента, то лучше переписать его с нуля
7. Качественное ревью кода помогает избежать от 60 до 90% багов. При этом оно должно длится не более часа. Размер кода, проходящего ревью, не должен превышать нескольких сотен строчек. Именно столько можно качественно проревьювить за час.

mismatch
программирование The deep synergy between testability and good design — еще один доклад от Майкла Физерса. И начинает он с того, что проблемы с тестированием кода сигнализируют о проблемах с дизайном этого кода. Например, если у вас возникает желание протестировать приватные методы класса, скорее всего он делает слишком много и не следует принципу единственной ответственности. Некоторых разработчиков смущает то, что следование этому принципу приводит к появлению большого количества небольших классов. Но так ли это плохо? Да, в определенных случаях вам придется походить по файлам, чтобы разобраться как работает некоторая функциональность. Но это разделение упрощает поддержку кода. В большинстве случаев вам будет достаточно заменить один из этих небольших классов или добавить еще один небольшой класс вместо того, чтобы менять один большой и беспокоиться не сломали ли вы существующую функциональность.
Далее Майкл задается вопросом: а что же затрудняет тестирование кода?
1. Спрятанное в методе состояние — у вас длинный метод с многими локальными переменными и вы хотите протестировать работу этого метода при различных комбинациях значений этих переменных
2. Сложная система — класс с многими зависимостями, необходимыми для его создания
3. Неполное выключение — например, не освобождаются ресурсы или не переводятся в нужное состояние. В этом случае появится зависимость между тестами и они начнут падать, сигнализируя об имеющейся проблеме.
4. Состояние перетекает из одного теста в другой — например, статическая изменяемая переменная или синглтоны
5. Наличие фреймворка — если фреймворк затрудняет тестирование, то вы недостаточно разделили фреймворк и предметную область
6. Сложности с моками — не нарушаете ли вы закон Деметра?
7. Скрытые эффекты
8. Скрытые входные данные — возможно вы перестарались с инкапсуляцией
9. Громоздкий список параметров метода — нарушение принципа единственной ответственности
10. Недоступность метода — этот случай рассмотрен в самом начале
11. Круговерть тестов — при изменении кода меняется много тестов — вы нарушаете принцип открытости/закрытости
mismatch
программирование habrahabr.ru — «Красота» кода — зло! Никогда не называйте код «красивым», даже мысленно. Самый изощрённый говнокод получается из стремления «сделать красиво». Код может быть читаемым, предсказуемым, лаконичным — но никак не красивым!

Что тут скажешь? Сердцу не прикажешь :) Смотришь на один код и умиляешься, а от другого плеваться хочется. И в этот момент не раскладываешь код по полочкам. Это уже, когда джуну объясняешь, что такое хорошо и что такое плохо.

Но, конечно, я не спорю, что "Самый изощрённый говнокод получается из стремления «сделать красиво»", потому что никто не отменял «хотели как лучше, а получилось как всегда». И, конечно, рефакторинг не должен превращаться в лоботомию. Поэтому сплюнули, включили мозги и принялись за работу.
mismatch
программирование infoq.com — One Weird Trick for Making Perfect Software — Pieter Hintjens (автор ZeroMQ) рассказывает о результато-ориентированном подходе к созданию идеального ПО. Идеальное ПО в первую очередь помогает конечным пользователям решать их собственные проблемы и успешно на рынке. Его разработка движима неудовлетворенными потребностями пользователя. Эти потребности документируются в виде набора небольших проблем, каждую из которых можно достаточно легко держать в голове и решить за относительно короткое время (не более нескольких часов — чем меньше, тем лучше). При этом разработка ведется так, что один коммит решает одну проблему и новая проблема решается преимущественно за счет добавления нового кода, минимально затрагивая существующий. Этот подход требует определенной компетенции от разработчика и не предполагает разгребания технического долга.
mismatch
программирование infoq.com — Тесты или продвинутая система типов? На что положиться? И то и другое требует дисциплины. При этом качество тестов может существенно варьироваться — не зря же придумали мерить покрытие и мутационное тестирование.
mismatch
программирование youtu.be — если вы собираетесь переписать приложение послушайте, на что вам стоит обратить внимание и чего стоит избегать. Главное, не переписывать все сразу, знать, когда остановиться и не переписывать в спешке.
mismatch
программирование martinfowler.com — интересная и обстоятельная статья о переключателях "фич" с их классификацией, советами по реализации и поддержке. Рассматриваются варианты конфигурации этих переключателей: статические (прямо в коде или отдельном конфигурационном файле) и динамические (в базе данных или распределенных системах хранения конфигурации Consul, etcd, ...). Из советов по реализации обращает на себя внимание подход, названный "инверсия принятия решения" (inversion of decision), упрощающий тестирование функциональности в зависимости от состояния переключателя.