Twister's blog

Dans un moment d'égarement, je viens de regarder en détail une des classes de mon projet qui est très utilisée. StringHelper...

Les 9/10è des fonctions présentes dans cette classes font les même choses que leurs homonymes dans StringUtils de Apache.commons-lang. La même chose, non, pas tout à fait, elles le font en moins bien codées...

Je vais vous fournir ici quelques unes des gemmes de cette classe, à vous de me trouver ce qui en fait des fonctions stupides par rapport à celles de StringUtils.

Facile :

	public static final boolean isBlank(final String str) {
		return str == null || str.trim().isEmpty();
	}

Dans la famille "je ne fais pas tout à fait ce que je dis que je fais" :

	public static final int compare(final String one, final String two) {
		if(one == two) {
			return 0;
		}
		if(one != null) {
			if(two != null) {
				return one.toUpperCase().trim().compareTo(two.toUpperCase().trim());
			}
			return -1;
		}
		return 1;
	}

Suivie dans la classe par "je fais ce que je dis que je fais" :

	public static final int compareIgnoreCase(
			final String one,
			final String two) {
		if(one == two) {
			return 0;
		}
		if(one != null) {
			if(two != null) {
				return one.compareToIgnoreCase(two);
			}
			return -1;
		}
		return 1;
	}

Et par "je le fais, mais je ne le fais pas vite" :

	public static final String concat(final String...strs) {
		if(strs != null) {
			final int nbStr = strs.length;
			if(nbStr > 0) {
				final StringBuilder sb = new StringBuilder();
				for(int index = 0; index < nbStr; ++index) {
					sb.append(strs[index]);
				}
				return sb.toString();
			}
		}
		return null;
	}

Et par "alors moi je suis méga pas pressé, le CPU et la RAM je m'en cogne, alors je m'éclate" :

	public static final boolean isNumber(final String str) {
		if(str != null) {
			return str.matches("[0-9]*");
		}
		return false;
	}

Un petit peu plus compliqué :

	public static String rightPad(String stringToPad, String padder, int size) {
		if (padder.length() == 0) {
			return stringToPad;
		}
		StringBuffer strb = new StringBuffer(stringToPad);
		StringCharacterIterator sci = new StringCharacterIterator(padder);

		while (strb.length() < size) {
			for (char ch = sci.first(); ch != CharacterIterator.DONE; ch = sci
					.next()) {
				if (strb.length() < size) {
					strb.append(String.valueOf(ch));
				}
			}
		}
		return strb.toString();
	}

Une de mes préférées :

	public static <T> String loopAppender(
			final Iterable<T> iterable,
			final CollectionHelper.Stringuifier<T> stringuifier,
			final String appender
	) {
		final StringBuilder sb = new StringBuilder();
		if(iterable != null) {
			final Iterator<T> it = iterable.iterator();
			while(it.hasNext()) {
				sb.append(stringuifier.stringuify(it.next())).append(appender);
			}
			cleanStringBuilder(sb, appender);
		}
		return sb.toString();
	}

	public static void cleanStringBuilder(
			final StringBuilder sb,
			final String appender
	) {
		final int finalSize= sb.length() - appender.length();
		if (finalSize > 0) {
			sb.setLength(finalSize);
		}
	}

Suivi par une téléportation rapide dans NumberUtils (ou alors les int sont des String travesties ???) :

	private static final int minimum(final int a, final int b, final int c) {
		return Math.min(a, Math.min(b, c));
	}

Bref, arrêtez de recoder des trucs qui existent dans des jar classiques, surtout quand ces jar fournissent des méthodes bien plus efficaces que les vôtres ! Sachez reconnaître que des fonctions existantes depuis des dizaines d'années et utilisée par des dizaines de milliers de développeurs sont sûrement plus efficace que les votre! Surtout quand votre projet inclus déjà ces JARs !!! Et oui StringHelper existe alors que apache.commons-lang est dans les dépendances du projet. sic...

Cela dit c'est peut être un autre problème qui est à la source de cette aberration : les développeurs ont peut être juste oublié de chercher sur internet s'il n'existait pas déjà quelque chose qui faisait ce qu'ils voulaient faire et du coup ont codé ces fonctions la tête dans le guidon! C'est mal!

