Впрочем, можно добавить ещё парочку полезных советов:
Use BDD
Все свои (или чужие) хотелки и идеи пишите не только на бумаге, а оформляйте как код, и пусть это будут тесты для ещё не написанных классов\модулей. Этим вы конкретизируете себе задачу, а тесты будут вас направлять, если вы сбились с пути — т.е. они применимы ко всем пунктам статьи. Я уже не говорю о том, что у вас будет «пуленепробиваемый» код (конечно, при грамотных и очень разнообразных тестах)
От простого к простому
НЕ ставьте больших задач, разбивайте их на малые, и тестируйте. Потом «собрать» приложение как конструктор в сложную логику тоже окажется простой задачей. Имеет смысл выделить приоритетные функции — чтобы показать, что работает впринципе, а навороты и удобство потом. Всё подкрепляйте тестами.
Разделяй и властвуй
Отдельный модуль должен выполнять только строго определённую задачу. Если задача неделима, но находится в пересечении функции существующих модулей — возможно, стоит сделать отдельный модуль. Модули должны быть минимально зависимы друг от друга, что бы можно было выкинуть любой модуль, остальные же части приложения должны работать (возможно, вместо выкинутого модуля можно поставить заглушку). И наоборот, что бы можно было поднять и протестировать отдельный модуль без поднятия остальных.
Здесь помощники: DI, IoC, EDD, MVC
не согласен по поводу «Стоит реже компилировать свой код, вообще стоит больше писать меньше собирать.»: Доверяй, но проверяй
Все мы люди, и не стоит доверять даже себе. «На бумаге» легко не заметить ошибку «на единицу», других условий… Поэтому, как только написал функцию или код — запусти, посмотри, работает ли, и работает ли как надо. Внешние с точки зрения модуля(именно модуля, не только аппликации) данные должны проверяться на допустимость (тип, наличие, размер и т.д.).
Эти проверки можно отрубить в продакшене, если действительно виден выигрыш в производительности.
Если придерживаться BDD, то оно получается само. Идеальный случай — если аппликация может работать в фоне и «подхватывать» изменения сразу же, без перезапуска (интерпретируемые языки, типа PHP, Perl, Python,Rubt могут это позволить, для Java стоит написать собственный ClassLoader). А ещё идеальнее, если бы сразу срабатывали и тесты.
И о документации
Я не люблю писать документацию, и часто игнорирую этот пункт. Но хотя бы код должен быть понятным. Чаще достаточно просто коротких и ёмких имён.
Когда-то споткнулся о то же, тоже решил с помощью дженериков.
Но самое большое извращение с дженериками было, когда пришлось написать функцию (статический метод), который берёт на вход enum (точнее, его класс) и возвращает случайное его значение :)
Впрочем, можно добавить ещё парочку полезных советов:
Use BDD
Все свои (или чужие) хотелки и идеи пишите не только на бумаге, а оформляйте как код, и пусть это будут тесты для ещё не написанных классов\модулей. Этим вы конкретизируете себе задачу, а тесты будут вас направлять, если вы сбились с пути — т.е. они применимы ко всем пунктам статьи. Я уже не говорю о том, что у вас будет «пуленепробиваемый» код (конечно, при грамотных и очень разнообразных тестах)
От простого к простому
НЕ ставьте больших задач, разбивайте их на малые, и тестируйте. Потом «собрать» приложение как конструктор в сложную логику тоже окажется простой задачей. Имеет смысл выделить приоритетные функции — чтобы показать, что работает впринципе, а навороты и удобство потом. Всё подкрепляйте тестами.
Разделяй и властвуй
Отдельный модуль должен выполнять только строго определённую задачу. Если задача неделима, но находится в пересечении функции существующих модулей — возможно, стоит сделать отдельный модуль. Модули должны быть минимально зависимы друг от друга, что бы можно было выкинуть любой модуль, остальные же части приложения должны работать (возможно, вместо выкинутого модуля можно поставить заглушку). И наоборот, что бы можно было поднять и протестировать отдельный модуль без поднятия остальных.
Здесь помощники: DI, IoC, EDD, MVC
не согласен по поводу «Стоит реже компилировать свой код, вообще стоит больше писать меньше собирать.»:
Доверяй, но проверяй
Все мы люди, и не стоит доверять даже себе. «На бумаге» легко не заметить ошибку «на единицу», других условий… Поэтому, как только написал функцию или код — запусти, посмотри, работает ли, и работает ли как надо. Внешние с точки зрения модуля(именно модуля, не только аппликации) данные должны проверяться на допустимость (тип, наличие, размер и т.д.).
Эти проверки можно отрубить в продакшене, если действительно виден выигрыш в производительности.
Если придерживаться BDD, то оно получается само. Идеальный случай — если аппликация может работать в фоне и «подхватывать» изменения сразу же, без перезапуска (интерпретируемые языки, типа PHP, Perl, Python,Rubt могут это позволить, для Java стоит написать собственный ClassLoader). А ещё идеальнее, если бы сразу срабатывали и тесты.
И о документации
Я не люблю писать документацию, и часто игнорирую этот пункт. Но хотя бы код должен быть понятным. Чаще достаточно просто коротких и ёмких имён.
Но самое большое извращение с дженериками было, когда пришлось написать функцию (статический метод), который берёт на вход enum (точнее, его класс) и возвращает случайное его значение :)
шизофреники реже талантливы
мда, видимо, неудачный я дем нашел — буд-то что-то оскорбительное