J'ai récemment eu l’occasion d'implémenter l'intégration d'un flux assez conséquent : environ 4Go pour une initialisation (1 par an) puis plusieurs centaines de Mo pour les deltas hebdomadaires. Pendant les développements j'ai vu et j'ai pensé à certains trucs qu'il est bon de respecter lorsque l'on génère ou traite un si gros flux de données.

Tout d'abord il faut choisir son format. Pour ma part c'était du XML (imposé par le producteur). Il existe une multitude de format existant lisibles par une panoplie de librairies pour à peu près tous les langages. Le choix du format est fonction de ce que vous voulez (de ce que vous avez) à faire. Pour par part il fallait un format qui puisse être "lu" par un humain pour des questions d'analyse si jamais un jour l'algorithme d'intégration du flux décidait d'intégrer les choses à l'envers... ... (et de toutes façons le choix a été fait côté producteur)

Le XML est un format qui reste "humain", si ce n'est pas un de vos pré-requis optez pour des formats plus compacts, votre administrateur réseau vous remerciera sûrement et vous pourrez faire passer plus de données si jamais vous avec un très gros débit temps réel.

Un fois le format choisi il faut y mettre vos données, c'est là où il faut le plus faire attention. En effet vous aller créer un flux qui sera potentiellement consommé par n'importe qui utilisant n'importe quel langage/système donc faites attentions aux formats des données et typez les le plus fortement possible si votre format le permet (ie : ne déclarez pas tout en String dans votre XSD).

Si vous typez correctement vos données et que vous utilisez un format standard il y a de fortes chances que vous n'ayez pas à vous occuper de la sérialisation/de-sérialisation de vos données parce que la librairie que vous aurez choisie le fera très probablement à votre place (XStream en Java pour le XML par exemple). Cela à l'avantage de vous fournir à directement objets avec des champs typés et directement exploitable sans passer des heures à parser des Strings avec tous les risques que cela comporte. Cela évite donc les sorties non conformes parce que votre (dé)sérialiseur maison n'a pas lu/formaté la donnée correctement.

On pourrait parler encore des heures des flux mais ceci est le résultat de ma dernière expérience qui aurait être plus rapide à concrétiser si tout ceci avait été pris en compte. Je n'ai donc pas tout détailler mais voici d'autres point à prendre en compte :

• Si vous êtes producteur :
  • Evitez tous les caractères inutiles comme les retours chariots (\r), les tabulations pour mettre en forme, les espaces multiples qui ne servent à rien...
  • Offrez la possibilité de compresser votre flux (avec un algo adapté comme GZip, BZip2)
  • Offrez la possibilité de ré émettre un flux
  • Prévoyez des tonnes d'exemples pour les développeurs qui consommeront votre flux.
• Si vous êtes consommateur :
  • Faites attention à la charge que génèrera l'intégration de votre flux (insertions en base, moteur de calcul...) et décalez peut être l'intégration à des moments de la journée où la charge est plus faible.
  • Stockez l'original du flux ! Si jamais un problème arrive pendant l'intégration vous serez content d'avoir les données. Si votre flux est temps réel il serait sûrement intéressant d'avoir un 'recorder/replayer' de flux différent du système qui consomme le flux afin de pouvoir tester/développer/debugger
  • Mesurez, re mesurez, et encore... il est important de savoir qu'elle quantité de données vous recevez, combien de temps vous mettez à les lire puis à les traiter.
  • Ne faites jamais confiance au producteur s'il vous fourni des chiffres, revérifiez les ! Le flux a pu grossir depuis sa conception et les chiffres n'ont pas été remis à jour
  • Ne prenez pas pour argent comptant les dire du producteurs sur les contraintes 'fonctionnelles', 'techniques', 'sûres', 'sur la vie d'ma mère'. S'il vous garanti qu'un champs n'est jamais null ajoutez quand même le test dans votre code, s'il vous dit qu'il y a une clé unique faites quand même la votre ou vérifiez l'unicité à chaque traitement, ... bref soyez paranoïaque...